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).
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 !
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 !
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
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.
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
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...
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
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.
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" a écrit dans le message de news: 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.
"pif34" <pif34@nospam.fr> a écrit dans le message de news:
4e9d29dc$0$4008$426a74cc@news.free.fr...
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.
"pif34" a écrit dans le message de news: 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 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.
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.
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.
"WebShaker" a écrit dans le message de news: 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.
Je ne suis pas sous postgress mais sous Oracle. Et sous Linux Redhat 5.5 64 bits.
"WebShaker" <etienne@tlk.fr> a écrit dans le message de news:
4ea5da5e$0$29148$426a74cc@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.
"WebShaker" a écrit dans le message de news: 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.
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...
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.
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.
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.
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.
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.
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" writes:
"pif34" a écrit dans le message de news: 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
"Stéphane" <no_mail@free.fr> writes:
"pif34" <pif34@nospam.fr> a écrit dans le message de news:
4e9d29dc$0$4008$426a74cc@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/
"pif34" a écrit dans le message de news: 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/
