Gezien dat veld key is in beide gevallen geïndexeerd, de complexiteitsindex-zoekopdracht zelf zou erg op elkaar lijken. Als de waarde van a zou zijn gehasht
, en opgeslagen in de indexstructuur.
Als we op zoek zijn naar de algehele prestatiekosten, zou de gehashte versie extra (verwaarloosbare) kosten met zich meebrengen voor het hashen van de waarde van a voordat deze overeenkomt met de waarde in de indexstructuur. Zie ook mongo/db/index /hash_access_method.h
Ook zou de gehashte index geen gebruik kunnen maken van compressie van indexprefixen ( WiredTiger) . Compressie van indexprefixen is vooral effectief voor sommige datasets, zoals datasets met een lage kardinaliteit (bijv. land), of datasets met herhalende waarden, zoals telefoonnummers, socialezekerheidscodes en geografische coördinaten. Het is vooral effectief voor samengestelde indexen , waarbij het eerste veld wordt herhaald met alle unieke waarden van het tweede veld.
Over het algemeen is er geen reden om een niet-bereikwaarde te hashen. Als u een Shard-sleutel wilt kiezen, houdt u rekening met de kardinaliteit , frequentie , en veranderingssnelheid van de waarde.
Gehashte index wordt vaak gebruikt voor een specifiek geval van sharding . Wanneer een shard-sleutel waarde is een monotoon toenemend/afnemend waarde, zou de distributie van gegevens waarschijnlijk slechts in één scherf terechtkomen. Dit is waar een gehashte shard-sleutel de distributie van schrijfbewerkingen zou kunnen verbeteren. Het is een kleine afweging om uw sharding-cluster aanzienlijk te verbeteren. Zie ook Hashed vs Ranged Sharding .
Of het het waard is, hangt af van de use case. Een aangepaste hash-waarde zou betekenen dat elke zoekopdracht naar de hash-waarde door een aangepaste hash-code, d.w.z. toepassing, zou moeten gaan.
Het voordeel van het gebruik van de ingebouwde hash-functie is dat MongoDB automatisch de hashes berekent bij het oplossen van query's met behulp van gehashte indexen. Daarom hoeven toepassingen geen hashes te berekenen.