Dado ese campo key está indexado en ambos casos, el índice de complejidad busca en sí mismo seria muy parecido. Como el valor de a sería hashed
y se almacena en el árbol de índices.
Si estamos buscando el costo de rendimiento general, la versión cifrada incurriría en un costo adicional (insignificante) de cifrar el valor de a antes de hacer coincidir el valor en el árbol de índice. Ver también mongo/db/index /hash_access_method.h
Además, el índice hash no podría utilizar compresión de prefijo de índice ( tigre con cable) . La compresión de prefijos de índice es especialmente eficaz para algunos conjuntos de datos, como aquellos con baja cardinalidad (p. ej., país) o aquellos con valores repetidos, como números de teléfono, códigos de seguridad social y coordenadas geográficas. Es especialmente efectivo para índices compuestos , donde el primer campo se repite con todos los valores únicos del segundo campo.
En general, no hay razón para aplicar hash a un valor que no sea de rango. Para elegir una clave de fragmento, considere la cardinalidad , frecuencia y tasa de cambio del valor.
El índice hash se usa comúnmente para un caso específico de sharding . Cuando una clave de fragmento el valor es un creciente/decreciente monotónicamente valor, la distribución de datos probablemente entraría en un solo fragmento. Aquí es donde una clave fragmentada con hash podría mejorar la distribución de las escrituras. Es una compensación menor para mejorar en gran medida su clúster de fragmentación. Ver también Fragmentación Hashed vs Ranged .
Si vale la pena, depende del caso de uso. Un valor hash personalizado significaría que cualquier consulta del valor hash tendría que pasar por un código hash personalizado, es decir, la aplicación.
La ventaja de utilizar la función hash integrada es que MongoDB calcula automáticamente los hash al resolver consultas mediante índices hash. Por lo tanto, las aplicaciones no necesitan calcular hashes.
