Cuando trabajas con el aggregation framework de MongoDB y notas que tus consultas tardan más de lo esperado, necesitas datos reales para diagnosticar el problema. Analizar el rendimiento de un pipeline en MongoDB te permite saber cuánta memoria, CPU y tiempo consume cada etapa, sin depender de tu intuición. Esta guía te muestra cómo interpretar las estadísticas de ejecución cuando usas funciones personalizadas o consultas complejas.

¿Cómo activar el análisis de un pipeline en MongoDB?

En lugar de ejecutar tu pipeline directamente, le pides a MongoDB que lo analice y devuelva un reporte detallado. Para hacerlo, indicas la base de datos sobre la que trabajas y agregas el comando que activa la explicación con estadísticas de ejecución.

El resultado es un JSON con cada paso del pipeline, los recursos que consumió y la memoria que necesitó. Al inicio puede parecer intimidante por la cantidad de información, pero hay campos puntuales en los que vale la pena fijarte.

¿Qué hace el modo explain en MongoDB? Te entrega un reporte en JSON con cada etapa del pipeline, milisegundos consumidos, uso de memoria y si MongoDB tuvo que recurrir a disco. Sirve para diagnosticar consultas lentas con datos reales [01:05].

¿Qué muestra el reporte de ejecución paso a paso?

El primer bloque del JSON describe cómo MongoDB recupera la información. Abre un cursor sobre la colección y define qué campos necesita leer. Aquí aparece el campo que indicaste en tu pipeline y la etapa general de recolección [01:42].

Cuando no hay índices definidos en la colección, MongoDB se ve obligado a recorrerla por completo para obtener los datos. Si agregas índices, esa etapa desaparece y la ejecución es mucho más rápida. Es un buen recordatorio de por qué los índices importan tanto en producción.

Después vienen los valores por cada etapa que el pipeline atravesó:

• Tiempo de ejecución en milisegundos por etapa.
• Recursos de CPU que cada paso consumió.
• Tiempo muerto o tiempo en espera de una respuesta.
• Fases internas con la función o el área que MongoDB analizó.

En el ejemplo, el tiempo de espera fue cero, lo cual es una buena señal. Si ves valores altos en esa métrica, significa que tu pipeline está bloqueado esperando algo y conviene revisar la causa.

¿Qué métricas son las más importantes al analizar un pipeline?

Los resultados finales del reporte concentran la información más relevante. Estos son los tres valores que debes vigilar con atención.

Uso de memoria en aggregation framework

Por las características de los documentos de MongoDB, con objetos grandes y arrays dentro, el uso de memoria tiende a crecer exponencialmente. En el ejemplo de la clase, una consulta sobre la colección de Airbnb con un máximo de 5.600 documentos consumió un poco menos de 300 KB, un número razonable para ese volumen [03:35].

La señal de alerta aparece cuando ese consumo empieza a medirse en megas o gigas. Ahí es cuando tienes que rediseñar el pipeline o revisar si los operadores están bien aplicados.

¿Cuándo MongoDB usa el disco duro?

Si la memoria RAM no alcanza, MongoDB recurre al disco. El reporte indica si esto ocurrió o no. En el ejemplo no fue necesario, lo cual es ideal porque leer y escribir en disco es órdenes de magnitud más lento que operar en memoria.

Esta opción es configurable: puedes habilitarla o deshabilitarla en MongoDB según el caso de uso [04:00].

¿Por qué importa que MongoDB use disco al ejecutar un pipeline? Porque significa que tu consulta excedió la memoria disponible. Operar en disco es mucho más lento y suele indicar que el pipeline necesita filtros más tempranos o índices.

Milisegundos totales de ejecución

El tiempo total que toma el pipeline es el termómetro final. Si una consulta tarda más de lo aceptable para tu aplicación, este número te lo dirá con precisión.

¿Cómo impacta el filtro match en el rendimiento?

Vamos al experimento práctico. En el pipeline original, el operador match recuperaba todos los documentos con calificación mayor que cero y que estuvieran habilitados, lo que dejaba pasar prácticamente toda la colección a la siguiente etapa.

Al cambiar ese filtro a calificación mayor que 95, el conjunto que pasa a la siguiente etapa se reduce drásticamente y los milisegundos de ejecución bajan de inmediato [04:30]. Esto confirma una regla clave del aggregation framework: filtrar lo más temprano posible reduce la carga de las etapas siguientes.

Puedes aplicar este mismo método a tus pipelines:

1. Ejecuta el explain con tu pipeline actual.
2. Anota el uso de memoria y los milisegundos por etapa.
3. Modifica un parámetro o reordena un operador.
4. Vuelve a ejecutar y compara los resultados.

Este ciclo te da evidencia objetiva de si un cambio mejora o empeora el performance.

¿Por qué medir es mejor que asumir en consultas MongoDB?

La recomendación final es directa: no te guíes por el pálpito. Frases como "siento que está lento" o "creo que estamos en los recursos óptimos" no sirven cuando hay consultas complejas o grandes volúmenes de información [05:18].

Verifica con datos lo más científicos posibles que estás dentro de los rangos aceptables. El reporte del explain es justo eso: evidencia medible que te permite tomar decisiones técnicas con respaldo.

¿Has analizado alguna vez un pipeline lento en tu proyecto? Cuéntame en los comentarios qué métrica fue la que más te sorprendió.