Ça va vite même sans être la NSA...
Oui ce fut le cas pour nous avec un modele de donnees comme suivant ou l'on a un pipe line qui contient de plus en plus de donnees (chaque D represente le volume de donnees):
sachant que la premiere etape (geree par JMS) les volumes etaient aussi en train d'exploser, et il a fallu commencer a dedupliquer les donnees en entree.
Le modele etait ainsi fait que plus l'on avancait dans le pipeline et plus les donnees etaient volumineuses et complexes a gerer avec des regles metiers parfois completement opposees selon le type de donnees.
Hyper interessant, mais pas top quand tes collegues ne sont pas au niveau du challenge :(
dès que tu as plusieurs centaines de milliers de lignes à insérer ou mettre à jour, tu vas avoir très très envie de gérer des commits intermédiaires pour des raisons de perf. Et donc de te passer de la gestion des transactions des middlewares pour gérer tes points de reprise. C'est donc à adapter en fonction de chaque type de batch et de sa volumétrie.
Le probleme etait:
l'architecture pas adaptee au volume de donnees
la difficulte a casser les sacro saintes transactions en devant convaincre l'humain (en particulier lorsque les requirements faisaient que ca ne tiendrait plus jamais dans une seule transaction)
1.1. les analystes metiers
1.1. les clients
Les analaystes metiers etaient de maniere suprenante les plus difficiles a convaincre. Il y a aussi eu un testeur qui faisait des tests automatiques qui n'a pas aime le changement, mais j'ai du le rembarrer en lui disant que l'on n'avait pas le choix. Le pauvre gars avait pousse sa gueulante a un tres mauvais moment.
Bref assez stressant quand un P1 nous tombait sur le coin de la gueule toutes les semaines.
[^] # Re: Questions
Posté par djano . En réponse à la dépêche JQM, un serveur de batchs asynchrones en Java. Évalué à 1.
D => DD => DDD => DDDD => DDDDD
1 => 1000 -> 10000 -> 100000
sachant que la premiere etape (geree par JMS) les volumes etaient aussi en train d'exploser, et il a fallu commencer a dedupliquer les donnees en entree.
Le modele etait ainsi fait que plus l'on avancait dans le pipeline et plus les donnees etaient volumineuses et complexes a gerer avec des regles metiers parfois completement opposees selon le type de donnees.
Hyper interessant, mais pas top quand tes collegues ne sont pas au niveau du challenge :(
Le probleme etait:
Les analaystes metiers etaient de maniere suprenante les plus difficiles a convaincre. Il y a aussi eu un testeur qui faisait des tests automatiques qui n'a pas aime le changement, mais j'ai du le rembarrer en lui disant que l'on n'avait pas le choix. Le pauvre gars avait pousse sa gueulante a un tres mauvais moment.
Bref assez stressant quand un P1 nous tombait sur le coin de la gueule toutes les semaines.