Givet det felt key er indekseret i begge tilfælde, selve kompleksitetsindekssøgningen ville være meget ens. Som værdien af a ville blive hashed
, og gemt i indekstræet.
Hvis vi leder efter de overordnede ydeevneomkostninger, vil den hasherede version pådrage sig en ekstra (ubetydelig) omkostning ved at hashe værdien af a før den matcher værdien i indekstræet. Se også mongo/db/index /hash_access_method.h
Også hashed indeks ville ikke være i stand til at bruge indekspræfikskomprimering ( WiredTiger) . Indekspræfikskomprimering er især effektiv for nogle datasæt, som dem med lav kardinalitet (f.eks. land), eller dem med gentagne værdier, som telefonnumre, socialsikringskoder og geo-koordinater. Det er især effektivt til sammensatte indekser , hvor det første felt gentages med alle de unikke værdier for andet felt.
Generelt er der ingen grund til at hash en ikke-områdeværdi. For at vælge en shard-nøgle skal du overveje kardinaliteten , frekvens , og ændringshastighed af værdien.
Hashed indeks bruges almindeligvis til et specifikt tilfælde af sharding . Når en shard nøgle værdien er en monotonisk stigende/faldende værdi, vil distributionen af data sandsynligvis kun gå i ét skår. Det er her, en hashed shard-nøgle ville være i stand til at forbedre distributionen af skrivninger. Det er en mindre afvejning at forbedre din skæringsklynge i høj grad. Se også Hashed vs Ranged Sharding .
Om det er det værd, afhænger af brugssagen. En tilpasset hash-værdi vil betyde, at enhver forespørgsel efter hash-værdien skal gå gennem en tilpasset hash-kode, dvs. applikation.
Fordelen ved at bruge den indbyggede hash-funktion er, at MongoDB automatisk beregner hasherne, når forespørgsler løses ved hjælp af hash-indekser. Derfor behøver applikationer ikke at beregne hash.