Arbre par représentation intervallaire

Le
I.G.LOG
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
Vidéos High-Tech et Jeu Vidéo
Téléchargements
Vos réponses
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
patrice
Le #14516141
"I.G.LOG" 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
Le #14516111
> 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
Le #14516101
"I.G.LOG" 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
Le #14516081
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
Le #14516061
>
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
Publicité
Poster une réponse
Anonyme