Skip site navigation (1) Skip section navigation (2)

Re: Partionnement automatique

From: Baptiste Manson <baptiste(dot)manson(at)inovia-team(dot)com>
To: Cédric Villemain <cedric(dot)villemain(dot)debian(at)gmail(dot)com>
Cc: pgsql-fr-generale(at)postgresql(dot)org
Subject: Re: Partionnement automatique
Date: 2011-08-31 08:29:59
Message-ID: CAMaQLwDCBFYyv5myUzmebjAYz0B0DCg20KXVkrwJJ4U=Dadxqw@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-fr-generale
Merci de ton retour Cédric.
Ton avis est pertinent. Concernant le risque d'effet boule de neige du
DDL dans un trigger, il nous faudrait effectivement préciser que seul
une colonne relevant d'un référentiel stable peut être ainsi utilisée.
Il est par moment difficile de partionner avec un cron : en effet,
dans certains cas, les données à insérer ne sont pas intégrée au fil
de l'eau. L'exemple est l'intégration de données historiques s'étalant
sur un nombre de période variable. Créer toutes les tables à la main
est une tâche fatiguante et error prone.

Nous pensons écrire un autre article sur la stratégie que tu présentes
en tentant d'identifier les cas d'usages liés à chacune des approches
:
- création à la demande de partition : reprise de données historique,
clé de partitionnement stabilisée par référentiel
- création planifiée de partition : intégration de données au fil de
l'eau, partionnement temporel sur la date d'intégration, beaucoup
d'insert concurrents.
- création initiale des partitions : clé de partitionnement connue et
très peu variante (on partionne sur des pays)

Voyez vous d'autres cas d'usages et d'autres approches sur la création
des partitions ?

Le 30 août 2011 18:57, Cédric Villemain
<cedric(dot)villemain(dot)debian(at)gmail(dot)com> a écrit :
> Le 30 août 2011 16:09, Baptiste Manson
> <baptiste(dot)manson(at)inovia-team(dot)com> a écrit :
>> Bonjour à tous,
>>
>> C'est mon premier article dans cette mailing list, alors n'hésitez pas
>> à me faire vos commentaires si je ne respecte pas l'étiquette.
>> Nous avons écrit quelques articles sur la mise en place d'un
>> partionnement automatique :
>> L'idée est de fournir, pour des applications avec peu de write
>> (beaucoup de read) des fonctionnalités avancées pour gérer les
>> partitions et les maintenir.
>> Nous avons implémenté cela avec un trigger basé sur l'INSERT et sur
>> une clé fonctionnelle de partionnement.
>> Voici le code de la fonction concernée :
>>
>> -- Attach a magic function to the insert of this table:
>> CREATE OR REPLACE FUNCTION create_partition_and_insert()
>> RETURNS trigger AS
>> $BODY$
>> DECLARE
>> partition VARCHAR(25);
>> BEGIN
>> partition := TG_RELNAME || '_' || NEW.period || ‘p’;
>> IF NOT EXISTS(SELECT relname FROM pg_class WHERE relname=partition) THEN
>> RAISE NOTICE 'A partition has been created %',partition;
>> EXECUTE 'CREATE TABLE ' || partition || ' (check (period = ''' ||
>> NEW.period || ''')) INHERITS (' || TG_RELNAME || ');';
>> END IF;
>> EXECUTE 'INSERT INTO ' || partition || ' SELECT(' || TG_RELNAME || ' '
>> || quote_literal(NEW) || ').*;';
>> RETURN NULL;
>> END;
>> $BODY$
>> LANGUAGE plpgsql VOLATILE
>> COST 100;
>> Voici un article détaillant le processus :
>> http://blog.inovia.fr/auto-partitioning-on-postgresql-part-1/
>>
>> Quels inconvénients et avantages voyez vous sur cette méthode ?
>
> L'avantage est le coté dynamique bien sur. Toutefois il faut pondérer.
> Le dynamisme sur l'insert dans une table ou dans une autre aura un
> léger impact comparé à un insert dédié pour chaque table mais impact
> probablement négligeable. (et puis a l'inverse, le nombre de trigger à
> déployer peut impacter si il y en a trop).
> Par contre, il est tres fortement déconseillé de passer des DDL (le
> create table) dans un trigger. Il y a un énorme risque d'effet boule
> de neige: le temps de creer la table, d'autres INSERT risque de se
> produire et de déclencher eux aussi des create table, ca s'accumule,
> puis tous vont faire un rollback, sauf 1 qui va gagner (l'effet sur le
> serveur est une pause dans la qualité du service) ;)
> La solution consiste à avoir une partition 'fourre-tout' et des
> creations de partition périodique (cron par exemple). La partition
> fourre-tout sert alors lorsque la partition qui aurait du etre créée
> par 'cron' ne l'a pas été et que l'on ne veut pas que le trigger
> plante jusqu'a ce qu'un admin agisse.
>
>
>
> --
> Cédric Villemain +33 (0)6 20 30 22 52
> http://2ndQuadrant.fr/
> PostgreSQL: Support 24x7 - Développement, Expertise et Formation
>



-- 
Baptiste Manson
Inovia - Paris - www.inovia.fr
http://twitter.com/#!/inoviateam
baptiste(dot)manson(at)inovia-team(dot)com
(mobile) 00+33 6 62 13 82 18
(land)    00+33 1 75 51 37 48

In response to

Responses

pgsql-fr-generale by date

Next:From: Marc CousinDate: 2011-08-31 08:59:28
Subject: Re: Partionnement automatique
Previous:From: Cédric VillemainDate: 2011-08-30 16:57:42
Subject: Re: Partionnement automatique

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group