Les CSV, trois ans plus tard.

Il y a trois ans, j’écrivais un article sur le traitement des fichiers CSV en Java. Je vous invite d’ailleurs à le lire ou à le relire. Je m’étais alors volontairement limité, notamment sur l’aspect multithread. Il faut dire aussi que l’article faisait 70 pages, ce qui est déjà bien difficile à digérer. Mais depuis, la technologie a évolué, aussi bien dans nos programmes que dans les composants matériels.

Je reviens donc sur cet article trois ans après l’avoir écrit. Entre temps, la technologie a évolué. La mémoire vive (RAM) des serveur a été multipliée par quatre, voire plus. Même les postes de développeurs sont de plus en plus équipés de 16 Go de RAM alors que 4 était jusque là le standard. Les capacités des disques durs, et plus généralement des unités de stockage, ont été revues à la hausse. Alors qu’il y a trois ans, l’unité de mesure était encore la centaine de Go (Giga), on parle désormais en To (Tera). En outre, les unités de stockage sans partie mobile, comme les SSD, sont enfin accessibles à des prix compétitifs et offrent des performances incroyables.

Tout cela pourrait encourager les développeurs à ne plus faire d’effort dans leurs programmes. Mais c’est un piège. Au contraire, on manipule de plus en plus de données. On a donc des fichiers CSV de plus en plus gros. Et oui, trois ans plus tard, les fichiers CSV sont toujours présents. Le format JSON a révolutionné le secteur informatique mais ne répond pas à tous les besoins, notamment dans le cadre d’une forte volumétrie.

L’idéal est de travailler avec des fichiers CSV dont chaque ligne est indépendante des autres, ce qui est souvent le cas. Par exemple, dans mes fichiers des cours des actions, chaque ligne correspond à la valeur d’une action et ne dépend donc pas des autres lignes. Le sens de l’histoire tend à traiter chaque ligne au moment où elle est lue et non plus de lire l’ensemble du fichier d’un coup pour en traiter les lignes plus tard. Des frameworks comme Spring-Batch facilitent ce fonctionnement. Ils recommandent d’ailleurs, pour des raisons évidentes, de traiter les lignes par lots (plus ou moins gros). Ainsi au lieux de traiter un fichier de 10 000 lignes en une seule fois, on préfère le découper en plus petits lots de seulement 1000 lignes chacun. On traitera alors 10 lots. La taille d’un lot dépend bien entendu du sujet d’étude. Mais cela n’est possible que si les lignes sont indépendantes.

En fait, cette méthodologie existait déjà il y a trois ans. Elle était d’ailleurs déjà efficace. Or, l’évolution des processeurs ne tend plus à augmenter la fréquence (exprimée en MHz) mais à multiplier le nombre de cÅ“urs, c’est-à-dire d’unités de calcul/traitement. Les derniers processeurs destinés aux particuliers ont souvent 4 cÅ“urs ou plus, leur permettant donc d’effectuer autant d’opérations en même temps. Pouvoir diviser un fichier CSV en petits lots permet d’utiliser ce nouveau potentiel. Et, disons le, c’est extrêmement performant.

L’arrivée de Java 7 a permis de vrais gains dans le cadre de la programmation concurrente (i.e. parallèle) et celle de Java 8 (prévue dans quelques semaines) va simplifier l’écriture des programmes dans ce but. Un mot/notion a bien connaitre sera le « Stream ». Je vous conseille de vous y intéresser.

Laisser un commentaire