Angesichts dieses Feldes key Indiziert wird in beiden Fällen die Komplexitätsindex-Suche selbst wäre sehr ähnlich. Als Wert von a würde gehasht
werden , und im Indexbaum gespeichert.
Wenn wir nach den Kosten für die Gesamtleistung suchen, würde die gehashte Version zusätzliche (vernachlässigbare) Kosten für das Hashing des Werts von a verursachen bevor der Wert im Indexbaum abgeglichen wird. Siehe auch mongo/db/index /hash_access_method.h
Außerdem wäre der gehashte Index nicht in der Lage, die Indexpräfixkomprimierung ( WiredTiger) . Die Indexpräfixkomprimierung ist besonders effektiv für einige Datensätze, wie solche mit niedriger Kardinalität (z. B. Land) oder solche mit sich wiederholenden Werten, wie Telefonnummern, Sozialversicherungscodes und Geokoordinaten. Es ist besonders effektiv für zusammengesetzte Indizes , wobei das erste Feld mit allen eindeutigen Werten des zweiten Felds wiederholt wird.
Im Allgemeinen gibt es keinen Grund, einen Wert außerhalb des Bereichs zu hashen. Berücksichtigen Sie bei der Auswahl eines Shard-Schlüssels die Kardinalität , Häufigkeit , und Änderungsrate des Wertes.
Hash-Index wird häufig für einen bestimmten Fall von Sharding verwendet . Wenn ein Shard-Schlüssel -Wert ist ein monoton steigender/fallender Wert würde die Verteilung der Daten wahrscheinlich nur in einen Shard gehen. Hier könnte ein gehashter Shard-Schlüssel die Verteilung von Schreibvorgängen verbessern. Es ist ein kleiner Kompromiss, um Ihren Sharding-Cluster erheblich zu verbessern. Siehe auch Hashed vs. Fernkampf-Sharding .
Ob es sich lohnt, hängt vom Anwendungsfall ab. Ein benutzerdefinierter Hash-Wert würde bedeuten, dass jede Abfrage nach dem Hash-Wert einen benutzerdefinierten Hash-Code, d. h. eine Anwendung, durchlaufen müsste.
Der Vorteil bei der Verwendung der integrierten Hash-Funktion besteht darin, dass MongoDB die Hashes automatisch berechnet, wenn Abfragen mithilfe von Hash-Indizes aufgelöst werden. Daher müssen Anwendungen keine Hashes berechnen.
