Dada una consulta estándar simple (sin limit() o sort() o cualquier aplicación sofisticada) que tenga una condición de filtro en dos campos (como en name y age en su ejemplo), para encontrar los documentos resultantes, MongoDB:
- hacer un análisis completo de la colección (lea todos los documentos de la colección completa, analice el BSON, encuentre los valores en cuestión, pruébelos con la entrada y devuelva/deseche cada documento):Esto es muy intenso en E/S y, por lo tanto, lento.
- usar un índice que contiene uno de los campos (utilice el árbol de índices para ubicar el subconjunto relevante de documentos seguido de un escaneo de ellos):dependiendo de su distribución de datos/selectividad de índices, esto puede ser muy rápido o apenas proporcionar algún beneficio (imagine un índice en
ageen un conjunto de datos de millones de personas entre 30 y 40 años --> cada búsqueda arrojaría una cantidad infinita de documentos). - usar dos índices que juntos contengan ambos campos en cuestión (cargue ambos índices, realice búsquedas clave y luego calcule la intersección de los resultados):De nuevo, dependiendo de su distribución de datos, esto puede o no brindarle un mejor rendimiento. Sin embargo, en la mayoría de los casos debería ser más rápido que el #2. Sin embargo, me sorprendería si fuera realmente 10 veces más lento que el n. ° 4 (como mencionaste).
- usar un índice compuesto (dos búsquedas clave posteriores conducen inmediatamente a los documentos requeridos):Esta será la opción más rápida de todas dado que requiere las operaciones menos y más baratas para llegar a los documentos correctos. Para garantizar el mayor nivel de reutilización (no el rendimiento, que no se verá afectado por esto), en general, debe comenzar primero con el campo más selectivo, por lo que, en su caso, probablemente
namey noagedado que muchas personas tendrán la mismaage(selectividad tan baja) en comparación conname(mayor selectividad). Pero esa elección también depende de su escenario concreto y de las consultas que pretenda ejecutar en su base de datos. Hay un artículo bastante bueno en la web sobre cómo definir mejor un índice compuesto teniendo en cuenta varios aspectos de su situación específica:https://emptysqua.re/blog/optimizing-mongodb-compound-indexes
Otros aspectos a considerar son:Las actualizaciones del índice tienen un precio determinado. Sin embargo, si lo único que le importa es la velocidad de lectura sin procesar y solo tiene algunas actualizaciones de vez en cuando, entonces debería buscar más índices o índices más grandes.
Y por último, pero no menos importante (!), el consejo básico bien usado en exceso:Cree un perfil completo de su sistema utilizando datos reales y quizás incluso escenarios de carga realistas. Y también siga midiendo a medida que sus datos/sistema cambien con el tiempo.
Lecturas adicionales:https://docs.mongodb.com/manual/core/query-optimization/index.html
https://dba.stackexchange.com/questions/158240/mongodb-index-intersection-does-not-eliminate-the-need-for-creating-compound-in
¿Intersección de índice frente a índice compuesto?
índice compuesto mongodb vs. intersección de índice
¿Qué importancia tiene el orden de los índices compuestos en el rendimiento de MongoDB?
En MongoDB, estoy usando una consulta grande, cómo crearé un índice compuesto o un índice único, por lo que mi tiempo de respuesta aumenta
