Предвид това поле key се индексира и в двата случая, самото търсене по индекс на сложност би било много подобно. Като стойност на a ще бъде хеширан
и се съхранява в дървото на индекса.
Ако търсим общите разходи за производителност, хешираната версия ще доведе до допълнителни (незначителни) разходи за хеширане на стойността на a преди съпоставяне на стойността в дървото на индекса. Вижте също mongo/db/index /hash_access_method.h
Освен това хешираният индекс няма да може да използва компресия на префикса на индекса ( WiredTiger) . Компресирането на префикса на индекса е особено ефективно за някои набори от данни, като такива с ниска кардиналност (напр. държава) или такива с повтарящи се стойности, като телефонни номера, кодове за социална сигурност и географски координати. Той е особено ефективен за съставни индекси , където първото поле се повтаря с всички уникални стойности на второто поле.
По принцип няма причина да се хешира стойност извън обхват. За да изберете шард ключ, помислете за кардиналност , честота и скорост на промяна от стойността.
Хешираният индекс обикновено се използва за конкретен случай на шардинг . Когато shard ключ стойността е монотонно нарастващ/намаляващ стойност, разпределението на данните вероятно ще отиде само в един шард. Това е мястото, където хешираният shard ключ би могъл да подобри разпределението на записите. Това е малък компромис, за да подобрите значително вашия клъстер за шардинг. Вижте също Хеширано срещу диапазонно шардинг .
Дали си струва зависи от случая на използване. Персонализирана хеш стойност би означавала, че всяка заявка за хеш стойността ще трябва да премине през персонализиран хеш код, т.е. приложение.
Предимството за използване на вградената функция за хеширане е, че MongoDB автоматично изчислява хешовете при разрешаване на заявки с помощта на хеширани индекси. Следователно приложенията не трябва да изчисляват хешове.
