MongoDB
Explica cómo MongoDB indexa arrays mediante índices multikey, qué consultas soportan y qué límites aparecen al combinar varios campos array.
Un índice se vuelve cuando indexa un campo que contiene un array. MongoDB crea entradas de índice para los elementos, permitiendo consultar valores dentro del array sin recorrer toda la colección.
db.products.createIndex({
businessId: 1,
tags: 1
});Documento:
{
businessId,
tags: ['coffee', 'organic', 'ground']
}El documento contribuye con varias claves asociadas a sus tags.
Los arrays representan datos repetidos dentro de un documento. Sin multikey, una query como:
{ businessId, tags: 'coffee' }tendría que examinar documentos. El índice permite localizar documentos que contienen un elemento.
Un documento con tres tags genera pocas entradas. Uno con cien mil elementos puede generar una enorme cantidad de claves y hacer costosas las escrituras.
1 documento
× N elementos indexados
→ múltiples index keysPor eso un array ilimitado es un problema de documento e índice.
{ tags: ['coffee', 'organic'] }Query:
{ tags: 'coffee' }El índice multikey soporta membership. $all puede requerir combinar bounds o trabajo adicional según query.
{
items: [
{ productId: A, quantity: 1 },
{ productId: B, quantity: 5 }
]
}Índice:
db.orders.createIndex({
'items.productId': 1,
'items.quantity': 1
});Las condiciones separadas pueden corresponder a elementos distintos. $elemMatch expresa que deben pertenecer al mismo elemento y puede permitir bounds más precisos:
{
items: {
$elemMatch: {
productId: A,
quantity: { $gte: 2 }
}
}
}Un compound index puede incluir un campo array junto a campos escalares:
{
businessId: 1,
'items.productId': 1,
createdAt: -1
}MongoDB restringe compounds donde más de un campo indexado es array en el mismo documento, porque la combinación cartesiana de elementos sería ambigua o explosiva.
Debes verificar el schema completo, no solo documentos de muestra. Una futura migración que convierta otro campo en array puede hacer inválidas escrituras o builds.
Una query sobre arrays puede necesitar sort adicional incluso si el campo está en el índice. La interacción depende de bounds, paths y si el sort comparte prefijos con campos multikey.
No asumas que { tags: 1, createdAt: -1 } ordena todas las consultas por tags sin revisar explain().
Covered queries con multikey tienen restricciones. Si la projection devuelve el propio array, el servidor normalmente necesita leer el documento. Una query sobre otro campo podría cubrirse bajo condiciones específicas.
Confirma ausencia de FETCH y totalDocsExamined: 0; no deduzcas cobertura por la definición del índice.
Si un array contiene el mismo valor varias veces, MongoDB evita algunas duplicaciones internas por documento, pero el diseño no debe depender de detalles de implementación. Los duplicados siguen afectando semántica y tamaño del documento.
$addToSet evita igualdad exacta en el array, no sustituye una colección con índice unique para una relación.
Un unique multikey index protege la combinación de claves entre documentos, pero permite repeticiones derivadas dentro del mismo documento bajo reglas específicas. No sirve para imponer “cada subdocumento del array tiene userId único dentro de este documento” de forma general.
Si necesitas esa invariantes, considera:
Sin $elemMatch, MongoDB puede usar bounds para una condición y aplicar la otra como filtro residual. Esto aumenta keysExamined y docsExamined.
Con $elemMatch, el planner sabe que condiciones deben aplicarse al mismo elemento y puede combinar bounds de forma más útil.
Access pattern:
órdenes de un negocio que contienen productId
ordenadas por fecha descendenteÍndice candidato:
db.orders.createIndex({
businessId: 1,
'items.productId': 1,
createdAt: -1
});Query:
db.orders.find({
businessId,
'items.productId': productId
}).sort({ createdAt: -1 });Debes medir si el sort se cubre, cuántas líneas tiene cada orden y si el reporte debería usar una colección de movimientos o datos derivados.
Modificar un array indexado puede añadir o eliminar muchas claves:
{ $push: { tags: { $each: manyTags } } }El coste incluye:
Wildcard indexes pueden indexar múltiples paths, incluyendo arrays según reglas específicas. Son útiles para schemas dinámicos, pero pueden generar gran cantidad de claves y no sustituyen índices deliberados para hot paths.
No produce las mismas claves que un valor null o missing.
El índice pasa a multikey automáticamente, cambiando comportamiento y métricas.
Pueden multiplicar complejidad y bounds.
Puede impedir creación o escritura.
Un único documento genera muchísimas claves.
Orden y matching dejan de ser coherentes.
El coste crece con cada elemento.
Combina condiciones de elementos diferentes.
El índice no protege la regla deseada.
Viola restricciones.
Multikey introduce límites.
keysExamined puede ser enorme aunque pocos documentos coincidan.
$elemMatch y filtros separados.isMultiKey e multiKeyPaths en explain.Un multikey index permite consultar arrays, pero cada elemento puede convertirse en trabajo de índice. $elemMatch, cardinalidad, compound restrictions, sort y coverage deben comprenderse antes de usarlo. Los arrays ilimitados no se vuelven sostenibles por estar indexados.
$elemMatch ayuda a los bounds?Índices unique, partial y sparse.