Discussion :

[Sergejack]

Bonjour.

J'ai une DB qui évolue pas mal chaque jour.
Il y a dans cette DB beaucoup de données qui n'ont quasiment que pour seule valeur de servir d'historique.
Ainsi je me disais qu'il serait peut-être intéressant pour les performances si je mettais à intervalle ponctuel (tous les jours à minuit par exemple) ces données sur le côté afin de ne conserver dans ma DB que les données nécessaires au fonctionnement en cours et à venir.

Je ne m'y connais pas sur le sujet. J'ignore par exemple si les partitions seraient une piste illusoire à suivre, etc.

Donc, j'aimerais que vous me conseilliez un peu si vous le pouvez.
Merci.

[NicoD.]

Déplacer les enregistrements de la table courante vers la table archive est une bonne idée.

Ceci peut être fait par l'intermédiaire d'un script dans un langage tiers (ex: PHP) ou même par création d'une procédure stockée.

Cependant, avant d'optimiser à fond, combien y a-t-il d'enregistrements dans ta table et combien peux-tu en espérer au maximym sans faire de ménage (dans un scénario raisonnablement pessimiste) ?

[Sergejack]

J'ignore à quel moment j'aurais de gros problèmes de performance.
Mais quotidiennement, on peut estimer que 95% des nouveaux enregistrements peuvent/devraient être archivés et donc ça augmente vite.

[NicoD.]

Si on prend une procédure stockée, voici un exemple de code à exécuter à 0h15.

On ajoutera une colonne booléenne to_be_archived à la table courante afin d'être sûr de supprimer les enregistrements de la table qui ont été copiés dans l'archive.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
 
 
CREATE PROCEDURE nettoie_table() 
BEGIN
 
  UPDATE table_courante SET to_be_archived = true WHERE date_insertion <= DATE_ADD(CURDATE, INTERVAL -1 SECOND) ;
 
  INSERT INTO table_archive SELECT * FROM table_courante WHERE to_be_archived = true ;
 
  DELETE FROM table_courante WHERE to_be_archived = true
 
END //

Un petit LOCK TABLES pourra même être un peu plus sécurisant si jamais tu n'es pas sûr des processes qui ont accès à la base de données.

[Sergejack]

La seule méthode suggérée est de dupliquer les tables ?

[NicoD.]

Si c'est pour des soucis de performance, c'est le système que j'emploierais effectivement en priorité.

Après tu avais évoqué le partitionnement. C'est également une piste à suivre mais cela dépend de la structure existante de la table et de la manière qu'on a de l'interroger.

Il faut trouver un bon "angle de partitionnement" pour pouvoir séparer les données (Ex : l'heure d'insertion pour des logs). Mais il ne faut pas que cela handicape des requêtes SELECT qui chercheraient des enregistrements sur plusieurs partitionnement (Perfs légèrement dégradées par rapport à l'absence de partitionnement).