Vous n'êtes pas identifié(e).
Bonjour,
J'ai un gros soucis de maintenance de une base de données très volumineuse : presque 2 tera-octets répartis sur une table de près de 3 milliards de lignes ...
Cette dernière est donc très volumineuse, notamment une table qui contient des données enregistrées toutes les secondes, sous forme de 'bytea'.
En gros, je dois enregistrer 1 an de données, avec une précision à la seconde, pour 80 entitées. Puis une fois presques pleine, la base doit effectuer un roulement, remplaçant les données les plus vieilles par les nouvelles.
Pour cela, chaque nuit, les lignes correspondant aux jours "en trop" sont supprimées (afin de pouvoir être remplacées).
Sauf que l'espace disque n'est pas rendu pour autant...
Comme un simple autovacuum n'a pas suffit, j'ai cherché à mettre en place une solution "manuelle".
Après quelques lectures sur internet, j'ai testé une solution qui marche sur un test avec seulement 1 jour de données (4 gigas sur 7 millions de lignes):
- vacuum + analyze
- reindex
Mais avec une base plus grosse (dès qu'on atteint quelques semaines de données), l'analyse ne se lance même pas (ou en tout cas le mode verbose n'affiche rien, et attendre une nuit complète n'y change rien...)
Dans l'idéal, il faudrait que cette maintenance puisse se faire sans stopper les "enregistrements" pour autant.
Au pire, la maintenance devrait pouvoir etre effectuée le plus rapidement possible durant la nuit, pour ne stopper les "enregistrements" qu'un minimum de temps.
J'ai essayer de retoucher le fichier de config (nontament en augmentant le 'max_fsm_pages'), mais rien n'y fait...
Quelqu'un a-t-il une idée de config, ou une piste a essayer ?
Hors ligne
On est en plein dans un des quelques cas ou il est intéressant de partitionner par date : il s'agit de faire des plus petites tables, chacune ne contenant qu'une partie de l'intervalle de temps.
Voici déjà la doc sur le sujet, pour commencer : http://docs.postgresqlfr.org/8.4/ddl-partitioning.html
Marc.
Hors ligne
Merci pour la piste, qui aurait du être explorée lors de la conception, plutôt qu'a une semaine du déploiement...
Je vais y jeter un œil, et voir si cela est possible a mettre en place rapidement.
L'ennui, donc, est que je voudrais éviter (au moins dans un premier temps) de trop modifier la structure de ma base, car l'application doit être fonctionnelle la semaine prochaine, et seul ce problème subsiste.
Y a-t-il une configuration de postgresql (notamment les paramètres de réglage du vacuum et ru reindex ?) adaptée à mon cas, sans pour autant retoucher la structure ?
Merci!
Hors ligne
La modification de structure proposée par Marc ne demande aucune modification de l'application. Ce n'est pas un soucis pour le déploiement de la solution.
Avec la structure actuelle... Pour le REINDEX, seul un maintenance_work_mem plus important pourra vous aider. Pour le VACUUM, jouer avec les coûts ne pourra qu'augmenter la durée d'exécution du VACUUM, mais améliorer la rapidité des autres procédures.
Guillaume.
Hors ligne
Je suis effectivement en train de mettre en place le partitionnement, qui semble être la solution qui aurait du être spécifiée depuis le début, car complètement adaptée à mon cas.
Hors ligne
Par contre, attention, avec le partitonnement, il y a qq requêtes qui peuvent poser problème (les plans sont plus difficiles à élaborer).
Des choses toutes bêtes comme "select max(date) from ma_table_partitonnee". C'est full scan de toutes les partitions (pas retesté en 8.4, mais c'était le cas en 8.3).
Donc ça veut dire refaire une passe de validation sur l'appli.
Marc.
Hors ligne
En effet, et j'en ai plein d'autre comme ca...
J'espère avoir le temps de modifier les requêtes a problème et de repasser un plan de test complet derrière, pas évident d'ici la fin de la semaine...
J'ai du boulot ;-)
Pour info, je suis en 8.3
Hors ligne
