Quels sont les avantages de T-arbres sur B +/- arbres?

voix
12

J'ai exploré les définitions de T-arbres et B / B + arbres. A partir de documents sur le web , je crois comprendre que B arbres réussissent mieux dans la mémoire hiérarchique, tels que les lecteurs de disque et de la mémoire cache.

Ce que je ne comprends pas est pourquoi T arbres ont été / sont utilisés, même pour la mémoire plat?

Ils sont annoncés comme espace alternative efficace aux arbres AVL.

Dans le pire des cas, tous les nœuds feuilles d'un T-arbre contiennent un seul élément et tous les noeuds internes contiennent le montant minimum autorisé, qui est proche de la pleine. Cela signifie que l'on utilise seulement la moitié de la moyenne de l'espace alloué. À moins que je ne me trompe, c'est la même utilisation que le pire des cas de B-arbres, lorsque les nœuds d'un arbre B sont à moitié plein.

En supposant que les deux arbres stockent les clés localement dans les noeuds, mais utiliser des pointeurs de se référer aux dossiers, la seule différence est que B arbres doivent stocker des pointeurs pour chacune des branches. Cela cause généralement jusqu'à 50% de frais généraux ou moins (plus de T-arbres), en fonction de la taille des touches. En fait, c'est proche de la surcharge attendue dans les arbres AVL, en supposant qu'aucun pointeur parent, les enregistrements intégrés dans les noeuds, les clés intégrés dans les dossiers. Est-ce le gain d'efficacité attendu qui nous empêche d'utiliser à la place B-arbres?

T-arbres sont généralement mis en œuvre sur le dessus des arbres AVL. AVL sont plus équilibrés que B arbres. Cela peut-il être lié à l'application de T-arbres?

Créé 29/01/2011 à 15:43
source utilisateur
Dans d'autres langues...                            


2 réponses

voix
3

Je peux vous donner une histoire personnelle qui couvre la moitié de la réponse, c'est la raison pour laquelle je l' ai écrit un code Pascal pour programmer B + arbres il y a 18 ans.

mon système cible était un PC avec deux lecteurs de disque, je devais stocker un index sur la mémoire non volatile et je voulais mieux comprendre ce que j'ai appris à l'université. Je suis très satisfait de la performance d'un ensemble commercial, probablement dBase III, ou un produit Fox, je ne me souviens pas.

de toute façon: je avais besoin de ces opérations:

  • Chercher
  • insertion
  • effacement
  • prochain point
  • article précédent

  • taille maximale de l'indice n'a pas été connu

  • afin que les données devaient résider sur le disque
  • chaque accès au soutien avait un coût élevé
  • la lecture d'un bloc entier le même coût que la lecture d'un octet

B + -trees fait ce petit PC lent vraiment voler à travers les données!

les deux avaient leafs pointeurs supplémentaires ont donc formé une liste doublement chaînée, pour les recherches séquentielles.

Créé 11/02/2011 à 23:49
source utilisateur

voix
2

En réalité, la différence réside dans le système que vous utilisez. Comme mon professeur à l'université a commenté: si votre problème réside dans le manque de mémoire, ou en pénurie de hdd déterminera quel arbre et dans lequel la mise en œuvre que vous utiliserez. Très probablement, il sera arbre B +.

Parce qu'il ya des centaines de mises en œuvre, par exemple avec 2direction file d'attente et une file d'attente de direction où vous avez besoin d'éléments de pensée en boucle, et il y a aussi plusieurs façons de stocker l'index et le récupérer déterminera les vrais inconvénients et minutes de toute mise en œuvre.

Créé 25/02/2011 à 09:02
source utilisateur

Cookies help us deliver our services. By using our services, you agree to our use of cookies. Learn more