MongoDB
Explica cómo combinar colecciones con $lookup, igualdad simple o pipelines correlacionados, y qué costos introducen joins, cardinalidad e índices.
combina documentos de otra colección y añade las coincidencias como un array. Permite resolver relaciones durante una aggregation, pero no crea integridad referencial ni elimina el coste de consultar y transferir datos de ambas colecciones.
$lookup{
$lookup: {
from: 'customers',
localField: 'customerId',
foreignField: '_id',
as: 'customer'
}
}Cuando los datos relacionados viven en colecciones independientes, una lectura puede necesitar composición. Las alternativas son:
$in;$lookup dentro del servidor.$lookup es útil cuando la relación y el volumen justifican una pipeline, especialmente para reportes, administración o respuestas que deben combinar varios conjuntos.
cada documento local
→ busca coincidencias extranjeras
→ recibe un array
→ continúa la pipelineLa cardinalidad del documento local no cambia hasta que se aplica $unwind. Sin embargo, el tamaño del documento de salida puede aumentar mucho si hay muchas coincidencias.
db.orders.aggregate([
{ $match: { businessId, status: 'pending' } },
{ $sort: { createdAt: -1, _id: -1 } },
{ $limit: 20 },
{
$lookup: {
from: 'customers',
localField: 'customerId',
foreignField: '_id',
as: 'customer'
}
}
]);Filtrar y limitar antes reduce la cantidad de lookups cuando la semántica lo permite.
El campo extranjero necesita un índice compatible. _id ya está indexado, pero otros campos no necesariamente.
Permite condiciones más expresivas:
{
$lookup: {
from: 'inventory',
let: {
productId: '$productId',
branchId: '$branchId'
},
pipeline: [
{
$match: {
$expr: {
$and: [
{ $eq: ['$productId', '$$productId'] },
{ $eq: ['$branchId', '$$branchId'] }
]
}
}
},
{
$project: {
_id: 0,
stock: 1,
reserved: 1
}
}
],
as: 'inventory'
}
}let define variables del documento local y $expr las utiliza. El soporte de índices dentro de expresiones tiene condiciones y limitaciones; verifica el plan real.
Aunque esperes una sola coincidencia, el resultado es un array:
{ customer: [/* cero, una o varias coincidencias */] }Puedes convertirlo:
{
$unwind: {
path: '$customer',
preserveNullAndEmptyArrays: true
}
}Cero coincidencias indica referencia ausente o filtros incompatibles. Varias pueden indicar falta de índice unique en la identidad lógica.
Para una relación con muchas coincidencias:
{
$lookup: {
from: 'reviews',
localField: '_id',
foreignField: 'productId',
as: 'reviews'
}
}Reunir miles de reviews dentro de cada producto puede superar memoria o límite de documento. Usa pipeline con sort y limit para un subset:
pipeline: [
{ $match: { $expr: { $eq: ['$productId', '$$productId'] } } },
{ $sort: { createdAt: -1 } },
{ $limit: 3 }
]El conjunto completo debe paginarse por separado.
No existe una respuesta universal. Mide latencia, payload, frecuencia y cardinalidad.
Si una relación se consulta en casi todos los hot paths y tiene ownership y crecimiento acotados, depender siempre de lookup puede indicar un boundary demasiado normalizado.
Si la entidad es independiente, cambia con frecuencia o tiene cardinalidad alta, referencing y lookup ocasional pueden ser correctos.
El lado extranjero debe soportar la condición:
db.inventory.createIndex({
branchId: 1,
productId: 1
});También filtra el lado local con índices antes del lookup. Un índice ausente puede convertir el join en trabajo repetido por documento.
Revisa explain() y estadísticas de ejecución. El plan exacto puede variar por versión y motor de ejecución.
MongoDB soporta combinaciones con colecciones sharded bajo condiciones dependientes de versión. El coste puede incluir comunicación entre shards y routers.
Evalúa:
No asumas que un lookup localmente rápido tendrá el mismo coste distribuido.
db.orders.aggregate([
{
$match: {
businessId,
status: 'pending'
}
},
{
$sort: {
createdAt: -1,
_id: -1
}
},
{ $limit: 20 },
{
$lookup: {
from: 'customers',
let: {
customerId: '$customer.id',
businessId: '$businessId'
},
pipeline: [
{
$match: {
$expr: {
$and: [
{ $eq: ['$_id', '$$customerId'] },
{ $eq: ['$businessId', '$$businessId'] }
]
}
}
},
{
$project: {
_id: 1,
currentName: '$name',
active: 1
}
}
],
as: 'currentCustomer'
}
}
]);La orden ya contiene nameAtPurchase; el lookup solo se justifica si la pantalla necesita current state.
La condición extranjera debe incluir tenant cuando la colección lo requiera. Unirse solo por un identificador enviado o almacenado incorrectamente puede mezclar datos entre negocios.
No permitas al cliente elegir from, pipeline o paths arbitrarios.
Cada resultado sigue sujeto al límite BSON. Un lookup que adjunta arrays enormes puede fallar aunque los documentos originales sean pequeños.
Projection dentro de la pipeline extranjera reduce campos, pero no cardinalidad. Añade limit o cambia el access pattern.
Combinar $lookup y $unwind puede multiplicar documentos. Si luego sumas valores del documento local, podrías contarlos una vez por coincidencia.
Ejemplo:
1 orden × 3 pagos relacionados
→ total de orden aparece 3 vecesAgrupa cuidadosamente o calcula antes del unwind.
El array queda vacío; la aplicación no debe asumir índice 0.
Falta una regla unique o la relación no era one-to-one.
String y ObjectId no coinciden.
Para jerarquías existe $graphLookup; tiene otro modelo y límites.
Projection reduce payload.
Produce array vacío; no hay error automático.
Fragmenta el modelo y penaliza hot paths.
Multiplica scans.
Duplica métricas.
Supera memoria o tamaño BSON.
No protege existencia ni cascades.
Introduce riesgo de seguridad y red.
$lookup es composición de lectura, no integridad. Funciona bien con relaciones selectivas, índices adecuados y cardinalidad controlada. Antes de usarlo en un hot path, compara con embedding, batch queries y datos derivados, especialmente en clusters sharded.
$facet, $bucket y pipelines múltiples.