Ctrl+Alt+Shift+QQuery Regressions
Cada query recibe un fingerprint estable (estilo sql_id de Oracle) que sobrevive al cambio de valores literales — así "la misma query" sigue siendo una sola línea aunque cambien los valores del filtro. NoSqlStudio aprende un baseline por fingerprint (EWMA/MAD), observa el stream en vivo en toda la instancia y, en el instante en que una query regresiona, explica POR QUÉ en cinco niveles — desde las métricas antes/después hasta una narrativa de causa raíz por IA. Es el único IDE que hace esto en MongoDB, Azure Cosmos DB (Mongo API) y AWS DocumentDB por igual.
Dónde vive en la app: Monitoring ▾ → Query Regressions
Por qué un DBA necesita Query Regressions
Un slow-query log te dice que una sentencia fue lenta. Nunca te dice qué query, si siempre fue así, qué cambió, ni si importa — así que el DBA termina escarbando logs a las 2am, correlacionando a mano, adivinando. Query Regressions existe para terminar con eso.
Le da a cada query una identidad estable (un fingerprint que sobrevive al cambio de valores), aprende cómo es lo "normal" de cada una y observa toda la instancia en vivo. La pregunta deja de ser "¿hay algo lento?" y pasa a ser "esta query exacta se volvió 74× más lenta, este es el plan que cambió, y se eliminó un índice dos minutos antes".
Esto importa porque los incidentes caros son los silenciosos: un índice eliminado en una ventana de mantenimiento, un deploy que cambió el shape de la query, crecimiento de datos que cruzó un umbral sin avisar, una factura de Cosmos que se duplicó. Ninguno te avisa — hasta que lo hace el cliente. Esto los detecta en el instante en que regresionan y nombra la causa, en MongoDB, Cosmos y DocumentDB por igual.
Y respeta la realidad del DBA: tu laptop no es un servidor. Armas el monitoreo en el alcance y la ventana que elijas; las alertas te llegan por Slack, Discord, Teams o el SO; el historial sobrevive a los reinicios; y la IA escribe el resumen de causa raíz que armarías a mano. Menos escarbar logs, menor MTTR, menos sorpresas a las 2am.
Qué hace
- Fingerprint estable estilo sql_id por shape de query — queryHash nativo en MongoDB, shape-hash del lado del cliente en Cosmos/DocumentDB — así la query mantiene una sola identidad aunque cambien los valores.
- Cross-engine por diseño: MongoDB / Atlas, Azure Cosmos DB (Mongo API) y AWS DocumentDB — la única herramienta que da RCA de regresión en los tres.
- Captura en vivo instance-wide: ve las queries de TODOS los clientes, así detecta el cambio no declarado hecho en una ventana de mantenimiento — no solo las queries que tú corres.
- Causa raíz en 5 niveles: (1) métricas antes/después, (2) diff del plan de ejecución, (3) sondas de índice / cardinalidad, (4) eventos de DDL y deploy correlacionados en ±5 min, (5) una narrativa de IA con tu propio LLM.
- Clasifica la causa: cambio de plan, colapso de selectividad, crecimiento de datos, pico de RU, o un collection scan lento nunca visto.
- Métrica por engine: latencia p95 en MongoDB / DocumentDB, RU en Cosmos.
- Monitoreo dirigido por el DBA: lo armas en pantalla (instancia completa o bases elegidas, con agenda opcional); corre como job en el Job Manager con un punto de grabación en vivo — tu laptop no es un servidor.
- Alertas en regresiones confirmadas: notificación nativa del SO + webhook (Slack, Discord y Microsoft Teams autodetectados por la URL), con un intervalo de re-alerta que defines en segundos.
- Todo persiste: los baselines aprendidos y el historial de alertas sobreviven al reinicio (archivo + mirror MongoDB), así una regresión detectada de madrugada sigue ahí por la mañana — filtra por período, marca leído/no leído, elimina.
- Remediación en un clic: limpia el plan cache en un cambio de plan, reconoce, pospón (snooze), o abre el explain plan.
Paso a paso
- 1
Abre Monitoring ▾ → Query Regressions
La pestaña abre con las alertas que ya dispararon para esta conexión, agrupadas por base de datos. Nada que configurar para ver el historial.
- 2
Arma el monitoreo en el alcance que importa
Haz clic en Start y elige la instancia completa o bases específicas, opcionalmente con agenda inicio/fin. Se registra como job en el Job Manager y sigue corriendo independiente de la pestaña.
- 3
Ejemplo — una "new slow query"
Un collection scan nunca visto sobre muchos docs se señala al instante, sin necesidad de baseline. Un filtro en un campo sin índice es el caso clásico:
// campo sin índice -> COLLSCAN sobre toda la colección db.orders.find({ promoCode: "BLACKFRIDAY" }) // → card: New slow query — shop.orders // plan: COLLSCAN · docs examinados 1.550.000 · p95 642 ms · WARN - 4
Ejemplo — una regresión de baseline
Una query que era barata contra su baseline aprendido de repente cuesta mucho más. Mismo fingerprint, solo cambió el plan/costo — p.ej. se eliminó un índice y el IXSCAN pasó a COLLSCAN:
// misma query, mismo fingerprint — solo cambió el plan baseline (35 muestras): IXSCAN { userId:1, status:1 } p95 2.5 ms ahora: COLLSCAN p95 185.0 ms // → card: Plan regression — shop.orders // delta 74x · causa: plan-change · CRITICAL // qué cambió cerca: dropIndex idx_user_status (2 min antes) - 5
Lee el card + obtén la causa raíz por IA (Nivel 5)
Severidad, el fingerprint, Baseline → Ahora para latencia y docs examinados, el diff del plan, el shape de la query y qué cambió cerca. Luego corre el análisis Nivel 5 con tu LLM — lee solo el fact sheet y termina con la causa más probable + un score de confianza.
- 6
Arréglalo, y recibe alerta la próxima vez
Limpia el plan cache o crea el índice; configura la alerta SO + Slack/Discord/Teams una vez en Settings ▸ Alerting para que la próxima regresión te alcance donde estés.
Casos de uso reales
La regresión silenciosa
Un job nocturno eliminó un índice. A las 2am un find() pasó de IXSCAN → COLLSCAN en una colección de 1,5M docs. El card disparó con el diff de plan y el evento dropIndex correlacionado 2 min antes — causa raíz en una sola pantalla, sin escarbar logs.
Atrapa un mal deploy
Un release cambió el shape de la query y dejó de usar el índice compuesto. La regresión se confirmó en minutos y la timeline de Nivel 4 apuntó al marcador de deploy — rollback antes de que paginaran al on-call.
Pico de factura en Cosmos
El costo en RU de una query se triplicó tras un colapso de selectividad. El RU antes/después más la narrativa de IA dieron el fix de partición/índice antes del cierre de facturación.
Cambio no declarado en una ventana de mantenimiento
La captura instance-wide señaló una regresión en una base que no era parte del cambio planeado — el banner de fuera-de-alcance lo sacó a la luz antes de volverse incidente.
Triaje desde el celular
Las regresiones confirmadas van a Slack / Discord / Teams con el namespace y el delta; el intervalo de re-alerta sigue recordando mientras está roto, y se calla cuando se arregla.
FAQ
¿En qué se diferencia de un slow-query log?
Un slow log te da líneas aisladas. Query Regressions da identidad estable por query, baseline aprendido, la causa clasificada en cinco niveles, correlación con DDL/deploys, narrativa de IA — más alertas e historial. Te dice qué cambió, no solo que algo estuvo lento.
¿De verdad funciona en Cosmos DB y DocumentDB?
Sí — ese es el punto. MongoDB lee el slow log, Cosmos lee los diagnostic logs de Azure (RU como métrica), DocumentDB lee el profiler en CloudWatch. Mismo modelo de fingerprint + RCA en los tres.
¿Tengo que mantener la app abierta?
El monitoreo corre mientras NoSqlStudio está abierto (con la pestaña abierta o no) y sobrevive al reinicio recargando los baselines persistidos. Un agente headless 24/7 es un producto aparte en el roadmap.
¿A dónde van las alertas?
Una notificación nativa del SO más un webhook opcional. Una URL sirve para Slack, Discord o Microsoft Teams — el payload se adapta al proveedor. El intervalo de re-alerta (en segundos) controla cada cuánto re-notifica una query aún regresionada.
¿Qué envía al LLM el paso de IA?
Solo un fact sheet compacto (métricas antes/después, diff de plan, hallazgos de índice, cardinalidad, shape de la query). Traes tu propio proveedor/clave vía AI Registry; nada sale hasta que corres el análisis.