Biorąc pod uwagę to pole key jest indeksowany w obu przypadkach, samo wyszukiwanie indeksu złożoności byłby bardzo podobny. Jako wartość a byłoby hasowane
i przechowywane w drzewie indeksów.
Jeśli szukamy całkowitego kosztu wydajności, wersja zaszyfrowana poniosłaby dodatkowy (nieistotny) koszt haszowania wartości a przed dopasowaniem wartości w drzewie indeksów. Zobacz także mongo/db/index /hash_access_method.h
Ponadto indeks haszowany nie będzie mógł korzystać z kompresji prefiksu indeksu ( WiredTiger) . Kompresja prefiksu indeksu jest szczególnie skuteczna w przypadku niektórych zestawów danych, takich jak te o małej liczności (np. kraj) lub z powtarzającymi się wartościami, takimi jak numery telefonów, kody ubezpieczenia społecznego i współrzędne geograficzne. Jest to szczególnie skuteczne w przypadku indeksów złożonych , gdzie pierwsze pole jest powtarzane ze wszystkimi unikalnymi wartościami drugiego pola.
Generalnie nie ma powodu, aby haszować wartość spoza zakresu. Aby wybrać klucz fragmentu, rozważ liczność , częstotliwość oraz szybkość zmian wartości.
Indeks haszowany jest powszechnie używany w konkretnym przypadku shardingu . Gdy klucz fragmentu wartość to monotonicznie wzrastające/malejące wartość, dystrybucja danych prawdopodobnie przejdzie tylko do jednego fragmentu. W tym miejscu zaszyfrowany klucz fragmentu mógłby poprawić dystrybucję zapisów. To drobny kompromis, który znacznie ulepszy twój klaster shardingu. Zobacz też Hashed vs Ranged Sharding .
To, czy warto, zależy od przypadku użycia. Niestandardowa wartość skrótu oznaczałaby, że każde zapytanie o wartość skrótu musiałoby przejść przez niestandardowy kod skrótu, tj. aplikację.
Zaletą korzystania z wbudowanej funkcji skrótu jest to, że MongoDB automatycznie oblicza skróty podczas rozwiązywania zapytań przy użyciu indeksów skrótu. Dlatego aplikacje nie muszą obliczać skrótów.
