Re: Partionnement automatique

Bonjour Baptiste,

Le 31 août 2011 10:29, Baptiste Manson
<baptiste(dot)manson(at)inovia-team(dot)com> a écrit :
> 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 ?

Il existe de tres nombreux usages pour les partitions, pour les
approches sur la création c'est assez limité.
- via DDL si tres peu de risque de concurrence d'acces.
- via cron si risque important
- via DBA si déterministe/limité: les pays, mais aussi des partitions
utilisées pour leur structure (chaque partition a un tronc commun et
des colonnes indépendantes par exemple)
- via appli, pour un besoin applicatif

Dans les usages, il faut distinguer les usages pour des raisons de
performances du serveur et les usages pour l'application.
J'ai des cas d'utilisations où l'héritage et ce qui vient avec est très utile.
Pour les performances, améliorer le moteur semble être la chose à faire :)

>
> 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
>

--
Cédric Villemain +33 (0)6 20 30 22 52
http://2ndQuadrant.fr/
PostgreSQL: Support 24x7 - Développement, Expertise et Formation