Bonjour à tous,
Il y a quelques temps, je m'étais interessé à la modélisation des arbres par
représentation intervallaire (sqlpro). Il y avait eu un débat ici à ce
sujet.
Si cette technique est très performante au niveau de l'interrogation, je ne
l'avais pas impémenté dans mon appli à cause du coût élevé lors de
l'insertion ou suppression d'un élément dans l'arbre.
J'ai fait aujourd'hui un test simple sur base MySQL 4.1.22 qui consiste
seulement à incrémenter un champ dans une table contenant plus de 100.000
tuples, avec le code suivant :
update documlg set QTE = QTE + 1 where IDDOCUM > 15000
pour effectuer cette requete, il a fallu plus de 20 secondes :-( Et la champ
QTE n'est pas indexé; je suppose que sur un champ indexé, le temps de
traitement sera encore plus long (il faut bien que la base mette à jour les
indexes)
Est ce que quelqu'un s'est interessé "de plus près" à cette technique
prometteuse et a réussi a optimiser l'insertion/suppression dans l'arbre ?
Merci à tous
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
patrice
"I.G.LOG" a écrit dans le message de news:4806fbe4$0$863$
Bonjour à tous, Il y a quelques temps, je m'étais interessé à la modélisation des arbres
par
représentation intervallaire (sqlpro). Il y avait eu un débat ici à ce sujet. Si cette technique est très performante au niveau de l'interrogation, je
ne
l'avais pas impémenté dans mon appli à cause du coût élevé lors de l'insertion ou suppression d'un élément dans l'arbre. J'ai fait aujourd'hui un test simple sur base MySQL 4.1.22 qui consiste seulement à incrémenter un champ dans une table contenant plus de 100.000 tuples, avec le code suivant : update documlg set QTE = QTE + 1 where IDDOCUM > 15000 pour effectuer cette requete, il a fallu plus de 20 secondes :-( Et la
champ
QTE n'est pas indexé; je suppose que sur un champ indexé, le temps de traitement sera encore plus long (il faut bien que la base mette à jour
les
indexes) Est ce que quelqu'un s'est interessé "de plus près" à cette technique prometteuse et a réussi a optimiser l'insertion/suppression dans l'arbre ? Merci à tous
peût être créer des intervalles avec suffisemment d'espace pour éviter de tout réorganiser à chaque insertion un peu comme pour les btree. donc l'intervalle initial devrait être choisi en fonction de la profondeur actuelle/prévue/nb fils prévu
"I.G.LOG" <iglog@free.fr> a écrit dans le message de
news:4806fbe4$0$863$ba4acef3@news.orange.fr...
Bonjour à tous,
Il y a quelques temps, je m'étais interessé à la modélisation des arbres
par
représentation intervallaire (sqlpro). Il y avait eu un débat ici à ce
sujet.
Si cette technique est très performante au niveau de l'interrogation, je
ne
l'avais pas impémenté dans mon appli à cause du coût élevé lors de
l'insertion ou suppression d'un élément dans l'arbre.
J'ai fait aujourd'hui un test simple sur base MySQL 4.1.22 qui consiste
seulement à incrémenter un champ dans une table contenant plus de 100.000
tuples, avec le code suivant :
update documlg set QTE = QTE + 1 where IDDOCUM > 15000
pour effectuer cette requete, il a fallu plus de 20 secondes :-( Et la
champ
QTE n'est pas indexé; je suppose que sur un champ indexé, le temps de
traitement sera encore plus long (il faut bien que la base mette à jour
les
indexes)
Est ce que quelqu'un s'est interessé "de plus près" à cette technique
prometteuse et a réussi a optimiser l'insertion/suppression dans l'arbre ?
Merci à tous
peût être créer des intervalles avec suffisemment d'espace pour éviter de
tout réorganiser à chaque insertion
un peu comme pour les btree.
donc l'intervalle initial devrait être choisi en fonction de la profondeur
actuelle/prévue/nb fils prévu
"I.G.LOG" a écrit dans le message de news:4806fbe4$0$863$
Bonjour à tous, Il y a quelques temps, je m'étais interessé à la modélisation des arbres
par
représentation intervallaire (sqlpro). Il y avait eu un débat ici à ce sujet. Si cette technique est très performante au niveau de l'interrogation, je
ne
l'avais pas impémenté dans mon appli à cause du coût élevé lors de l'insertion ou suppression d'un élément dans l'arbre. J'ai fait aujourd'hui un test simple sur base MySQL 4.1.22 qui consiste seulement à incrémenter un champ dans une table contenant plus de 100.000 tuples, avec le code suivant : update documlg set QTE = QTE + 1 where IDDOCUM > 15000 pour effectuer cette requete, il a fallu plus de 20 secondes :-( Et la
champ
QTE n'est pas indexé; je suppose que sur un champ indexé, le temps de traitement sera encore plus long (il faut bien que la base mette à jour
les
indexes) Est ce que quelqu'un s'est interessé "de plus près" à cette technique prometteuse et a réussi a optimiser l'insertion/suppression dans l'arbre ? Merci à tous
peût être créer des intervalles avec suffisemment d'espace pour éviter de tout réorganiser à chaque insertion un peu comme pour les btree. donc l'intervalle initial devrait être choisi en fonction de la profondeur actuelle/prévue/nb fils prévu
I.G.LOG
> peût être créer des intervalles avec suffisemment d'espace pour éviter de tout réorganiser à chaque insertion un peu comme pour les btree. donc l'intervalle initial devrait être choisi en fonction de la profondeur actuelle/prévue/nb fils prévu
Bonjour, Je voudrais appliquer cette méthode sur une table article qui contient actuellement 120.000 tuples, avec un nombre de niveaux pouvant aller jusqu'à 7 (actuellement... peut être plus dans l'avenir) J'ai l'impression que, dans ce cas, ce modèle va être difficilement exploitable :-( bien dommage compte tenu de la simplicité des requetes d'interrogation... En tous cas merci de ta réponse
> peût être créer des intervalles avec suffisemment d'espace pour éviter de
tout réorganiser à chaque insertion
un peu comme pour les btree.
donc l'intervalle initial devrait être choisi en fonction de la profondeur
actuelle/prévue/nb fils prévu
Bonjour,
Je voudrais appliquer cette méthode sur une table article qui contient
actuellement 120.000 tuples, avec un nombre de niveaux pouvant aller jusqu'à
7 (actuellement... peut être plus dans l'avenir)
J'ai l'impression que, dans ce cas, ce modèle va être difficilement
exploitable :-( bien dommage compte tenu de la simplicité des requetes
d'interrogation...
En tous cas merci de ta réponse
> peût être créer des intervalles avec suffisemment d'espace pour éviter de tout réorganiser à chaque insertion un peu comme pour les btree. donc l'intervalle initial devrait être choisi en fonction de la profondeur actuelle/prévue/nb fils prévu
Bonjour, Je voudrais appliquer cette méthode sur une table article qui contient actuellement 120.000 tuples, avec un nombre de niveaux pouvant aller jusqu'à 7 (actuellement... peut être plus dans l'avenir) J'ai l'impression que, dans ce cas, ce modèle va être difficilement exploitable :-( bien dommage compte tenu de la simplicité des requetes d'interrogation... En tous cas merci de ta réponse
patrice
"I.G.LOG" a écrit dans le message de news:480714e9$0$884$
> peût être créer des intervalles avec suffisemment d'espace pour éviter
de
> tout réorganiser à chaque insertion > un peu comme pour les btree. > donc l'intervalle initial devrait être choisi en fonction de la
profondeur
> actuelle/prévue/nb fils prévu > Bonjour, Je voudrais appliquer cette méthode sur une table article qui contient actuellement 120.000 tuples, avec un nombre de niveaux pouvant aller
jusqu'à
7 (actuellement... peut être plus dans l'avenir) J'ai l'impression que, dans ce cas, ce modèle va être difficilement exploitable :-( bien dommage compte tenu de la simplicité des requetes d'interrogation... En tous cas merci de ta réponse
si c'est un arbre binaire, qu'est ce qui t'empeche de prendre un intervalle 1-120K pour le sommet puis des intervalles de 60k pour le niveau suivant, 30k ensuite, etc ... ? si tu pense que ton fichier article peut difficilement doubler tu part en 1-240K au sommet
ce qui fait que s'il y a des réorginations à faire, elle se feront sur un sous ensemble de l'arbre et pas sur la totalité
"I.G.LOG" <iglog@free.fr> a écrit dans le message de
news:480714e9$0$884$ba4acef3@news.orange.fr...
> peût être créer des intervalles avec suffisemment d'espace pour éviter
de
> tout réorganiser à chaque insertion
> un peu comme pour les btree.
> donc l'intervalle initial devrait être choisi en fonction de la
profondeur
> actuelle/prévue/nb fils prévu
>
Bonjour,
Je voudrais appliquer cette méthode sur une table article qui contient
actuellement 120.000 tuples, avec un nombre de niveaux pouvant aller
jusqu'à
7 (actuellement... peut être plus dans l'avenir)
J'ai l'impression que, dans ce cas, ce modèle va être difficilement
exploitable :-( bien dommage compte tenu de la simplicité des requetes
d'interrogation...
En tous cas merci de ta réponse
si c'est un arbre binaire, qu'est ce qui t'empeche de prendre un intervalle
1-120K pour le sommet puis des intervalles de 60k pour le niveau suivant,
30k ensuite, etc ... ?
si tu pense que ton fichier article peut difficilement doubler tu part en
1-240K au sommet
ce qui fait que s'il y a des réorginations à faire, elle se feront sur un
sous ensemble de l'arbre et pas sur la totalité
"I.G.LOG" a écrit dans le message de news:480714e9$0$884$
> peût être créer des intervalles avec suffisemment d'espace pour éviter
de
> tout réorganiser à chaque insertion > un peu comme pour les btree. > donc l'intervalle initial devrait être choisi en fonction de la
profondeur
> actuelle/prévue/nb fils prévu > Bonjour, Je voudrais appliquer cette méthode sur une table article qui contient actuellement 120.000 tuples, avec un nombre de niveaux pouvant aller
jusqu'à
7 (actuellement... peut être plus dans l'avenir) J'ai l'impression que, dans ce cas, ce modèle va être difficilement exploitable :-( bien dommage compte tenu de la simplicité des requetes d'interrogation... En tous cas merci de ta réponse
si c'est un arbre binaire, qu'est ce qui t'empeche de prendre un intervalle 1-120K pour le sommet puis des intervalles de 60k pour le niveau suivant, 30k ensuite, etc ... ? si tu pense que ton fichier article peut difficilement doubler tu part en 1-240K au sommet
ce qui fait que s'il y a des réorginations à faire, elle se feront sur un sous ensemble de l'arbre et pas sur la totalité
JeAn-PhI
I.G.LOG a présenté l'énoncé suivant :
Bonjour à tous, Il y a quelques temps, je m'étais interessé à la modélisation des arbres par représentation intervallaire (sqlpro). Il y avait eu un débat ici à ce sujet. Si cette technique est très performante au niveau de l'interrogation, je ne l'avais pas impémenté dans mon appli à cause du coût élevé lors de l'insertion ou suppression d'un élément dans l'arbre. J'ai fait aujourd'hui un test simple sur base MySQL 4.1.22 qui consiste seulement à incrémenter un champ dans une table contenant plus de 100.000 tuples, avec le code suivant : update documlg set QTE = QTE + 1 where IDDOCUM > 15000 pour effectuer cette requete, il a fallu plus de 20 secondes :-( Et la champ QTE n'est pas indexé; je suppose que sur un champ indexé, le temps de traitement sera encore plus long (il faut bien que la base mette à jour les indexes) Est ce que quelqu'un s'est interessé "de plus près" à cette technique prometteuse et a réussi a optimiser l'insertion/suppression dans l'arbre ? Merci à tous
20 secondes pour modifier combien d'enreg ? 1 enreg modifé effectivement le temps est très long 85000 enregs modifée c'est largement acceptable
-- Cordialement JeAn-PhI
I.G.LOG a présenté l'énoncé suivant :
Bonjour à tous,
Il y a quelques temps, je m'étais interessé à la modélisation des arbres par
représentation intervallaire (sqlpro). Il y avait eu un débat ici à ce
sujet.
Si cette technique est très performante au niveau de l'interrogation, je ne
l'avais pas impémenté dans mon appli à cause du coût élevé lors de
l'insertion ou suppression d'un élément dans l'arbre.
J'ai fait aujourd'hui un test simple sur base MySQL 4.1.22 qui consiste
seulement à incrémenter un champ dans une table contenant plus de 100.000
tuples, avec le code suivant :
update documlg set QTE = QTE + 1 where IDDOCUM > 15000
pour effectuer cette requete, il a fallu plus de 20 secondes :-( Et la champ
QTE n'est pas indexé; je suppose que sur un champ indexé, le temps de
traitement sera encore plus long (il faut bien que la base mette à jour les
indexes)
Est ce que quelqu'un s'est interessé "de plus près" à cette technique
prometteuse et a réussi a optimiser l'insertion/suppression dans l'arbre ?
Merci à tous
20 secondes pour modifier combien d'enreg ?
1 enreg modifé effectivement le temps est très long
85000 enregs modifée c'est largement acceptable
Bonjour à tous, Il y a quelques temps, je m'étais interessé à la modélisation des arbres par représentation intervallaire (sqlpro). Il y avait eu un débat ici à ce sujet. Si cette technique est très performante au niveau de l'interrogation, je ne l'avais pas impémenté dans mon appli à cause du coût élevé lors de l'insertion ou suppression d'un élément dans l'arbre. J'ai fait aujourd'hui un test simple sur base MySQL 4.1.22 qui consiste seulement à incrémenter un champ dans une table contenant plus de 100.000 tuples, avec le code suivant : update documlg set QTE = QTE + 1 where IDDOCUM > 15000 pour effectuer cette requete, il a fallu plus de 20 secondes :-( Et la champ QTE n'est pas indexé; je suppose que sur un champ indexé, le temps de traitement sera encore plus long (il faut bien que la base mette à jour les indexes) Est ce que quelqu'un s'est interessé "de plus près" à cette technique prometteuse et a réussi a optimiser l'insertion/suppression dans l'arbre ? Merci à tous
20 secondes pour modifier combien d'enreg ? 1 enreg modifé effectivement le temps est très long 85000 enregs modifée c'est largement acceptable
-- Cordialement JeAn-PhI
I.G.LOG
> 20 secondes pour modifier combien d'enreg ? 1 enreg modifé effectivement le temps est très long 85000 enregs modifée c'est largement acceptable
Bonjour, il y avait au moins 100.000 enreg modifiés. Ce qui normal, mais ce temps n'est plus satisfaisant si l'utilisateur doit attendre 20 secondes chaque fois qu'il ajoute un article !! Encore merci
>
20 secondes pour modifier combien d'enreg ?
1 enreg modifé effectivement le temps est très long
85000 enregs modifée c'est largement acceptable
Bonjour,
il y avait au moins 100.000 enreg modifiés. Ce qui normal, mais ce temps
n'est plus satisfaisant si l'utilisateur doit attendre 20 secondes chaque
fois qu'il ajoute un article !!
Encore merci
> 20 secondes pour modifier combien d'enreg ? 1 enreg modifé effectivement le temps est très long 85000 enregs modifée c'est largement acceptable
Bonjour, il y avait au moins 100.000 enreg modifiés. Ce qui normal, mais ce temps n'est plus satisfaisant si l'utilisateur doit attendre 20 secondes chaque fois qu'il ajoute un article !! Encore merci
