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
Vidéos High-Tech et Jeu Vidéo
Téléchargements
Vos réponses Page 1 / 2
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
pif34
Le #23877761
Le 18/10/2011 09:12, Etienne a écrit :
En fait au final, le partitionnement consiste à séparer les données
contenues dans une table dans plusieurs tables (lorsque cela est possible).



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 !
Etienne
Le #23877751
Le 18/10/2011 09:25, pif34 a écrit :
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
pif34
Le #23877801
Le 18/10/2011 09:34, Etienne a écrit :

Ceci dit, si le partitionnement existe, c'est bien que le problème lui
aussi existe.



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
Etienne
Le #23877841
Le 18/10/2011 09:50, pif34 a écrit :
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...



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
Stéphane
Le #23898081
"pif34" 4e9d29dc$0$4008$
Le 18/10/2011 09:12, Etienne a écrit :
En fait au final, le partitionnement consiste à séparer les données
contenues dans une table dans plusieurs tables (lorsque cela est
possible).



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 !




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.
WebShaker
Le #23900331
Le 24/10/2011 11:48, Stéphane a écrit :
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.



Ah ouai.
j'en suis a 12 Go a présent. je suis encore loin des 2 To c'est clair.

T'as mis quoi comme valeurs pour les paramètres

Linux
- kernel.shmmax

Postgresql
- shared_buffers
- effective_cache_size
- work_mem
- max_fsm_pages

Etienne
Stéphane
Le #23900771
"WebShaker" 4ea5da5e$0$29148$
Le 24/10/2011 11:48, Stéphane a écrit :
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.



Ah ouai.
j'en suis a 12 Go a présent. je suis encore loin des 2 To c'est clair.

T'as mis quoi comme valeurs pour les paramètres

Linux
- kernel.shmmax

Postgresql
- shared_buffers
- effective_cache_size
- work_mem
- max_fsm_pages

Etienne





Je ne suis pas sous postgress mais sous Oracle. Et sous Linux Redhat 5.5 64
bits.
pif34
Le #23905171
c'est ce que j'ai essayé de te faire comprendre, outre des
"optimisations" et la puissance du serveur, la plupart des perfs que tu
peux récupérer c'est dans ton appli: cache applicatif, index, requetes,
schéma, etc.

C'est un job de développement d'un serveur propre... Combien d'appli
soit disant performante j'ai récupéré et en moins de 15j de charges
(profiling, correction), j'ai divisé par 10 à 100 les points qui
posaient problème...

Tes partitions, c'est du bricolage, tot ou tard si ta volumétrie
augmente dans le temps tu auras à nouveau le problème, mais il deviendra
bien plus complexes à analyser et corriger grace à ton bricolage...

Le 24/10/2011 23:36, WebShaker a écrit :
Le 24/10/2011 11:48, Stéphane a écrit :
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.



Ah ouai.
j'en suis a 12 Go a présent. je suis encore loin des 2 To c'est clair.

T'as mis quoi comme valeurs pour les paramètres

Linux
- kernel.shmmax

Postgresql
- shared_buffers
- effective_cache_size
- work_mem
- max_fsm_pages

Etienne


Etienne
Le #23905241
Le 26/10/2011 08:45, pif34 a écrit :
c'est ce que j'ai essayé de te faire comprendre, outre des
"optimisations" et la puissance du serveur, la plupart des perfs que tu
peux récupérer c'est dans ton appli: cache applicatif, index, requetes,
schéma, etc.

C'est un job de développement d'un serveur propre... Combien d'appli
soit disant performante j'ai récupéré et en moins de 15j de charges
(profiling, correction), j'ai divisé par 10 à 100 les points qui
posaient problème...

Tes partitions, c'est du bricolage, tot ou tard si ta volumétrie
augmente dans le temps tu auras à nouveau le problème, mais il deviendra
bien plus complexes à analyser et corriger grace à ton bricolage...



Pour autant que j'ai pu comprendre de mon soucis.
il est plus technique d'autre chose.
j'avais (j'ai toujours) dans la table des champs tsvector.

si j'ai bien compris les infos que j'ai glanées à droite à gauche (sans
pour autant pouvoir être sur que c'est totalement vrai), lorsqu'on
modifie une donnée d'un enregistrement c'est tous l'enregistrement qui
est réécrit sur le disque.

du coup, rien que flaguer un mail comme étant lu imposait une
ré-écriture de tout le mail dans la base y compris le tsvector qui est
assez gros.

Donc il est vrai que je ne saurai jamais si le partitionnement était
utile. Il est possible que la simple séparation des données dans deux
tables:
- une pour les données vouées à être modifiées
- une pour le donnée statiques
aurait peut être tout aussi bien solutionner mon problème.

Au final j'ai fait les deux : partitionnement et séparation des données.
Les intérêts sont multiples:
- les index des tsvector sont séparés compte mail par compte mail, du
coup leur indéxation est un peu plus rapide.
- les caches sont mieux exploités car certain comptes mails inactifs ne
seront jamais cachés
- les autovaccums bien qu'encore très long sont plus nombreux mais aussi
plus rapide.

Bref. J'ignore si l'on pouvait optimiser autrement. peut etre en effet
utiliser un outil externe a postgresql pour indéxer.
Mais l'utilisation des tsvector est tellement simple que je préfère ne
pas m'en passer.
Marco Blanc
Le #23987551
"Stéphane"
"pif34" 4e9d29dc$0$4008$

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



Ben une base qui fait 1Go c'est une ultra mini base !



Oui, 1 Go c'est rien du tout. Pour répondre à pif34, les systèmes qui
gèrent les "grosses" bases avec des données considérables (comme
facebook, Google et autres) utilisent des bases de données orientées
colonnes sur de l'informatique distribuée (BigTable, Hbase...). Voir le
framework Hadoop : http://hadoop.apache.org/

--
M.B
Publicité
Poster une réponse
Anonyme