B-Tree vs table de hachage


103

Dans MySQL, un type d'index est un b-tree et l'accès à un élément d'un b-tree est en temps amorti logarithmique O(log(n)).

D'un autre côté, l'accès à un élément dans une table de hachage se fait O(1).

Pourquoi une table de hachage n'est-elle pas utilisée à la place d'un b-tree pour accéder aux données d'une base de données?


9
Les tables de hachage ne prennent pas en charge les requêtes de plage et ne peuvent pas augmenter ou réduire en douceur pendant le fonctionnement.
hmakholm a quitté Monica le

3
@HenningMakholm Pourquoi pas le hachage pour les colonnes qui n'ont pas besoin de requêtes de plage?
Pacerier

Réponses:


115

Vous ne pouvez accéder aux éléments que par leur clé primaire dans une table de hachage. C'est plus rapide qu'avec un algorithme d'arborescence ( O(1)au lieu delog(n) ), mais vous ne pouvez pas sélectionner de plages ( tout entre xety ). Les algorithmes d'arborescence prennent en charge cela Log(n)alors que les index de hachage peuvent entraîner une analyse complète de la table O(n). De plus, la surcharge constante des index de hachage est généralement plus importante ( ce qui n'est pas un facteur en notation thêta, mais elle existe toujours ). De plus, les algorithmes d'arbre sont généralement plus faciles à maintenir, à se développer avec les données, à l'échelle, etc.

Les index de hachage fonctionnent avec des tailles de hachage prédéfinies, vous vous retrouvez donc avec des «compartiments» dans lesquels les objets sont stockés. Ces objets sont à nouveau bouclés pour trouver vraiment le bon dans cette partition.

Donc, si vous avez de petites tailles, vous avez beaucoup de frais généraux pour les petits éléments, les grandes tailles entraînent une numérisation plus poussée.

Les algorithmes actuels des tables de hachage sont généralement mis à l'échelle, mais la mise à l'échelle peut être inefficace.

Il existe en effet des algorithmes de hachage évolutifs. Ne me demandez pas comment cela fonctionne - c'est un mystère pour moi aussi. AFAIK ils ont évolué à partir de la réplication évolutive où le re-hachage n'est pas facile.

Il s'appelle RUSH - R eplication U nder S calable H ashing , et ces algorithmes sont donc appelés algorithmes RUSH.

Cependant, il peut y avoir un point où votre index dépasse une taille tolérable par rapport à vos tailles de hachage et votre index entier doit être recréé. Ce n'est généralement pas un problème, mais pour des bases de données énormes, énormes, cela peut prendre des jours.

Le compromis pour les algorithmes d'arbre est petit et ils conviennent à presque tous les cas d'utilisation et sont donc par défaut.

Cependant, si vous avez un cas d'utilisation très précis et que vous savez exactement de quoi et seulement ce qui sera nécessaire, vous pouvez profiter des index de hachage.


Pouvez-vous expliquer plus en détail la reconstruction d'index? Cela signifie-t-il que pendant x jours pendant la reconstruction de l'index, la table est totalement indisponible pendant cette période?
Pacerier

cela dépend du système de base de données utilisé. la question ne couvrait que les aspects théoriques. je ne connais pas vraiment les détails de mise en œuvre des systèmes de base de données communs. mais généralement cela ne devrait pas être le cas car le deuxième index peut être construit alors que le premier est encore utilisé
The Surrican

"Vous ne pouvez accéder aux éléments que par leur clé primaire" - vous entendez par la valeur de la colonne qui a le droit d'index, que ce soit une clé primaire ou un autre type d'index?
Mark Fisher

90

En fait, il semble que MySQL utilise les deux types d'index soit une table de hachage ou un b-tree selon le lien suivant .

La différence entre l'utilisation d'un b-tree et d'une table de hachage est que le premier vous permet d'utiliser des comparaisons de colonnes dans les expressions qui utilisent les opérateurs =,>,> =, <, <= ou BETWEEN, tandis que le second n'est utilisé que pour comparaisons d'égalité qui utilisent les opérateurs = ou <=>.


9
C'est injuste. La meilleure réponse a le score le plus bas.
Андрей Беньковский

6
Ceci est exactement ce que je cherchais. Je me souciais de la façon dont cela affectait mes requêtes plutôt qu'une analyse technique.
Ben Dehghan

Oui! Cette réponse m'a le plus aidé.
Ron Ross

merci beaucoup, cela fait longtemps mais cette réponse m'aide beaucoup aussi.
Reham Fahmy

14

La complexité temporelle des tables de hachage n'est constante que pour des tables de hachage de taille suffisante (il doit y avoir suffisamment de compartiments pour contenir les données). La taille d'une table de base de données n'étant pas connue à l'avance, la table doit être remaniée de temps en temps pour obtenir des performances optimales d'une table de hachage. Le ressassement est également coûteux.


2
Le reshashing peut-il être effectué pendant que db est en ligne? Ou devons-nous verrouiller la table pour tout ressasser?
Pacerier

1
Pacerier, MySQL ne prend pas en charge les index de hachage. Il est théoriquement possible de modifier l'index alors que la base de données est encore en ligne (continuer à utiliser l'ancien index, créer un nouvel index, basculer vers le nouveau quand c'est fait) mais je ne sais pas ce que MySQL ferait s'ils implémentaient indices de hachage.
Emil Vikström

3
MySQL prend en charge les index de hachage, n'est-ce pas? : dev.mysql.com/doc/refman/5.5/en/index-btree-hash.html
Pacerier

Vous semblez avoir raison. C'était une nouvelle pour moi! Je dois essayer de suivre le développement :-) Alors vous êtes bien mieux que moi de répondre à votre question, mais comme je l'ai dit: c'est théoriquement possible.
Emil Vikström

Btw, pourquoi dites-vous qu '"un btree peut être facilement paginé sur le disque mais pas une table de hachage"? Une table de hachage ne pourrait-elle pas être stockée sur le disque car une simple recherche de clé suffirait?
Pacerier

6

Je pense que les Hashmaps ne sont pas également mis à l'échelle et peuvent être coûteux lorsque la carte entière doit être remaniée.


0

Pick DB / OS était basé sur le hachage et fonctionnait bien. Avec plus de mémoire ces jours-ci pour prendre en charge des tables de hachage clairsemées efficaces et un hachage redondant pour prendre en charge des requêtes à plage modeste, je dirais que le hachage peut encore avoir sa place (certains préféreraient avoir d'autres formes de correspondance de similitude sans plage, telles que les caractères génériques et les expressions rationnelles) ). Nous recommandons également la copie pour garder les chaînes de collision contiguës lorsque les hiérarchies de mémoire présentent de grandes différences de vitesse.

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.