From: | Dimitri Fontaine <dimitri(at)2ndQuadrant(dot)fr> |
---|---|
To: | "Pierre Y(dot)" <pierre(dot)y(at)gmail(dot)com> |
Cc: | pgsql-fr-generale(at)postgresql(dot)org |
Subject: | Re: Migration d'une base simple vers une base utilisant des schemas |
Date: | 2013-01-31 10:25:07 |
Message-ID: | m2k3qtabuk.fsf@2ndQuadrant.fr |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-fr-generale |
"Pierre Y." <pierre(dot)y(at)gmail(dot)com> writes:
> Je suis toujours en train de réfléchir à cette question... Je me demandais
> s'il serait possible, plutôt que partitionner toute la base par user, de ne
> partitionner que les plus grosses tables ?
Dans ce genre d'approche on peut aussi envisager PL/Proxy, dont
l'inconvénient majeur est de devoir passer par une interface entièrement
basée sur des procédures stockées et dont l'avantage principal est de
savoir s'adapter très facilement à des variations importantes de volumes
de données à gérer.
> Après il reste l'idée de déplacer les vieilles données par forcément utiles
> dans un serveur d'archivage et de faire le ménage dans la base principale
> mais je doute que ça puisse se faire automatiquement, il va me falloir
> scripter ça et appeller ce système d'archivage dans une tâche cron.
S'il est possible de faire un script et de l'invoquer depuis cron, alors
je pense que « ça peut se faire automatiquement », non ?
> L'idée de vérifier que les performances de ma base et de mon application
> sont optimales est aussi à l'ordre du jour, je vais me faire une sessions
> pgbadger quand les logs seront pleins.
Ici, regarder Tsung et pg_stats_statement.
"Pierre Y." <pierre(dot)y(at)gmail(dot)com> writes:
> J'ai quand même l'impression que les partitions c'est une usine à gaz.
>
> C'est bien de ça qu'on parle ?
> http://www.postgresql.org/docs/current/static/ddl-partitioning.html
C'est relativement lourd en effet. Ce mécanisme a été développé pour la
version 8.1 de PostgreSQL avec une contrainte forte sur le temps de
développement, et donc en tirant le maximum de l'existant.
Le problème de cette approche est qu'elle fonctionne juste assez bien
pour avoir historiquement limité la motivation des sponsors à financer
le développement d'une solution intégrée de partitionnement. On arrive
enfin au bout de cette période, cependant.
Deux projects de développements sont à considérer ici :
- partitionnement automatique, ou Segment Partitionning
PostgreSQL se débrouille tout seul pour savoir où trouver dans le
stockage physique les données qui correspondent à certaines clauses
WHERE
- partitionnement déclaratif
Un nouveau système de déclaration à l'avance des partitions
permettant au planificateur de requêtes de ne pas avoir à deviner où
sont les données, et lui permettant surtout de savoir aiguiller les
modifications de données (DML) sans que l'utilisateur ne fournisse
de triggers
Nous (2ndQuadrant) avons déjà travaillé sur la conception de ces deux
systèmes et avons un plan de développement concret, appliquable dans le
cadre du développement de PostgreSQL 9.4. Quelques sponsors ont déjà
déclaré leur intérêt et souhaitent participer, vous êtes les bienvenues
égalemment ! :)
--
Dimitri Fontaine
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support
From | Date | Subject | |
---|---|---|---|
Next Message | Dimitri Fontaine | 2013-02-04 13:05:51 | Barman 1.2.0 |
Previous Message | Pierre Y. | 2013-01-30 22:02:08 | Re: Migration d'une base simple vers une base utilisant des schemas |