PostgreSQL partitonnement - retour d'expérience.

[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

[pif34]

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

"pif34" <pi...@nospam.fr> a écrit dans le message de news:
4e9d29dc$0$4008$426a...@news.free.fr...

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

"WebShaker" <eti...@tlk.fr> a écrit dans le message de news:
4ea5da5e$0$29148$426a...@news.free.fr...

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

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

[Etienne]

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]

"Stéphane" <no_...@free.fr> writes:

> "pif34" <pi...@nospam.fr> a écrit dans le message de news:
> 4e9d29dc$0$4008$426a...@news.free.fr...

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

[pif34]

oui, enfin dans les messages dans mes souvenirs, j'ai bien précisé que
je parlais de modèle relationnel pour une base de donnée classique (hors
clustering, etc.).

Par ailleurs, tout dépend aussi du résultat que tu souhaites: google ne
retourne pas un résultat exacte... car quand tu prend des grandes bases
de grandes entreprises ou administration francaise, celle qui tournent
en tera(s) voir peta(s), elle tournent sur un clustering oracle plus
classique... en tout cas, c'est oracle qui va gérer bonne partie du
problème en conservant une modélisation relationnelle assez classique...
on se pose uniquement quelques questions de déploiement, tablespace, etc.