MongoDB
Explica cómo optimizar MongoDB desde access patterns, consultas, índices, proyecciones, tamaño de documentos, memoria, red y distribución de carga.
Optimizar MongoDB significa reducir el trabajo necesario para cumplir un requisito, no perseguir una métrica aislada. El orden correcto es medir el síntoma, localizar la capa responsable, cambiar una hipótesis y volver a medir.
SLO incumplido
→ endpoint y query shape
→ explain + profiler
→ schema/índice/query/pool/storage
→ prueba comparativa
→ despliegue y observaciónAgregar hardware o shards antes de corregir scans, documentos y acceso solo distribuye el problema.
Distingue:
“MongoDB está lento” no es una hipótesis accionable. Identifica endpoint, operación, frecuencia, tenant y momento.
Captura filtro, sort, projection, limit y collation reales. Usa:
db.orders.find(filter, projection)
.sort(sort)
.limit(20)
.explain('executionStats');Compara nReturned, keys/docs examined, bounds, FETCH y SORT. Un índice usado puede seguir recorriendo cientos de miles de claves.
Un buen índice combina equality, sort y range según la query. Evita:
Mide el coste en writes, cache y disco. Usa hidden indexes para retirar de forma reversible.
Un documento enorme obliga a leer y reescribir más datos. Revisa:
Aplican subset, bucket, outlier o referencias según workload. No normalices por dogma.
Devuelve solo lo necesario:
orders.find(filter, {
projection: {
status: 1,
total: 1,
createdAt: 1
}
});Reduce red y deserialización, pero no siempre evita leer documentos. Para eso necesita covered query compatible.
skip profundo obliga a recorrer resultados previos. Prefiere cursor pagination:
{
businessId,
$or: [
{ createdAt: { $lt: cursor.createdAt } },
{
createdAt: cursor.createdAt,
_id: { $lt: cursor.id }
}
]
}Con índice {businessId:1, createdAt:-1, _id:-1} y sort estable.
Reduce cardinalidad temprano:
$match primero cuando sea posible;$project campos necesarios;$unwind explosivo;$lookup;$facet;Optimizar un pipeline implica medir documentos entre stages, no solo duración total.
Writes lentos pueden deberse a:
Usa operadores atómicos y evita reemplazar documentos completos. Agrupa en batches razonables, no en una transacción enorme.
La query puede ser rápida en servidor pero el request esperar una conexión. Mide:
Reutiliza MongoClient. Un cliente por request crea tormentas y TLS overhead.
Relaciona p99 con cache eviction y disk reads. Mitigaciones:
No exige que toda la base quepa en RAM.
Un contador o documento global puede serializar writes. Alternativas:
Las transacciones no eliminan contention y pueden aumentar retries.
Considera sharding cuando un replica set optimizado no sostiene capacidad o localidad. Antes valida:
Scatter-gather multiplica una query ineficiente.
Usa datos y distribución representativos:
No compares una query aislada en laptop con producción.
skip profundo;El rendimiento surge de la combinación de schema, query shape, índices, pool, memoria, storage y topología. Optimiza el cuello medido y valida el resultado bajo distribución real. Más hardware es válido cuando el diseño ya es correcto; antes de eso solo compra tiempo.
Conexiones y pooling.