Vzhledem k tomu poli key je indexován v obou případech, samotné vyhledávání indexu složitosti by bylo velmi podobné. Jako hodnota a by bylo hašováno
a uloženy ve stromu indexu.
Pokud hledáme celkové náklady na výkon, hašovaná verze by si vyžádala další (zanedbatelné) náklady na hašování hodnoty a před porovnáním hodnoty ve stromu indexu. Viz také mongo/db/index /hash_access_method.h
Hašovaný index by také nemohl využít komprese předpon indexu ( WiredTiger) . Komprese předpon indexu je zvláště účinná pro některé soubory dat, jako jsou soubory s nízkou mohutností (např. země) nebo soubory s opakujícími se hodnotami, jako jsou telefonní čísla, kódy sociálního zabezpečení a zeměpisné souřadnice. Je zvláště účinný pro složené indexy , kde se první pole opakuje se všemi jedinečnými hodnotami druhého pole.
Obecně není důvod hašovat hodnotu mimo rozsah. Chcete-li vybrat zlomkový klíč, zvažte kardinalitu , frekvence a rychlost změny hodnoty.
Hašovaný index se běžně používá pro konkrétní případ sharding . Když útržkový klíč hodnota je monotónně rostoucí/klesající hodnota, distribuce dat by pravděpodobně šla pouze do jednoho fragmentu. To je místo, kde by hashovaný klíč mohl zlepšit distribuci zápisů. Je to malý kompromis, který výrazně vylepší váš sharding cluster. Viz také Hashed vs Ranged Sharding .
Zda se to vyplatí, záleží na případu použití. Vlastní hodnota hash by znamenala, že jakýkoli dotaz na hodnotu hash by musel projít vlastním hashovacím kódem, tj. aplikací.
Výhodou pro využití vestavěné hašovací funkce je, že MongoDB automaticky počítá haše při řešení dotazů pomocí hašovaných indexů. Aplikace tedy nemusí počítat hashe.