MongoDB tiene un excelente soporte para arreglos y ofrece mucha flexibilidad en su modo de documento. Por ejemplo, puede incrustar matrices en documentos y también incrustar documentos en matrices, etc. Sin embargo, trabajar con matrices tiene varios inconvenientes en MongoDB. En esta publicación, veremos algunos de los problemas que tiene MongoDB con los índices y las matrices.
Índices multiclave
En MongoDB, puede indexar un campo de matriz para crear una entrada de índice para cada elemento de la matriz. El índice resultante se denomina índice 'multiclave'. Los índices multiclave se pueden crear sobre valores escalares o documentos incrustados. Para obtener más información sobre los índices multiclave, consulte esta documentación.
Los índices multiclave, aunque útiles, tienen varias limitaciones:
- Si crea un índice multiclave compuesto, entonces tiene como máximo un campo que es una matriz.
- Un índice compuesto no puede ser una clave fragmentada.
- Un índice compuesto no puede ser un índice hash.
Uno de los aspectos más interesantes de los índices multiclave es cómo se calculan los límites de intersección del índice.
Límites de intersección del índice
Así es como la documentación de MongoDB define los límites de intersección del índice:
“Los límites de un escaneo de índice definen las partes de un índice para buscar durante una consulta. Cuando existen varios predicados sobre un índice, MongoDB intentará combinar los límites de estos predicados mediante intersección o composición para producir un escaneo con límites más pequeños.”
Consultas de rango en matrices
Comencemos con un ejemplo simple para ver cómo MongoDB calcula los límites del índice para consultas en matrices. Supongamos que tenemos los siguientes tres documentos en una colección:
{x: 65}
{x: 35}
{x: [12,95]}
Emitimos la siguiente consulta:
db.coll.find({x :{ $gt :22, $lt:55})
La consulta es bastante simple. Esperaría que la respuesta fuera {x:35} pero la consulta devuelve:
{x:35}
{x:[25,95]}
La razón proviene de cómo MongoDB trata con las matrices. El mismo elemento de la matriz no necesita cumplir ambas condiciones; siempre que haya un elemento que coincida con cada condición, es una coincidencia. Entonces, en este caso, los límites son [22, Infinity] e [-Infinity, 55]. Dado que no se usa un operador 'elemMatch', MongoDB no usa la intersección de índice. MongoDB no especifica cuál de estos rangos [22, Infinity] o [-Infinity, 55] se utilizará para la ejecución de la consulta.
Si queremos usar la intersección del índice, entonces necesitamos usar la siguiente consulta:
db.coll.find(x :{ $elemMatch:{$gt :22,$lt:55}})
Cuando usa esto, MongoDB cruza los límites del índice y usa [22, 55] como los límites. Como era de esperar, esta consulta no devuelve ningún resultado (elemMatch no coincide con matrices). Entonces, esencialmente, las consultas de rango en arreglos son bastante inútiles sin el operador $elemMatch.
Índices multiclave compuestos:mezcla de campos de matriz y no matriz
Considere una colección con los siguientes documentos:
{item: 35, prices:[250,35]}
......
{item: 106, prices:[1500,65]}
Agregaremos un índice compuesto en esta colección:
db.ensureIndex({item:1, prices:1});
Ahora ejecutemos una consulta simple:
db. coll. find({item: {$gt:12, $lt:65}});
La consulta parece bastante simple, ya que estamos usando un elemento que no es una matriz con un rango fijo. Espero que los límites de intersección del índice sean algo así como elemento:[[12,65] ] para la consulta; sin embargo, si ejecuta una explicación, verá esto:
"indexBounds" : {
"item" : [ [ -Infinity, 65 ] ],
"prices" : [ [ { "$minElement" : 1 }, { "$maxElement" : 1 } ] ]
},
El motivo es que MongoDB detecta que se trata de un índice de varias claves y no procesa la intersección de los límites del índice, independientemente del hecho de que su consulta no utilice ningún campo de matriz. La moraleja de la historia es que cuando mezcla campos de matriz y que no son de matriz en un índice, siempre vigile los límites de intersección de su índice. Lo más probable es que no sea eficiente.
