Bonjour,

Pour l’histoire
Il y a maintenant 10 ans, j’ai développé un moteur de transformation de données.
Il a bien entendu évolué pendant toutes ces années.
Actuellement, ce moteur utilise des objets Moose et fonctionne à 100% en mémoire, dans un seul thread.
Les objets sont donc tous persistants, pendant toute la durée d’execution.
A ce jour cette méthode ne correspond plus à mes besoins futurs.

De plus, la volumétrie des données que je reçois, est en constante évolution.
Il n’est pas rare de voir le process, consommer de 30 à 50Go de mémoire, sur 64, (voire 79 au plus haut avec une méchante pagination qui met à genou la machine).
En revanche tous les coeurs ne sont pas utilisés et cela démontre bien une mauvaise utilisation de cette super machine de 12 coeurs.

Ce que je souhaite faire
Bref, je souhaite donc maintenant, avoir des objets persistants, après exécution et gérer beaucoup plus de volume.
J’ai donc opté pour la théorie suivante :
- Postgres (persistance des données)
- Moose + DBix::Class (gestion des objets, similaire à aujourd’hui avec persistance)
- Threads Perl (exécution de règles de transformation en //)

Le multi-threading, me permettra donc, de soumettre des règles de conversion en parallèle.
Alors que dans la version actuelle, du moteur, elles sont sérialisées.
Certaines de ces règles pourront tourner en parallèle et d’autres seront en attente de leurs « prédécesseurs », via une configuration déjà existante.
Je vais donc mettre au moins un petit ordonnanceur, qui, avec les fonctions « list » de threads, garantira le bon ordonnancement.

Les règles sont, ni plus ni moins, que de petites fonctions, qui feront du CRUD dans la base, au travers des objets Moose.
Bien entendu, comme en principe je sais ce que fais (enfin je crois ), chaque règle aura son propre périmètre et ne devrait jamais mettre à jour les mêmes zones de la base ou même les lire avant un update, afin d’éviter des conflits d’update, (même si le SGBD sait le faire), mais surtout garantir la cohérence des données.

Votre avis m'intéresse
Avec ce principe, je pense donc répondre à mes futurs besoins et le multi-threads ferait gagner du temps, perdu par les I/O du SGBD.
Je suis actuellement sur l’architecture fonctionnelle théorique de ce bousin et je souhaite vous solliciter sur différents points :
  • Est-ce que j’ai bon dans la théorie ?
  • Avez-vous des retours d’expérience de ce type d'architecture ?
  • Que pensez-vous de cela ?


Je vous remercie par avance de vos retours.
Bien cordialement,
dca_marshall