B-Tree vs Hash Tabelle

In MySQL ist ein Indextyp ein B-Baum, und der Zugriff auf ein Element in einem B-Baum erfolgt in logarithmisch amortisierter Zeit O(log(n)).

Der Zugriff auf ein Element in einer Hash-Tabelle erfolgt dagegen in O(1).

Warum wird keine Hash-Tabelle anstelle eines B-Baums verwendet, um auf Daten in einer Datenbank zuzugreifen?

Sie können nur über ihren Primärschlüssel in einer Hashtabelle auf Elemente zugreifen. Dies ist schneller als mit einem Baumalgorithmus ( O(1)anstelle vonlog(n) ), aber Sie können keine Bereiche auswählen ( alles dazwischen xundy ). Baumalgorithmen unterstützen dies, Log(n)während Hash-Indizes zu einem vollständigen Tabellenscan führen können O(n). Auch der konstante Overhead von Hash-Indizes ist normalerweise größer ( was in der Theta-Notation kein Faktor ist, aber immer noch existiert ). Außerdem sind Baumalgorithmen normalerweise einfacher zu warten, wachsen mit Daten, Skalierung usw.

Hash-Indizes arbeiten mit vordefinierten Hash-Größen, sodass Sie am Ende einige "Buckets" haben, in denen die Objekte gespeichert sind. Diese Objekte werden erneut durchlaufen, um wirklich das richtige in dieser Partition zu finden.

Wenn Sie also kleine Größen haben, haben Sie viel Aufwand für kleine Elemente, große Größen führen zu weiterem Scannen.

Heutige Algorithmen für Hash-Tabellen skalieren normalerweise, aber die Skalierung kann ineffizient sein.

Es gibt tatsächlich skalierbare Hashing-Algorithmen. Fragen Sie mich nicht, wie das funktioniert - es ist mir auch ein Rätsel. AFAIK entwickelten sie aus einer skalierbaren Replikation, bei der ein erneutes Hashing nicht einfach ist.

Seine genannt RUSH - R eplication U nder S calable H Veraschungs, und diese Algorithmen sind somit RUSH Algorithmen bezeichnet.

Es kann jedoch vorkommen, dass Ihr Index im Vergleich zu Ihren Hash-Größen eine tolerierbare Größe überschreitet und Ihr gesamter Index neu erstellt werden muss. Normalerweise ist dies kein Problem, aber bei riesigen Datenbanken kann dies Tage dauern.

Der Kompromiss für Baumalgorithmen ist gering und sie eignen sich für fast jeden Anwendungsfall und sind daher Standard.

Wenn Sie jedoch einen sehr genauen Anwendungsfall haben und genau wissen, was und nur was benötigt wird, können Sie Hashing-Indizes nutzen.

Tatsächlich scheint es, dass MySQL beide Arten von Indizes verwendet, entweder eine Hash-Tabelle oder einen B-Baum gemäß dem folgenden Link .

Der Unterschied zwischen der Verwendung eines B-Baums und einer Hash-Tabelle besteht darin, dass Sie mit der ersteren Spaltenvergleiche in Ausdrücken verwenden können, die die Operatoren =,>,> =, <, <= oder ZWISCHEN verwenden, während die letztere nur für verwendet wird Gleichheitsvergleiche , die die Operatoren = oder <=> verwenden.

Die zeitliche Komplexität von Hashtabellen ist nur für ausreichend große Hashtabellen konstant (es müssen genügend Buckets vorhanden sein, um die Daten zu speichern). Die Größe einer Datenbanktabelle ist nicht im Voraus bekannt, daher muss die Tabelle von Zeit zu Zeit erneut aufbereitet werden, um eine optimale Leistung einer Hashtabelle zu erzielen. Das Aufwärmen ist auch teuer.

Ich denke, Hashmaps skalieren nicht so gut und können teuer sein, wenn die gesamte Karte erneut aufbereitet werden muss.

Pick DB / OS basierte auf Hashing und funktionierte gut. Mit mehr Speicher heutzutage zur Unterstützung effizienter Hash-Tabellen mit geringer Dichte und redundantem Hashing zur Unterstützung bescheidener Bereichsabfragen würde ich sagen, dass Hashing möglicherweise noch seinen Platz hat (einige hätten lieber andere Formen der Ähnlichkeitsübereinstimmung außerhalb des Bereichs, wie Platzhalter und reguläre Ausdrücke ). Wir empfehlen außerdem das Kopieren, um Kollisionsketten zusammenhängend zu halten, wenn Speicherhierarchien große Geschwindigkeitsunterschiede aufweisen.