Vous avez besoin d'un traitement de nuit qui lit vingt millions de lignes, les transforme et écrit les résultats. Comment l'écrivez-vous pour ne pas épuiser la mémoire ?

Traitez en flux plutôt que de tout matérialiser : lisez avec un curseur défilant ou une pagination par clé, fixez une taille de fetch pour que le pilote ne bufferise pas tout, et traitez par blocs avec un commit par bloc. Avec JPA, videz le contexte de persistance entre les blocs ou utilisez une session sans état, sinon chaque entité reste dans le cache de premier niveau. Groupez les écritures avec le batching JDBC, et rendez le traitement redémarrable depuis son dernier bloc commité.

La règle centrale, c'est qu'aucune étape ne détient vingt millions de quoi que ce soit. Je lis avec une pagination par clé sur la clé primaire, ou un curseur défilant avec une taille de fetch explicite, et il faut savoir que certains pilotes ignorent ça et bufferisent tout le jeu de résultats sauf si vous êtes aussi dans une transaction avec l'autocommit désactivé, ce que les gens découvrent à la dure quand le tas se remplit avant que le moindre traitement ne commence. Ensuite je traite par blocs de quelques milliers, j'écris avec le batching JDBC pour avoir un aller-retour par bloc plutôt que par ligne, et je commite par bloc. Avec JPA le piège en plus, c'est le contexte de persistance : chaque entité lue reste gérée, donc la mémoire grimpe et les flushs ralentissent à mesure que la détection de modifications parcourt plus d'objets. Je le vide à chaque bloc ou j'utilise une session sans état. La redémarrabilité compte autant que la mémoire, donc le traitement enregistre la dernière clé commitée, ce qui veut dire qu'un échec à la dix-huit millionième ligne reprend au lieu de tout recommencer. Et je le bride, parce qu'un traitement par lots qui sature la base à deux heures du matin touche quand même ceux qui sont réveillés.