Re: Re

From: Sébastien Dinot <sebastien(dot)dinot(at)free(dot)fr>
To: pgsql-fr-generale(at)postgresql(dot)org
Subject: Re: Re
Date: 2005-06-07 20:26:53
Message-ID: 20050607202653.GA4819@free.fr
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-fr-generale

Bonsoir,

Christophe Garault a écrit :
| - pourquoi ne pas supprimer les index (éventuellement les
| déclencheurs et les contraintes d'intégrité) avant l'intégration
| pour ne les recréer qu'en fin de traitement. Je n'ai pas
| l'expérience de tels volumes avec PostgreSQL, mais avec Oracle et
| une dizaine de tables qui dépassaient les 50 millions de lignes, le
| gain était faramineux. (bon ok c'était un E10K)

Je ne peux pas me permettre de supprimer temporairement les index car
chaque INSERT est précédé de deux ou trois SELECT selon le contexte.
Supprimer les index accélèrerait les écritures mais ralentirait les
lectures. Ce n'est pas viable.

| - n'est-il pas possible d'effectuer le traitement sur les CSV pour
| les enregistrer dans un autre fichier et effectuer ensuite
| l'intégration par un COPY FROM ?

Cela est impossible pour deux raisons :

1. Je veux conserver les données brutes originelles pour pouvoir à
tout instant les retraiter dans leur intégralité en partant d'une
base vide (ce que je fais actuellement).

En effet, les traitements sont partiellement destructifs et je ne
peux donc pas regénérer les données brutes à partir des données
traitées. Or, depuis le début du projet, la logique de traitement
de ces données a déjà évolué par deux fois. Si je n'avais pas gardé
ces données brutes, j'aurais été bien embêté.

2. Les traitements qui accompagnent ces insertions sont lourds et
mettent en jeu de gros volumes de données. Générer des fichiers CSV
« pré-digérés » sans passer par une base nécessite trop de mémoire.
Voici quelques mois, avec la moitié moins de données, j'avais
essayé : le script Perl consommait alors plus de 700 Mo de RAM
(dans de tels cas, utiliser Perl n'aide pas).

Quoiqu'il en soit, ce n'est que la troisième fois en un an que j'ai
besoin de rejouer l'intégralité des données. Mon souci est donc
ponctuel.

Si les traitements ne sont pas modifiés mais que j'ai besoin de
restaurer la base après une anomalie soit survenue, j'utilise
simplement les sauvegardes quotidiennes et non ce script.

| Enfin jetez donc un oeil sur la doc Chapitre 13.4 qui contient
| quelques autres conseils bien utiles dans votre cas.

Ce qui est dit dans cette section, soit je l'ai déjà fait, soit c'est
impossible dans mon cas.

Sébastien

--
Sébastien Dinot, sebastien(dot)dinot(at)free(dot)fr
http://sebastien.dinot.free.fr/
Ne goûtez pas au logiciel libre, vous ne pourriez plus vous en passer !

In response to

  • Re: Re at 2005-06-07 16:28:28 from Christophe Garault

Browse pgsql-fr-generale by date

  From Date Subject
Next Message Sébastien Dinot 2005-06-08 06:49:24 Re: Re
Previous Message Guillaume LELARGE 2005-06-07 20:13:03 Re: Backups sur les fichiers des bases ...