Traitement de millions d'enregistrements de bases de données en Java

Question

J'ai besoin d'écrire un travail par lot qui récupère les lignes d'une table de base de données et, en fonction de certaines conditions, écrit dans d'autres tables ou met à jour cette ligne avec une certaine valeur. Nous utilisons Spring et jdbc pour récupérer le jeu de résultats et itérer à travers et traiter les enregistrements en utilisant un programme java autonome qui est programmé pour être exécuté chaque semaine. Je sais que ce n'est pas la bonne façon de faire, mais nous devions le faire comme une solution temporaire. Au fur et à mesure que les enregistrements se compteront en millions, nous finirons par avoir des exceptions pour cause de mémoire insuffisante, et je sais donc que ce n'est pas la meilleure approche.

L'un d'entre vous peut-il me recommander la meilleure façon de faire face à une telle situation ?

Utiliser les Threads et récupérer 1000 enregistrements par thread et les traiter en parallèle ?

(OR)

Utiliser un autre mécanisme de batch pour faire cela (je sais qu'il y a spring-batch mais je ne l'ai jamais utilisé).

(OR)

D'autres idées ?

Answer 1

Vous savez déjà que vous ne pouvez pas mettre en mémoire un million de lignes et opérer sur elles.

Tu devras les réduire en morceaux d'une manière ou d'une autre.

Pourquoi les amener au niveau intermédiaire ? J'envisagerais d'écrire des procédures stockées et d'opérer sur les données sur le serveur de base de données. L'amener au niveau intermédiaire ne semble pas vous apporter grand-chose. Demandez à votre travail de lot de lancer la procédure stockée et d'effectuer les calculs sur place dans le serveur de base de données.

Answer 2

un travail par lot qui récupère des lignes d'une table de base de données et, en fonction de certaines conditions, écrit dans d'autres tables ou met à jour cette ligne avec une certaine valeur.

Cela ressemble au genre de chose que vous devriez faire dans la base de données. Par exemple, pour extraire une ligne particulière et la mettre à jour en fonction de certaines conditions, SQL dispose de la fonction UPDATE ... WHERE ... déclaration . Pour écrire dans une autre table, vous pouvez utiliser INSERT ... SELECT ... .

Cela peut devenir assez compliqué, mais je vous suggère de faire tout ce qui est en votre pouvoir pour le faire à l'intérieur de la base de données, car extraire les données pour les filtrer est incroyablement lent et va à l'encontre de l'objectif d'une base de données relationnelle.

Remarque : Veillez à expérimenter cette méthode sur un système de non-production d'abord, et mettez en place toutes les limites nécessaires pour ne pas bloquer les tables de production aux mauvais moments.

Answer 3

Cela dépend vraiment de ce que vous traitez et de la manière dont vous traitez les dossiers.

Mais d'une manière générale, vous ne devez pas les charger tous en une seule fois dans la mémoire, mais les traiter par morceaux de taille raisonnable.

Answer 4

Je suis d'accord avec Brendan Long en général. Cependant, je continuerais probablement à essayer de sélectionner un sous-ensemble de votre ensemble de données "millions" dans la procédure stockée. Sinon, vous allez faire exploser le journal des transactions de votre base de données. Assurez-vous simplement de toujours valider vos insertions ou mises à jour à intervalles réguliers.

Si vous ne voulez pas faire cela dans la proc stockée, demandez simplement à Spring Batch de charger les clés des enregistrements que vous souhaitez manipuler à une taille fixe (utilisez un curseur/lecteur de pagination), mais demandez à la proc stockée de faire le travail réel. De cette façon, vous minimisez les données transmises à votre niveau intermédiaire tout en bénéficiant des avantages de Spring Batch et des performances de votre base de données pour la manipulation des données.