Givet det fältet key indexeras i båda fallen, själva sökningen i komplexitetsindex skulle vara väldigt lika. Som värdet på a skulle hashas
, och lagras i indexträdet.
Om vi letar efter den totala prestandakostnaden skulle den hashade versionen medföra en extra (försumbar) kostnad för att hasha värdet av a innan du matchar värdet i indexträdet. Se även mongo/db/index /hash_access_method.h
Dessutom skulle hashat index inte kunna använda indexprefixkomprimering ( WiredTiger) . Komprimering av indexprefix är särskilt effektivt för vissa datamängder, som de med låg kardinalitet (t.ex. land) eller de med upprepade värden, som telefonnummer, socialförsäkringskoder och geokoordinater. Det är särskilt effektivt för sammansatta index , där det första fältet upprepas med alla unika värden för det andra fältet.
I allmänhet finns det ingen anledning att hasha ett icke-intervallvärde. För att välja en skärvnyckel, överväg kardinalitet , frekvens , och förändringshastighet av värdet.
Hashed index används vanligtvis för ett specifikt fall av sharding . När en shard-nyckel värdet är en monotont ökande/minskande värde, skulle distributionen av data sannolikt bara gå i en skärva. Det är här en hashad shard-nyckel skulle kunna förbättra distributionen av skrivningar. Det är en liten kompromiss för att avsevärt förbättra ditt skärningskluster. Se även Hashad vs Ranged Sharding .
Om det är värt det beror på användningsfallet. Ett anpassat hashvärde skulle innebära att alla frågor om hashvärdet måste gå igenom en anpassad hashkod, dvs applikation.
Fördelen med att använda den inbyggda hashfunktionen är att MongoDB automatiskt beräknar hasharna när man löser frågor med hashade index. Därför behöver applikationer inte beräkna hash.