Discussion :

[Ikebukuro]

Bonjour aux forumeurs,

Je me demande comment sont créées les feuilles d'un reverse index.

Pour un b-tree normal, j'ai compris qu'on crée une feuille puis quand elle devient trop remplie, on crée une deuxième feuille etc etc.

Si j'ai bien lu les articles sur le Net, l'intérêt du reverse index est de pouvoir créer des lignes dans N feuilles en même temps sans devoir attendre que le process de la première transaction ait fini de travailler et passe la main au process suivant.

Ma question est donc : est-ce que à un instant t, l'index reverse contient 4, 5 ou 10 blocs feuilles, remplis à seulement 10% ou 50%, pour que les différents process puissent écrire en parallèle leurs données?
Si c'est le cas, leur génération et gestion est différente de celle d'un index b-tree non reverse... cela m'intrigue

J'attends vos réponses avec impatience!

[Ikebukuro]

Pas de réponse

[pachot]

bonjour,
Il n'y a rien de différent dans un reverse index, sauf que la valeur est inversée.
Si l'index est sur une valeur toujours croissante (par exemple venant d'une sequence) un index non reverse va remplir les blocs et passer au suivant quand le dernier bloc est plein. Un index reverse lui va avoir des valeurs qui vont être réparties dans tout l'index, donc avec des feuilles entre 50% et 100%
Donc même chose. C'est juste que l’algorithme de remplissage des blocs est différent lorsqu'on insère toujours une valeur plus grande: meilleur remplissage mais plus de contention sur le dernier bloc.
Cordialement,
Franck.

[Ikebukuro]

Bonsoir Franck,

Merci pour ta réponse mais je ne suis pas entièrement d'accord.

De ce que je comprends, dans un index classique B-Tree avec la valeur indexée étant un incrémental, on aura le scénario suivant : la feuille 1 se remplit puis, une fois remplie à 95% (c'est un exemple), on crée une feuille 2 qui est vide (en gardant la feuille 1 remplie à 95%) puis on remplit la feuille 2 puis on passe à la feuille 3 une fois la feuille 2 remplie à 95% etc etc.
Peut-être que sur ce point je me trompe et les gens me diront : après le split la feuille 1 est remplit seulement à 50% et 50% de ses données ont migré vers la feuille 2 et les nouvelles valeurs vont se répartir entre la feuille 1 et 2 --> impossible car c'est un incrémental qui est indexé donc les nouvelles valeurs n'iront jamais dans la feuille 1 mais toujours à la fin de la feuille 2.
J'en conclut donc que pour un index b-tree non reverse, les feuilles sont toujours remplies au max de leur capacité avant de passer à la feuille suivante.

En revanche je crois que c'est l'inverse qu'il faut ABSOLUMENT pour un index b-tree reverse. L'objectif est qu'à un instant t il puisse y avoir N process qui, en même temps, mettent à jours l'index reverse car c'est la définition même de l'index reverse : on stocke la valeur miroir DANS LE BUT de permettre à Oracle de mettre à jour N feuilles en même temps, ce qui est impossible avec un index classique indexant un incrémental. Ce qui signifie qu'à cet instant t on ait N feuilles qui ne soient pas remplies au max de leur capacité et donc que les process puissent écrire dedans; donc ces feuilles ne sont pas gérées comme celles d'un index b-tree classique.

Désolé si je ne suis pas clair et si je me fais des nœuds au cerveau mais j'essaye vraiment de comprendre.

[pachot]

Bonjour, oui c'est juste, mais je ne vois pas en quoi c'est différent de ce que je disais.
Il y a deux mécanismes de remplissage de blocs: remplissage plein pour le dernier bloc, 50-50 pour les autres
Et ceci quel que soit le type d'index. Le fait qu'il soit reverse fait que le valeurs sont dispersées, et c'est donc le 50-50 qui va se faire. Mais attention, ce n'est pas toujours mieux. Ok, il n'y a plus de contention, mais c'est un peu trop dispersé: moins de change de garder les blocs en cache.
Il est préférable de partitionner (by hash) l'index pour dsperser sur quelques partitions seulement, mais tout en gardant le remplissage plein du dernier bloc de chaque partition.

[mnitu]

Sur ce problématique lisez aussi "Introduction To Reverse Key Indexes: Part III (A Space Oddity)"

[Ikebukuro]

Hello mnitu,

Merci pour le lien, je vais l'imprimer