MongoDB
Introducción al Aggregation Pipeline para transformar documentos por etapas, filtrar, proyectar, agrupar, ordenar y combinar resultados.
Aggregation Pipeline es un sistema para transformar documentos mediante una secuencia ordenada de . Cada stage recibe documentos, realiza una operación y entrega documentos al siguiente.
collection
↓
$match
↓
$set / $project
↓
$unwind
↓
$group
↓
$sort
↓
resultadoLa pipeline no es solo una sintaxis para reportes. Permite filtrar, calcular, unir, reorganizar, agrupar y analizar datos dentro del servidor, evitando transferir grandes conjuntos a la aplicación para procesarlos manualmente.
Supón que necesitas ventas diarias por método de pago. Una implementación ingenua podría:
Esto transfiere datos innecesarios, consume memoria en la aplicación y duplica una capacidad que MongoDB ya ofrece.
Pipeline:
db.orders.aggregate([
{
$match: {
businessId,
status: 'confirmed',
confirmedAt: { $gte: start, $lt: end }
}
},
{
$group: {
_id: {
day: {
$dateTrunc: {
date: '$confirmedAt',
unit: 'day',
timezone: 'America/Bogota'
}
},
method: '$payment.method'
},
orderCount: { $sum: 1 },
revenue: { $sum: '$total' }
}
},
{
$sort: {
'_id.day': 1,
'_id.method': 1
}
}
]);input stream
→ cada stage cambia cantidad, forma u orden
→ el coste de stages posteriores depende de stages anterioresTres preguntas ayudan a diseñar:
Una pipeline funcional puede ser operacionalmente costosa si filtra tarde, expande arrays enormes o agrupa con cardinalidad alta.
Un stage opera sobre el flujo completo:
{ $match: { status: 'confirmed' } }Una expression calcula un valor dentro de un stage:
{
$set: {
subtotal: {
$multiply: ['$quantity', '$unitPrice']
}
}
}No confundas operadores de query con expressions. Algunos nombres se parecen, pero viven en contextos distintos.
db.orders.aggregate([
{ $match: { businessId } },
{
$project: {
customerName: '$customer.nameAtPurchase',
total: 1,
createdAt: 1
}
},
{ $sort: { createdAt: -1 } },
{ $limit: 20 }
]);Si solo necesitas filtro, projection, sort y limit, find() puede ser más simple. Aggregation se justifica cuando necesitas transformaciones, joins, grouping, window functions o múltiples salidas.
El orden cambia resultado y coste.
1.000.000 órdenes
→ $match reduce a 10.000
→ $group procesa 10.000Filtrar después del group obligaría a procesar el conjunto completo y puede cambiar la semántica.
Eliminar campos grandes reduce payload interno, pero no debes proyectar fuera campos requeridos por stages posteriores. El optimizador puede mover algunas operaciones; aun así, escribe pipelines legibles y verifica el plan.
Para un top 20, sort y limit temprano pueden reducir trabajo posterior, siempre que no alteren la pregunta.
El primer $match puede utilizar índices como una query normal. Un $sort temprano también puede aprovechar un índice compatible.
db.orders.createIndex({
businessId: 1,
status: 1,
confirmedAt: 1
});Si antes del $match calculas un campo o ejecutas un stage que cambia forma, quizá pierdas capacidad de utilizar el índice original.
Verifica con:
db.orders.explain('executionStats').aggregate(pipeline);Revisa:
COLLSCAN frente a IXSCAN;Algunos stages pueden producir resultados conforme reciben documentos. Otros necesitan acumular una parte importante antes de emitir.
$match;$project;$set;$unwind.$sort sin índice;$group;$bucket;Un cursor de salida no significa que toda la pipeline opere con memoria constante.
Stages como $group y $sort pueden superar límites de memoria y usar almacenamiento temporal según configuración, versión y opción allowDiskUse.
db.orders.aggregate(pipeline, {
allowDiskUse: true
});Permitir disco evita ciertos fallos, pero no vuelve barata una pipeline. Puede aumentar I/O, latencia y competencia por almacenamiento.
Primero reduce input, cardinalidad y campos.
Expressions respetan tipos. Estos documentos no son equivalentes:
{ total: Decimal128('100.00') }
{ total: 100 }
{ total: '100.00' }Un $sum sobre tipos inconsistentes puede producir resultados inesperados o requerir conversión.
{
$set: {
normalizedTotal: {
$convert: {
input: '$total',
to: 'decimal',
onError: null,
onNull: null
}
}
}
}La conversión durante cada consulta puede ser una solución temporal; el objetivo debe ser corregir el schema.
Expressions pueden distinguir o combinar null y missing de maneras específicas. Utiliza $ifNull, $type y validación explícita.
{
$set: {
displayName: {
$ifNull: ['$name', 'Sin nombre']
}
}
}No ocultes corrupción con defaults permanentes si el campo debería ser requerido.
db.orders.aggregate([
{
$match: {
businessId,
status: 'confirmed',
confirmedAt: { $gte: start, $lt: end }
}
},
{ $unwind: '$items' },
{
$group: {
_id: '$items.productId',
productName: { $last: '$items.nameAtPurchase' },
units: { $sum: '$items.quantity' },
revenue: {
$sum: {
$multiply: [
'$items.quantity',
'$items.unitPrice'
]
}
}
}
},
{ $sort: { revenue: -1 } },
{ $limit: 10 }
]);Flujo:
$match restringe tenant, estado y fecha.$unwind convierte cada item en una fila lógica.$group agrupa por producto.$sum calcula unidades e ingreso.$sort ordena.$limit conserva top 10.El coste depende de órdenes coincidentes y total de items, no solo del número de órdenes.
En Node.js:
const pipeline: Document[] = [
{ $match: { businessId, status: 'confirmed' } },
{ $group: { _id: '$payment.method', total: { $sum: '$total' } } }
];
const cursor = orders.aggregate(pipeline, {
allowDiskUse: true,
maxTimeMS: 10_000
});Construye stages mediante valores validados. No permitas que el cliente envíe una pipeline arbitraria.
Una pipeline puede leer, transformar y, con stages específicos, escribir en otras colecciones. La aplicación debe:
$lookup y colecciones permitidas.No la uses automáticamente para:
find resuelve mejor;Transfiere y acumula datos innecesarios.
$unwind multiplica trabajo antes de reducirlo.
$group o $lookup pueden explotar resultados.
Solo permite usar disco en ciertos stages; puede ser lento.
Dificulta pruebas y diagnóstico.
Una pipeline correcta puede comenzar con COLLSCAN.
Tipos mixtos producen métricas incorrectas.
explain('executionStats').Aggregation Pipeline es un flujo de transformación dentro del servidor. La calidad depende tanto de la semántica como del orden, cardinalidad, tipos, índices y memoria. Cada stage debe justificar qué recibe, qué produce y cuánto trabajo añade.
find es suficiente?allowDiskUse no es una optimización?$unwind sobre órdenes con muchos items?$match, $project y $set.