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.
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.
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.
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.
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.
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.
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.
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.
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.
J'espère que ceci vous aura aidé...
J'espère que ceci vous aura aidé...
J'espère que ceci vous aura aidé...
Etienne wrote:
t'as pas droit au dirty read ? pourquoi de lock de tables ? 1 seul
client monotache ?
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.
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...
create table as select ...
par contre, ca prend pas les index et contraintes d'intégrité diverses...
ben tu veux les créer comment ?
Etienne wrote:
t'as pas droit au dirty read ? pourquoi de lock de tables ? 1 seul
client monotache ?
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.
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...
create table as select ...
par contre, ca prend pas les index et contraintes d'intégrité diverses...
ben tu veux les créer comment ?
Etienne wrote:
t'as pas droit au dirty read ? pourquoi de lock de tables ? 1 seul
client monotache ?
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.
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...
create table as select ...
par contre, ca prend pas les index et contraintes d'intégrité diverses...
ben tu veux les créer comment ?
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.
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.
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.
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.
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.
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...
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...
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...
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 !!!
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.
En fait, je me préparais plutôt à partitionner en fonction de compte
mail et pas de la date.
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 !!!
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.
En fait, je me préparais plutôt à partitionner en fonction de compte
mail et pas de la date.
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 !!!
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.
En fait, je me préparais plutôt à partitionner en fonction de compte
mail et pas de la date.
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
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...
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....
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
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...
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....
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
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...
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....
Je n'ai pas tout compris, mais tu sembles t’exciter là !
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 !
Je n'ai pas tout compris, mais tu sembles t’exciter là !
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 !
Je n'ai pas tout compris, mais tu sembles t’exciter là !
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 !
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
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
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