postgreSQL partitionnement information

Le
Etienne
Salut;

J'ai une très grosse table dans laquelle je fais des requetes sur un
champs indéxé.

J'envisage je partitionner cette table.
J'ai quelques questions tout de même avant de procéder à l'opération.

Tout d'abors est ce vraiment utile en terme de performance.
Mon interrogation n'est pas tellement sur les lectures, mais plutôt sur
les lectures et écritures concurrentes.
je passe mon temps a ajouter, modifier, supprimer et lire des
enregistrement dans cette table.

Les transactions lock les tables. Donc je suppose que plus de tables =
moins de conflit non ?

Bref. Est ce que quelqu'un aurai un retour sur l'interet du
partitionnement. Car c'est quand même assez penible à mettre en place
alors autant ne pas le faire pour rien.

Ma deuxième question est:
puisque le partitionnement dans postgreSQL est juste un usage
particulier de l'héritage.
Comment puis-je interdire l'accès en écriture de la table père. Vu que
je vais devoir modifier une application qui pour le moment utilise la
table pére, j'aimerai mettre une contrainte qui m'interdit d'écrire
dedans afin d'être sur de ne pas avoir oublié une requète quelquepart.

Troisième Question:
Existe t-il une instruction qui permette de créer une table sur le
modèle d'une autre.J'aimerai, si c'est possible, éviter de devoir créer
les tables à partir d'un CREATE TABLE.
J'aimerai avoir une partition modèle qui me servierai de base pour la
creation d'une autre partition.
C'est possible ca ?

Enfin.
Lorsqu'on a 100 partitions (qui sont donc 100 tables filles d'une autre
tables), comment fait t-on pour modifier d'un seul coup les 100
partitions. Par exemple, si je dois ajouter un trigger ou une contrainte
sur toutes les partitions ?

Merci
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
Pif 34
Le #23823451
Etienne wrote:
Salut;

J'ai une très grosse table dans laquelle je fais des requetes sur un
champs indéxé.

J'envisage je partitionner cette table.

J'ai quelques questions tout de même avant de procéder à l'opération.

Tout d'abors est ce vraiment utile en terme de performance.
Mon interrogation n'est pas tellement sur les lectures, mais plutôt sur
les lectures et écritures concurrentes.
je passe mon temps a ajouter, modifier, supprimer et lire des
enregistrement dans cette table.

Les transactions lock les tables. Donc je suppose que plus de tables =
moins de conflit non ?



t'as pas droit au dirty read ? pourquoi de lock de tables ? 1 seul
client monotache ?

Bref. Est ce que quelqu'un aurai un retour sur l'interet du
partitionnement. Car c'est quand même assez penible à mettre en place
alors autant ne pas le faire pour rien.



difficile a dire sans avoir plus d'info sur la volumetrie et les acces:
- combien de requete par secondes ?
- quelle taille de table ?
- combien de tuples retournés en moyenne ?
- quelle requete en gros ?
- combien d'insertion/délétion/update par rapport au insertions ?

Je sais pas quelle est ton application et les techno en jeu, mais le
plus souvent la solution réside dans :
- l'index
- la procédure stockée si multiples requetes lourdes pour une opération
- grouper les requetes et mettre en place un cache applicatif, réduire
le fetchsize, etc.

Souvent, le problème se traite en amont...

Ma deuxième question est:
puisque le partitionnement dans postgreSQL est juste un usage
particulier de l'héritage.
Comment puis-je interdire l'accès en écriture de la table père. Vu que
je vais devoir modifier une application qui pour le moment utilise la
table pére, j'aimerai mettre une contrainte qui m'interdit d'écrire
dedans afin d'être sur de ne pas avoir oublié une requète quelquepart.



t'as deux solutions:
- utiliser une vue readonly
- utiliser un compte utilisateur différent dans lequel pour la table
t'as uniquement le droit de lecture...

Troisième Question:
Existe t-il une instruction qui permette de créer une table sur le
modèle d'une autre.



create table as select ...
par contre, ca prend pas les index et contraintes d'intégrité diverses...

J'aimerai, si c'est possible, éviter de devoir créer
les tables à partir d'un CREATE TABLE.



ben tu veux les créer comment ?

J'aimerai avoir une partition modèle qui me servierai de base pour la
creation d'une autre partition.
C'est possible ca ?



désolé, je connais pas assez bien les partitions... comme indiqué, j'ai
toujours trouvé des solutions en amont bien plus efficaces et moins
couteuse... de toute facon, chez moi, la BD elle s'ennuit en général
pendant que serveur applicatif mouline... en général, le problème, c'est
comment gérer le cache applicatif !

Enfin.
Lorsqu'on a 100 partitions (qui sont donc 100 tables filles d'une autre
tables), comment fait t-on pour modifier d'un seul coup les 100
partitions. Par exemple, si je dois ajouter un trigger ou une contrainte
sur toutes les partitions ?

Merci
Etienne.


SQLpro
Le #23838571
bonjour,

Le 04/10/2011 09:28, Etienne a écrit :
Salut;

J'ai une très grosse table dans laquelle je fais des requetes sur un
champs indéxé.

J'envisage je partitionner cette table.



hélas le partitionnement sur PG n'est encore qu'embryonnaire, car une
bonne partie doit être fait à la main !
En effet contrairement aux solution de SQL Server ou Oracle, chacune des
partitions est en fait une table indépendant sur laquelle il faut
appliquer certaines commandes DDL sur toutes les partitions, si vous
voulez que vos différentes partitions (en faite table) aient la même
structure (colonnes, contraintes, index...).

De plus PostGreSQL ne sait pas faire de l'optimisation sémantique sans
qu'on soit obliger de lui demander... Ainsi une requête demandant des
données ne pouvant figurer dans la partition, ira quand même lire les
données de cette partition pour ne rien retourner, sauf si vous avez
pensé à mettre en place préalablement le bon indicateur (mais est-ce
pour la session ou pour le serveur ??? mystère !) :
SET constraint_exclusion = on;
Mais même dans ce cas, l'utilisation d'un partitionnement par dateheure
avec l'appel à une fonction de type CURRENT_DATE plante l'optimiseur qui
utilisera toutes les partitions...

Enfin, la gestion des espaces de stockage étant encore aussi
embryonnaire, il est impossible par exemple de pré réserver de l'espace
pour stocker les données sur les fichiers de stockage des différentes
tables de partitionnement. Il en résulte que PostGreSQL fera de
l'autogrowth, ce qui n'est pas folichon du fait de la fragmentation
physique des fichier qui en résultera !

Pour terminer il est extrêmement difficile de gérer les partitions. Par
exemple pour migrer les données d'une partition d'un espace de stockage
à l'autre , il faut :
1) démarrez une transaction au niveau SERIALIZABLE
2) créer une nouvelle table fille dans cet espace de stockage
3) migrer les données par un UPDATE
4) supprimer les données de l'ancienne table
5) ajouter les index
6) ajouter les règles
7) modifier la vue
8) terminez la transaction
je n'ai pas encore tester ce qui se passe si cette table est une
référence d'intégrité...

En comparaison, sous MS SQL Server, il suffit d'une commande :
ALTER TABLE ... SWITCH PARTITION ...
En sus on peut en une seule commande sous MS SQL Server fusionner ou
scinder une partition :
ALTER PARTITION ... SPLIT RANGE ...
ALTER PARTITION ... MERGE RANGE ...

Tout ceci limite pas mal l'intérêt du partitionnement sous PG...

J'ai d'ailleurs l'intention de poster un comparatif des solutions de
partitionnement PG et MS SQL Server dans quelques temps sur la partie
blog de mon site : http://sqlpro.developpez.com/

J'espère que ceci vous aura aidé...

A +

J'ai quelques questions tout de même avant de procéder à l'opération.

Tout d'abors est ce vraiment utile en terme de performance.
Mon interrogation n'est pas tellement sur les lectures, mais plutôt sur
les lectures et écritures concurrentes.
je passe mon temps a ajouter, modifier, supprimer et lire des
enregistrement dans cette table.

Les transactions lock les tables. Donc je suppose que plus de tables > moins de conflit non ?

Bref. Est ce que quelqu'un aurai un retour sur l'interet du
partitionnement. Car c'est quand même assez penible à mettre en place
alors autant ne pas le faire pour rien.

Ma deuxième question est:
puisque le partitionnement dans postgreSQL est juste un usage
particulier de l'héritage.
Comment puis-je interdire l'accès en écriture de la table père. Vu que
je vais devoir modifier une application qui pour le moment utilise la
table pére, j'aimerai mettre une contrainte qui m'interdit d'écrire
dedans afin d'être sur de ne pas avoir oublié une requète quelquepart.

Troisième Question:
Existe t-il une instruction qui permette de créer une table sur le
modèle d'une autre.J'aimerai, si c'est possible, éviter de devoir créer
les tables à partir d'un CREATE TABLE.
J'aimerai avoir une partition modèle qui me servierai de base pour la
creation d'une autre partition.
C'est possible ca ?

Enfin.
Lorsqu'on a 100 partitions (qui sont donc 100 tables filles d'une autre
tables), comment fait t-on pour modifier d'un seul coup les 100
partitions. Par exemple, si je dois ajouter un trigger ou une contrainte
sur toutes les partitions ?

Merci
Etienne.






--
Frédéric BROUARD - expert SGBDR et SQL - MVP SQL Server - 06 11 86 40 66
Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez.com
Enseignant Arts & Métiers PACA, ISEN Toulon et CESI/EXIA Aix en Provence
Audit, conseil, expertise, formation, modélisation, tuning, optimisation
*********************** http://www.sqlspot.com *************************
Etienne
Le #23844231
Le 08/10/2011 20:43, SQLpro a écrit :
J'espère que ceci vous aura aidé...



Oui.

Il est vrai que le concept même de partitions est un poil étrange.
Je pense qu'une base de données intelligente devrait être capable de
gérer le partitionnement toute seule sans qu'on ai besoin de le lui dire.

Il est un peu étrange de devoir de palucher à la main toute cette
segmentation alors que le SGBD devrait être capable de faire ça tout seul.

Bon dans mon cas j'ai pas trop le choix, je vais devoir m'y coller (et
pourtant ma table n'est pas très grande).
C'est une table qui contient les mails de l'entreprise où je bosse.
pour le moment il n'y a que 500.000 enregistrements et déjà j'ai
quelques problème de performances lorsque j'insère en même temps qu'un
autre user décide par exemple de déplacer 150 mails.

Les IO se mettent alors à exploser semble t-il.
Le problème ne semble arriver que si j'exécute des grosses requêtes
concurrentes sur une même table.

On m'a donc conseiller:
- de partitionner
- de séparer les champs static (sujet, contenu, ...) des champs
dymanique (is_mail_readed, idmailfolder, ...) dans deux tables séparées
afin de limiter l'impact des IO lors de la modification des champs
dynamique.

Donc ben même si c'est un gros boulot, je vais me lancer là dedans.
On vera bien:)

Etienne
Etienne
Le #23844431
Le 04/10/2011 21:32, Pif 34 a écrit :
Etienne wrote:
t'as pas droit au dirty read ? pourquoi de lock de tables ? 1 seul
client monotache ?



Heu, là, je ne sais pas trop de quoi tu parles. je suis pas assez calé
en PostgreSQL pour comprendre.
Mais c'est pas une application monotache. Ca c'est sur.

difficile a dire sans avoir plus d'info sur la volumetrie et les acces:
- combien de requete par secondes ?
- quelle taille de table ?
- combien de tuples retournés en moyenne ?
- quelle requete en gros ?
- combien d'insertion/délétion/update par rapport au insertions ?



La base contient 500.000 enregistrements.
C'est une table qui contient des mails.
Elle est assez grosse car je me sers d'un ts-vector pour faire des
recherches dans les mails.

Je sais pas quelle est ton application et les techno en jeu, mais le
plus souvent la solution réside dans :
- l'index
- la procédure stockée si multiples requetes lourdes pour une opération
- grouper les requetes et mettre en place un cache applicatif, réduire
le fetchsize, etc.



Non c'est dejà indéxé.

t'as deux solutions:
- utiliser une vue readonly
- utiliser un compte utilisateur différent dans lequel pour la table
t'as uniquement le droit de lecture...



Bon. je vais voir.

create table as select ...
par contre, ca prend pas les index et contraintes d'intégrité diverses...
ben tu veux les créer comment ?



Ben je vais utiliser ton CREATE AS SELECT
si ca marche avec un SELECT * ca sera deja bien.

Merci.
Etienne.
pif34
Le #23844601
Le 10/10/2011 10:46, Etienne a écrit :
Le 04/10/2011 21:32, Pif 34 a écrit :
Etienne wrote:
t'as pas droit au dirty read ? pourquoi de lock de tables ? 1 seul
client monotache ?



Heu, là, je ne sais pas trop de quoi tu parles. je suis pas assez calé
en PostgreSQL pour comprendre.



ca n'a rien a voir avec PG, c'est de la BD purement généraliste: tu nous
parles de transactions et de concurrence alors qu'il n'y a pas de
concurrence ! C'est toi meme qui présuppose le cout des verrous et qui
sous entend que répartir ta données sur plusieurs tables a un intéret...

je rappelle ta question initiale:
"[...] les lectures et écritures concurrentes. je passe mon temps a
ajouter, modifier, supprimer et lire des enregistrement dans cette
table. Les transactions lock les tables. Donc je suppose que plus de
tables = moins de conflit non ? ".



Pour moi, l'intéret du partitionnement est ailleurs et il est
suffisamment rare pour qu'on ne se pose plein d'autres question
d'optimisation avant d'envisager quelque chose d'aussi lourd et complexe...


La base contient 500.000 enregistrements.
C'est une table qui contient des mails.
Elle est assez grosse car je me sers d'un ts-vector pour faire des
recherches dans les mails.



500 000 ligne c'est rien et ca mérite pas de partitionnement... une
table de 100 millions de lignes qui dépasse les 4 Go, la ca se
discute... j 'ai fait de l'indexation de texte avec 50 millions
d'enregistrement en me passant de tous ces artifices et ca tournait au
poil !

ton but c'est de faire un moteur de recherche dans des textes... une BD
c'est pas fait pour ca... il faut gérer une indexation au niveau
applicatif et utiliser le moteur relationnel pour des données
structurées et indexée proprement...

laisse tomber ton tsvector si c'est lui qui coute ! C'est un outil pour
ceux qui l'utilisent de facon accessoire.. toi c'est le coeur de métier
de ton applicatif vraissemblablement et les performance ne sont pas
suffisantes... alors travaille à optimiser cette fonctionnalité.

le partitionnement, ca va pas améliorer la fonction de recherche de ton
moteur... après si tu me dis que t'as 10 ans de mail et que tu veux
limiter la recherche aux X derniers mails ou à ceux des 30 derniers
jours, la en effet tu partitionne la donnée... ca allege le boulot pour
le SGBDR...
Etienne
Le #23844871
Le 10/10/2011 11:25, pif34 a écrit :
500 000 ligne c'est rien et ca mérite pas de partitionnement... une
table de 100 millions de lignes qui dépasse les 4 Go, la ca se
discute... j 'ai fait de l'indexation de texte avec 50 millions
d'enregistrement en me passant de tous ces artifices et ca tournait au
poil !



Ouaip. je sais que c'est pas des masses.
mais soyons clair. Ca ne moulle pas. c'est même assez rapide sauf...
lorsque j'insère un enregistrement en même temps que j'en modifie
d'autres. (en fait lorsque j'en insère plusieurs en meme temps que j'en
modifie plusieurs).

ton but c'est de faire un moteur de recherche dans des textes... une BD
c'est pas fait pour ca... il faut gérer une indexation au niveau
applicatif et utiliser le moteur relationnel pour des données
structurées et indexée proprement...



Hum.
Je faisais ca avant.
j'utilisais swish-e.
Sauf que c'était trop pénible à gèrer, mettre à jour, ...
En plus je me retrouvais avec autant de fichiers que de mails sur mon
serveur (je me parle même pas des pièces jointe...).
Un jour j'ai eu besoin de rebooter, le FSCK a pris 12 heures !!!

laisse tomber ton tsvector si c'est lui qui coute ! C'est un outil pour
ceux qui l'utilisent de facon accessoire.. toi c'est le coeur de métier
de ton applicatif vraissemblablement et les performance ne sont pas
suffisantes... alors travaille à optimiser cette fonctionnalité.



Ouaip.
C'est pas tout à fait aussi simple...
Le retirer est sans doute possible mais extrêmement compliqué !!!
Les recherches que je fais sont associé a un système de droit assez
complexe impossible (enfin pas simple) à reproduire avec un moteur
d'indéxation externe.

le partitionnement, ca va pas améliorer la fonction de recherche de ton
moteur... après si tu me dis que t'as 10 ans de mail et que tu veux
limiter la recherche aux X derniers mails ou à ceux des 30 derniers
jours, la en effet tu partitionne la donnée... ca allege le boulot pour
le SGBDR...



En fait, je me préparais plutôt à partitionner en fonction de compte
mail et pas de la date.

Etienne
pif34
Le #23845051
Le 10/10/2011 12:32, Etienne a écrit :
ton but c'est de faire un moteur de recherche dans des textes... une BD
c'est pas fait pour ca... il faut gérer une indexation au niveau
applicatif et utiliser le moteur relationnel pour des données
structurées et indexée proprement...



Hum.
Je faisais ca avant.
j'utilisais swish-e.



je fais du java, donc je parlerais dans cette techno:
soit tu fais ton propre process (idéalement une lemmatisation) qui
indexe par rapport à un ensemble de mot clés, et tu utilises un
antidictionnaire pour éviter les problème... a la fin dans ta base t'as
une table de lemme (termes) et une table de document et une table de
jointure.... tu peux retreindre à un tokenizer/chunker si tu sais pas
mieux faire...
du coup, une recherche c'est un ensemble de jointure sur l'ensemble,
avec de bons index, ca mouline vite...

sois tu utilise un moteur comme lucene qui mouline...

j'ai fait un analyseur de texte avec indexation et tout le bataclan en
moins de 2 semaines avec des problèmes de combinatoire bien supérieur au
langage communs (noms de molécules, traduction multilingue, 6 millions
de mots dans le dico) avec les contraintes de perf de 2003 sur un
mysql4.1 ...;



Sauf que c'était trop pénible à gèrer, mettre à jour, ...
En plus je me retrouvais avec autant de fichiers que de mails sur mon
serveur (je me parle même pas des pièces jointe...).
Un jour j'ai eu besoin de rebooter, le FSCK a pris 12 heures !!!



je te parles pas de rebooter, ou de fichiers... je te parle
d'indexation.. soit tu laisse faire une machine pasque tu sais pas
faire, soit tu code un truc propre et efficace, mais le partitionnement
ne résoudra pas ton probleme

Les recherches que je fais sont associé a un système de droit assez
complexe impossible (enfin pas simple) à reproduire avec un moteur
d'indéxation externe.



non, aucune raison, de nombreux CMS gerent les droits et s'appuient sur
lucene... tu sais pas faire, c'est une chose, c'est pas pour autant que
c'est impossible...

si c'est plus simple de le coder toi meme, vas y... c'est ce que j'ai
fait car aucun outil n'avais la qualité suffisante...

En fait, je me préparais plutôt à partitionner en fonction de compte
mail et pas de la date.



donc t'auras une table par utilisateur ? ca simplifie la gestion des
droits en effet... c'est crade au possible.... si on créé un fichier a
chaque fois qu'on veut pas gérer une clause de sécurité, ce serait vite
le bordel dans toutes les applications...

le partitionnement c'est pas fait pour ca, et ca changera absoluement
rien à ton problème de temps pour insérer nouveau tuple dans une base...

alors soit tu sais faire, soit tu prend un outil sur étagère que des
mecs ont su faire mieux que ce que tu peux espérer faire toit meme....
Etienne
Le #23845411
Le 10/10/2011 12:49, pif34 a écrit :

je fais du java, donc je parlerais dans cette techno:
soit tu fais ton propre process (idéalement une lemmatisation) qui
indexe par rapport à un ensemble de mot clés, et tu utilises un
antidictionnaire pour éviter les problème... a la fin dans ta base t'as
une table de lemme (termes) et une table de document et une table de
jointure.... tu peux retreindre à un tokenizer/chunker si tu sais pas
mieux faire...
du coup, une recherche c'est un ensemble de jointure sur l'ensemble,
avec de bons index, ca mouline vite...

sois tu utilise un moteur comme lucene qui mouline...

j'ai fait un analyseur de texte avec indexation et tout le bataclan en
moins de 2 semaines avec des problèmes de combinatoire bien supérieur au
langage communs (noms de molécules, traduction multilingue, 6 millions
de mots dans le dico) avec les contraintes de perf de 2003 sur un
mysql4.1 ...;

je te parles pas de rebooter, ou de fichiers... je te parle
d'indexation.. soit tu laisse faire une machine pasque tu sais pas
faire, soit tu code un truc propre et efficace, mais le partitionnement
ne résoudra pas ton probleme



ben oui.
moi je ne demande pas mieux que de laisser faire un applicatif, mais
j'ai rien trouvé qui puisse convenir à mes besoins.

non, aucune raison, de nombreux CMS gerent les droits et s'appuient sur
lucene... tu sais pas faire, c'est une chose, c'est pas pour autant que
c'est impossible...



Je n'ai pas dis pas possible j'ai dis pas simple...

si c'est plus simple de le coder toi meme, vas y... c'est ce que j'ai
fait car aucun outil n'avais la qualité suffisante...

donc t'auras une table par utilisateur ? ca simplifie la gestion des
droits en effet... c'est crade au possible.... si on créé un fichier a
chaque fois qu'on veut pas gérer une clause de sécurité, ce serait vite
le bordel dans toutes les applications...



Je n'ai pas tout compris, mais tu sembles t’exciter là !
La séparation de mes tables ne posera aucun problème a ma gestion de
droit puisque toutes mes tables héritent d'une table racine qui contient
le système de droit.
Je peux ainsi assez finement partager n'importe quelle donnée (et pas
seulement un mail) entre plusieurs utilisateurs.
Je ne sais pas si c'est au top comme solution, mais je sais que c'est
ultra souple et que ça convient parfaitement à mon besoin.

Si je n'avais mon petit problème d'IO (qui si ça se trouve est liée à la
customisation de la config de postgreSQL que j'ai faite) on n'aurai même
pas cette discussion. Car en lecture (si je coupe des écriture), je n'ai
aucun problème de performance.

le partitionnement c'est pas fait pour ca, et ca changera absoluement
rien à ton problème de temps pour insérer nouveau tuple dans une base...



Ben écoute le te le dirai bientot !

alors soit tu sais faire, soit tu prend un outil sur étagère que des
mecs ont su faire mieux que ce que tu peux espérer faire toit meme....



Les ts-vector sont typiquement un truc tout fait qui marche très bien !
J'utilise ca car effectivement, je ne pense pas pouvoir faire mieux !

Etienne
pif34
Le #23845401
Le 10/10/2011 13:54, Etienne a écrit :
Je n'ai pas tout compris, mais tu sembles t’exciter là !



je m'excite pas, mais t'essaye de faire un truc que tu sais pas faire,

tu demandes des infos sur un dispositif très pointus dans les SGBD: le
partitionnement alors que le problème est que tu ne maitrise pas les
fondements ... tu me dis que chaque utilisateur va avoir une table qui
"hérite". Visiblement, tu maitrise aucun fondement de modélisation
relationnelle ou objet...

Si t'as eu des cours de modélisation objet:

Voiture Moto héritent de Véhicule, parce qu'ils ont des propriétés
communes (dans véhicule) et d'autres spécifique...

toi tu me dis que la 206 immatriculée 24XY77 hérite de Voiture comme la
206 immatriculée 25XY77 et la 206... alors qu'elle n'ont aucune
propriété différentes...

tu va multiplier les tables alors qu'elles vont avoir exactement les
meme colonnes, c'est délirant en terme de modélisation relationnelle...

donc un conseil, suit des formations dans le domaine avant de te lancer
dans des trucs pareil et en attendant prend un soft sur étagère parceque
t'arriveras pas a faire un truc bétonné en n'ayant aucune connaissance
de base et en ayant juste apris un peu sur le tas...

Les ts-vector sont typiquement un truc tout fait qui marche très bien !
J'utilise ca car effectivement, je ne pense pas pouvoir faire mieux !



ben n'essaye pas d'optimiser plus: tu va faire empirer le problème dans
la mesure ou tu ne maitrise pas les notions de combinatoires dans le
SGBD....

je m'excite pas, mais faut pas demander ou sont les vitesses dans une F1
quand on vient de suivre sa première lecon de conduite !
SQLpro
Le #23850581
Finalement j'ai fait un article sur le sujet du partitionnement
comparant les solutions PG et SQL Server :
http://blog.developpez.com/sqlpro/p10378/langage-sql-norme/partitionner-une-table-comparaison-postg/

En sus tu trouvera de la matière sur l'intérêt du partitionnement dans
cet article :
http://blog.developpez.com/sqlpro/p9286/langage-sql-norme/partitionner-vos-tables-pour-ameliorer-l/

Enfin, découper ta table de manière verticale est une bonne chose.

A +

Le 10/10/2011 10:19, Etienne a écrit :
Le 08/10/2011 20:43, SQLpro a écrit :
J'espère que ceci vous aura aidé...



Oui.

Il est vrai que le concept même de partitions est un poil étrange.
Je pense qu'une base de données intelligente devrait être capable de
gérer le partitionnement toute seule sans qu'on ai besoin de le lui dire.

Il est un peu étrange de devoir de palucher à la main toute cette
segmentation alors que le SGBD devrait être capable de faire ça tout seul.

Bon dans mon cas j'ai pas trop le choix, je vais devoir m'y coller (et
pourtant ma table n'est pas très grande).
C'est une table qui contient les mails de l'entreprise où je bosse.
pour le moment il n'y a que 500.000 enregistrements et déjà j'ai
quelques problème de performances lorsque j'insère en même temps qu'un
autre user décide par exemple de déplacer 150 mails.

Les IO se mettent alors à exploser semble t-il.
Le problème ne semble arriver que si j'exécute des grosses requêtes
concurrentes sur une même table.

On m'a donc conseiller:
- de partitionner
- de séparer les champs static (sujet, contenu, ...) des champs
dymanique (is_mail_readed, idmailfolder, ...) dans deux tables séparées
afin de limiter l'impact des IO lors de la modification des champs
dynamique.

Donc ben même si c'est un gros boulot, je vais me lancer là dedans.
On vera bien:)

Etienne






--
Frédéric BROUARD - expert SGBDR et SQL - MVP SQL Server - 06 11 86 40 66
Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez.com
Enseignant Arts & Métiers PACA, ISEN Toulon et CESI/EXIA Aix en Provence
Audit, conseil, expertise, formation, modélisation, tuning, optimisation
*********************** http://www.sqlspot.com *************************
Publicité
Poster une réponse
Anonyme