PostgreSQL partitonnement - retour d'expérience.
Le
Etienne
Salut.
Bon pour info, le partitionnement de ma table semble avoir totalement
solutionné mes problèmes de performance lors d'accès concurrents.
Les blocages que j'avais ont disparus.
La charge globale du serveur à fondu (significativement).
Je me demande juste finalement à quoi sert d'avoir une table père dans
le partitionnement sous postgresql.
Puisque je n'aurai jamais accéder à cette table parent, mis a par le
fait de pouvoir ajouter un champ et le propager à toute les tables
filles, le concept de partitionnement via l'héritage me semble quelques
peu lourd
En fait au final, le partitionnement consiste à séparer les données
contenues dans une table dans plusieurs tables (lorsque cela est possible).
Etienne
Bon pour info, le partitionnement de ma table semble avoir totalement
solutionné mes problèmes de performance lors d'accès concurrents.
Les blocages que j'avais ont disparus.
La charge globale du serveur à fondu (significativement).
Je me demande juste finalement à quoi sert d'avoir une table père dans
le partitionnement sous postgresql.
Puisque je n'aurai jamais accéder à cette table parent, mis a par le
fait de pouvoir ajouter un champ et le propager à toute les tables
filles, le concept de partitionnement via l'héritage me semble quelques
peu lourd
En fait au final, le partitionnement consiste à séparer les données
contenues dans une table dans plusieurs tables (lorsque cela est possible).
Etienne
Poser une question
oui, en fait, ca sert à remettre toutes les règles d'or de la
modélisation...
moi la question, que je me pose, c'est comment font les grosses bases...
pasque si t'as besoin de 20 partitions sur une une base qui fait 1 Go,
comment font les systèmes qui ont aujourd'hui plusieurs tera voir péta !?
c'est comme changer les rous d'une voiture qui a les pneus creuvés par
des roues en bois pasque c'est mieux... c'est juste pas la solution !
Mais ca va plus vite que les pneus creuvés !
C'est une bonne question.
Dans mon cas j'use et abuse des jointures.
Je me demande effectivement ce que donnerai une requête assez complexe
avec quelques jointures sur des très grosses volumétrie.
Ceci dit, si le partitionnement existe, c'est bien que le problème lui
aussi existe.
Etienne
c'est parcequ'il existe qu'il est bon de l'utiliser systématiquement
quand un table est trop grosse à ton gout:
c'est expliqué ici:
http://fr.wikipedia.org/wiki/Partitionnement_(Oracle)
tu dois avoir un découpage logique...
découper les gens de l'annuaire entre suivant les lettres de l'alphabet
c'est pas logique...
si tu partitionne un fichier de client entre les clients pro et
particuliers, par exemple, ca peut etre pertinent, car ton appli en aval
a le meme schéma mais va traiter les infos totalement différemment dans
des reportings, etc.
ca veut dire que t'es capable de dire qu'une partie de l'application ne
vas s'intéresser qu'à une partie des données et pas l'autre...
découper un volume en 26 aléatoirement (car les lettre de l'alphabet
c'est presque ca), ca ne suit probablement aucune logique de ton
applicatif c'est donc abhérent à mon sens...
maintenant, le jour ou tu dois ajouter une colonne, ce sera bien plus
compliqué... t'as sacrifié ta maintenance applicatif suite à une erreur
de conception... donc maintenant, t'as un application toujours moins
bien concue qu'avant et encore plus difficile à maintenir...
mais elle va plus vite... c'est comme enlever réduire la taille du pneu,
enlever l'airbag et la ceinture de sécurité d'une berline: elle est plus
légère, moins de frottement donc elle va plus vite... et ca coute pas
cher au départ, c'est plus facile que mettre un gros moteur.. mais tot
ou tard ca coutera cher...
c'est comme ca qu'on apprend
Je suis d'accord.
Néanmoins, parfois on a pas le choix.
Dans le cas de l'extranet sur lequel je bosse, il vaut mieux que ce soit
réactif sinon tous les utilisateurs de la boite vont venir se plaindre
en permanence.
Donc là, y a pas à regretter mon choix.
Une fois que j'aurai fini l'import de toutes les données, la base va
faire environ 10 Go (donc bien plus avec les indexes...)
Je verrai à ce moment là si tout tient la route.
Etienne
Ben une base qui fait 1Go c'est une ultra mini base !
Actuellement je suis sur une base qui contient des tables de plusieurs
centaines de millions de lignes sans probleme de performances et sans
patitionnement. Taille totale de la base environ 2 To. Le tout sur un
serveur 24coeurs et 60Go de RAM avec en moyenne 500 connexions utilisateurs
en parallèle.