PostgreSQL La base de donnees la plus sophistiquee au monde.

Forums PostgreSQL.fr

Le forum officiel de la communauté francophone de PostgreSQL

Vous n'êtes pas identifié(e).

#1 17/02/2009 17:40:56

anseo
Membre

Optimisation pour les COPY FROM

Bonjour,

Dans le cadre de l'alimentation d'un DataWarehouse, je rencontre un problème de performance pour alimenter une des tables de faits.

L'alimentation hebdomadaire, via un ETL (Business Data Integrator) insère en moyenne dans l’une de ces tables plus de 3 millions d'enregistrements. L'ETL génère des ordres Insert avec un commit toutes les 1000 enregistrements et le traitement a une durée de 75 minutes en moyenne pour l’alimentation de cette table.

Afin d'optimiser ce traitement, nous avons décidé de ne plus utiliser les ordres Insert mais d'utiliser la fonction COPY :
COPY TO table_ods puis COPY FROM table_faits.
L'insertion des 3 millions d'enregistrement est descendue à 6 minutes les premières semaines, puis est remonté à 60 minutes (pour le copy from). La seule évolution apporté à la table de faits est l'ajout d'un index très précieux pour les performances des requêtes BO. Ce qui monte à 2 le nombre d'index sur cette table.

En supprimant l'index nouvellement créé, l'insertion des 3 millions d'enregistrement est redescendue à 6 minutes.

L'objectif de l'utilisation de la fonction COPY est de diminuer les temps d'alimentation du DataWarehouse puis de générer les requêtes BO dans la foulée pour les mettre à disposition des utilisateurs en début de matinée.

Peut-on désactiver la mise à jour des index d'une table le temps de l'alimenter et ensuite mettre à jour les index ?

La suppression/recréation des index sur cette table ne me convient pas car leur création met plusieurs heures.

J'espère avoir été clair et je vous remercie par avance pour vos suggestions.

Dernière modification par anseo (17/02/2009 17:44:08)

Hors ligne

#2 17/02/2009 18:32:18

gleu
Administrateur

Re : Optimisation pour les COPY FROM

La table d'insertion est vidée entre chaque insertion ? Le fait que la création de l'index prend plus de temps que sa mise à jour laisse à supposer que oui, mais bon.

Avez-vous essayé d'augmenter maintenance_work_mem lors de la création des index ? (aucun intérêt lors de leur mise à jour)

Vous faites des COPY FROM de combien d'enregistrements ?


Guillaume.

Hors ligne

#3 17/02/2009 18:54:17

anseo
Membre

Re : Optimisation pour les COPY FROM

Bonsoir,

La table de faits n'est pas vidée entre chaque chargement et chaque semaine le COPY FROM insère en moyenne 3 millions d'enregistrements  nouveaux dans cette table.

Hors ligne

#4 17/02/2009 21:10:10

gleu
Administrateur

Re : Optimisation pour les COPY FROM

Pour répondre à votre première question, non, il n'est pas possible de désactiver la mise à jour des index. Il est généralement préférable de supprimer les index, puis de les re-créer.


Guillaume.

Hors ligne

#5 18/02/2009 12:27:08

anseo
Membre

Re : Optimisation pour les COPY FROM

Merci gleu pour vos réponses.

Dans mon cas la supression des index, chargement de la table puis ensuite création des index serait beucoup plus couteux (4 à 5 heures en tout) que les ordres Insert (75 minutes en moyenne)
Donc dommage....

Ce que je ne m'explique pas c'est qu'avec un seul index sur cette table le COPY from est très perfomant. A partir du moment ou il y en a plus de deux, les perfomances se dégradent. Pour info les deux index ont sensiblement la même taille, 3 GB chacun pour une table de 17 GB.

Cordialement,

Philippe

Hors ligne

#6 19/02/2009 01:27:40

gleu
Administrateur

Re : Optimisation pour les COPY FROM

Cela peut dépendre de la façon dont les deux index sont construits. Par exemple, un index GIN mettra toujours beaucoup de temps à se mettre à jour, ralentissant du coup les insertions. Cela doit être pareil pour les index fonctionnels.


Guillaume.

Hors ligne

#7 07/03/2009 08:35:33

jmax
Membre

Re : Optimisation pour les COPY FROM

les index's sont aussi une bonne indication des performances du système d'entrées/sorties puisque c'est de l'I/O pur. Typiquement, le RAID5 y montre toutes ses faiblesses ;-)

Hors ligne

Pied de page des forums