que - mongodb español

Diferencia de rendimiento de Mongodb entre los índices Hash y Ascendente(¿Alguna razón para no usar el hash en un campo no ordenado?)

Question

En mongodb hay múltiples tipos de index . Para esta pregunta, me interesa el índice ascendente (o descendente) que se puede usar para la clasificación y el índice hash que, según la documentación, se utiliza principalmente con clusters fragmentados para admitir claves de fragmentos hash. distribución uniforme de datos "( fuente )

Sé que no puede crear un índice como: db.test.ensureIndex( { "key": "hashed", "sortOrder": 1 } ) porque db.test.ensureIndex( { "key": "hashed", "sortOrder": 1 } ) un error

{
"createdCollectionAutomatically" : true,
"numIndexesBefore" : 1,
"errmsg" : "exception: Currently only single field hashed index supported.",
"code" : 16763,
"ok" : 0
}

Mi pregunta:

Entre los índices:

1. db.test.ensureIndex( { "key": 1 } )

2. db.test.ensureIndex( { "key": "hashed" } )

Para la consulta db.products.find( { key: "a" } ) , ¿cuál es más eficaz ?, es la clave hashed O(1)

Cómo llegué a la pregunta:

Antes de que supiera que no podía tener índices de varias claves con hashed , creé un índice de la forma db.test.ensureIndex( { "key": 1, "sortOrder": 1 } ) , y al crearlo me pregunté si el índice de hash fue más eficaz que el ascendente (el hash generalmente es O(1) ). Dejé la clave como está ahora porque (como mencioné anteriormente) db.test.ensureIndex( { "key": "hashed", "sortOrder": 1 } ) no estaba permitido. Pero la cuestión de es el índice de hash más rápido para las búsquedas con una clave que permanecía en mi mente.

La situación en la que hice el índice fue:

Tenía una colección que contenía una lista ordenada de documentos clasificados por claves.

por ejemplo, {key: a, sortOrder: 1, ...} , {key: a, sortOrder: 2, ...} , {key: a, sortOrder: 3, ...} , {key: b, sortOrder: 1, ...} , {key: b, sortOrder: 2, ...} , ...

Como utilicé la key para clasificar y sortOrder para la paginación, siempre consulté el filtrado con un valor para la key y el uso de sortOrder para el orden de los documentos.

Eso significa que tuve dos posibles consultas:

• Para la primera página db.products.find( { key: "a" } ).limit(10).sort({"sortOrder", 1})
• Y para las otras páginas db.products.find( { key: "a" , sortOrder: { $gt: 10 } } ).limit(10).sort({"sortOrder", 1})

En este escenario específico, la búsqueda con O(1) para la clave y O(log(n)) para el sortOrder hubiera sido ideal, pero eso no estaba permitido.

Answer 1

Para la consulta db.products.find( { key: "a" } ) , ¿cuál es más eficaz?

Dado que la key campo está indexada en ambos casos, la búsqueda del índice de complejidad en sí sería muy similar. Como el valor de a sería hashed y almacenado en el árbol de índice.

Si buscamos el costo de rendimiento general, la versión con hash incurriría en un costo adicional (insignificante) de hashing del valor de a antes de que coincida con el valor en el árbol de índice. Véase también mongo/db/index/hash_access_method.h

Además, el índice de hash no podría utilizar la compresión de prefijo de índice (WiredTiger) . La compresión de prefijo de índice es especialmente efectiva para algunos conjuntos de datos, como aquellos con baja cardinalidad (por ejemplo, país) o con valores repetidos, como números de teléfono, códigos de seguridad social y coordenadas geográficas. Es especialmente efectivo para los índices compuestos , donde el primer campo se repite con todos los valores únicos del segundo campo.

¿Alguna razón para no usar hash en un campo no ordenado?

En general, no hay ninguna razón para calcular un valor que no sea de rango. Para elegir una clave de fragmento, considere la cardinality , la frequency y la tasa de cambio del valor.

El índice de hash se usa comúnmente para un caso específico de sharding . Cuando un valor de clave de fragmento es un valor monótonamente creciente / decreciente , es probable que la distribución de datos se incluya en un solo fragmento. Aquí es donde una clave de fragmento hash podría mejorar la distribución de escrituras. Es una compensación menor para mejorar enormemente tu grupo de fragmentación. Véase también Hashed vs Ranged Sharding .

¿vale la pena insertar un hash o valor aleatorio en el documento y usarlo para fragmentar en lugar de un hash generado en el _id?

Si vale la pena, depende del caso de uso. Un valor hash personalizado significaría que cualquier consulta para el valor hash tendría que pasar por un código hash personalizado, es decir, una aplicación.

La ventaja de utilizar la función hash incorporada es que MongoDB calcula automáticamente los hashes al resolver consultas mediante índices hash. Por lo tanto, las aplicaciones no necesitan calcular hashes.