Bonjour,

• J'ai une base de données SOURCE et une base de données DESTINATION.
• J'historise les données de certaines tables de SOURCE dans la base DESTINATION de la façon suivante :
  
  • A chaque transaction(insertion, modification, etc...) de la base SOURCE,
  • J’insère l'identifiant technique de la table de SOURCE dans une table T_PIVOT ayant la structure suivante : id de la table de la base SOURCE, l’état de la ligne insérée, la nature de la transaction, etc ...)
  • Chaque soir je lance un batch qui traite la table T_PIVOT et qui alimente la base DESTINATION
  • Mise à jour de l’état de la ligne traité : En cours de traitement, traité, erreur
  • etc ...
• Problématique : la table de pivot grossit vite et j'ai envie d'archiver les données dans une autre table T_PIVOT_ARCHIVE

• solution que j'envisage pour l'instant

• • Mettre en place un batch qui purge les éléments traités avec succès de T_PIVOT dans T_PIVOT_ARCHIVE tous les X ( soirs, semaine, mois)

• • Déclencher le batch si taille de la table atteint un certain seuil
• Mes interrogations :
  
  • Est-ce une bonne pratique de procéder ainsi ? j'imagine qu'il existe des bonnes pratiques pour faire de choses pareils sachant que je suis dans le monde Java : hibernate, spring batch, etc ...
  • Avez déjà travailler sur des tels problématiques ? si oui J'aimerai partager vos expérience, etc...
    
    Je vous remercie par avance

[HS]Pour un traitement comme celui si je ferait du talend qui est extrêmement bien adapté[/HS]

Une solution puissante mais dépendante de ton SGBD est les tables de partitionnements (je te laisse check google)

Si tu veux quand même le faire en springbatch, surtout ne récupère surtout pas les données, fait le en traitement SQL (via hibernate ne récupère pas les entité mais fait du SQL natif).

Après pense à faire la purge régulièrement plutôt que une fois par an.

Le système que j'avais mis en place était un peu différent, réexportait les données de n-1 à n et supprimait de n-2 à n-1, je zippait le fichier puis le balançait sur un serveur de stockage.

Attention si tu utilise un SGBD comme mysql, il faudrat que tu réalise des OPTIMIZE à minima après ton traitement, sinon tu auras le syndrome des ligne fantôme et des index casser, pour du PostGre/oracle, il y a en téhorie un système de réparation automatique, en sql server pas la moindre idée.

Voila voila, j’espère que sa pourra t'aider.

-
Edité par florent m 6 décembre 2016 à 9:08:14

Spring Batch est un ETL : extraire, transformer, charger.
Si ton batch ne fait qu'appeler un script SQL, tu peux avoir remplacer ça par une simple méthode schédulée.

Pinguet62 a écrit:

Spring Batch est un ETL : extraire, transformer, charger.
Si ton batch ne fait qu'appeler un script SQL, tu peux avoir remplacer ça par une simple méthode schédulée.

Je suis d'accord mais je mettrait juste un petit bémol, si sur le projet n'a pas ordonnanceur pur et dur derrière, je pense que faire une Task en Springbatch est préférable pour avoir un regroupement en même point (de même si la supervision Spring batch est activé).

Sa dépend, je pense principalement du fonctionnement actuel du projet.

Merci pour vos réponses et précisions , les choses se dessinent de mieux en mieux dans ma tête. Je pense le faire en Java, les contraintes du projet oblige, une solution à la spring batch avec un truc du genre TaskScheduler ... me va bien, je pourrais coupler ça avec  l'idée du serveur de stockage ...