Ctrl+Alt+Shift+QQuery Regressions
हर query को एक स्थिर fingerprint मिलता है (Oracle sql_id-style) जो बदलते literal values के बावजूद टिका रहता है, ताकि "वही query" एक ही line बनी रहे, भले filter values अलग हों। NoSqlStudio per-fingerprint एक baseline सीखता है (EWMA/MAD), live stream को instance-wide देखता है, और जिस क्षण कोई query regress होती है यह पाँच levels पर बताता है क्यों — before/after metrics से लेकर AI root-cause narrative तक। यह अकेला IDE है जो यह MongoDB, Azure Cosmos DB (Mongo API) और AWS DocumentDB सब पर करता है।
ऐप में यह कहाँ रहता है: Monitoring ▾ → Query Regressions
एक DBA को Query Regressions की ज़रूरत क्यों है
एक slow-query log आपको बताता है कि कोई statement धीमा था। यह कभी नहीं बताता कि कौन-सी query, क्या यह हमेशा से ऐसी थी, क्या बदला, या इससे फ़र्क भी पड़ता है या नहीं — तो DBA रात 2 बजे logs grep करता रह जाता है, हाथ से correlate करता है, अनुमान लगाता है। Query Regressions इसी को ख़त्म करने के लिए है।
यह हर query को एक स्थिर पहचान देता है (एक fingerprint जो बदलते values के बावजूद टिका रहता है), सीखता है कि हर एक के लिए "normal" कैसा दिखता है, और पूरे instance को live देखता है। सवाल "क्या कुछ धीमा है?" से बदलकर बन जाता है "यही query अभी 74× धीमी हो गई, यह रहा वह plan जो बदला, और दो मिनट पहले एक index drop हुआ था।"
यह इसलिए मायने रखता है क्योंकि महँगी घटनाएँ चुपचाप वाली होती हैं: maintenance window में drop हुआ एक index, एक deploy जिसने query shape बदल दिया, data growth जिसने चुपके से एक threshold पार कर लिया, एक Cosmos bill जो दोगुना हो गया। इनमें से कोई आपको page नहीं करता — जब तक ग्राहक न करें। यह उन्हें regress होते ही पकड़ता है और कारण बताता है, MongoDB, Cosmos और DocumentDB सब पर समान रूप से।
और यह DBA की हक़ीक़त का सम्मान करता है: आपका laptop server नहीं है। आप अपने चुने हुए scope और window के लिए monitoring arm करते हैं; alerts आप तक Slack, Discord, Teams या OS पर पहुँचते हैं; history restarts के बाद भी बची रहती है; और AI वह root-cause summary लिख देता है जिसे वरना आप हाथ से जोड़ते। कम log खंगालना, तेज़ MTTR, कम 2 बजे वाले झटके।
यह क्या करता है
- हर query shape के लिए स्थिर sql_id-style fingerprint — MongoDB पर native queryHash, Cosmos/DocumentDB पर client-side shape-hash — ताकि एक query अलग-अलग literal values में भी एक ही पहचान बनाए रखे।
- Cross-engine by design: MongoDB / Atlas, Azure Cosmos DB (Mongo API) और AWS DocumentDB — एकमात्र tool जो तीनों पर regression RCA देता है।
- Instance-wide live capture: यह हर client की queries देखता है, इसलिए maintenance window में किए गए बिना घोषित बदलाव को भी पकड़ लेता है — न कि सिर्फ़ वे queries जो आप चलाते हैं।
- 5-level root cause: (1) before/after metrics, (2) execution-plan diff, (3) index / cardinality probes, (4) ±5 min के भीतर correlate किए गए DDL और deploy events, (5) आपके अपने LLM के साथ एक AI narrative।
- कारण को classify करता है: plan change, selectivity collapse, data growth, RU spike, या एक बिलकुल नया धीमा collection scan।
- Per-engine metric: MongoDB / DocumentDB पर p95 latency, Cosmos पर RU।
- DBA-driven monitoring: आप इसे screen पर arm करते हैं (पूरा instance या चुने हुए databases, वैकल्पिक रूप से scheduled); यह एक live recording dot के साथ Job Manager job के रूप में चलता है — आपका laptop server नहीं है।
- पुष्ट regressions पर alerting: native OS notification + webhook (URL से Slack, Discord और Microsoft Teams auto-detect), और एक re-alert interval जिसे आप seconds में सेट करते हैं।
- सब कुछ persist होता है: सीखी हुई baselines और alert history restarts के बाद भी बचती हैं (file + MongoDB mirror), इसलिए रात में मिली regression सुबह भी मौजूद रहती है — period से filter करें, read/unread मार्क करें, delete करें।
- One-click remediation: plan change पर plan cache clear करें, acknowledge करें, snooze करें, या explain plan खोलें।
चरण-दर-चरण
- 1
Monitoring ▾ → Query Regressions खोलें
Tab उन alerts के साथ खुलता है जो पहले इस connection के लिए fire हुए थे, database के अनुसार grouped। history पढ़ने के लिए कुछ भी configure करने की ज़रूरत नहीं।
- 2
जिस scope की परवाह है उसके लिए monitoring arm करें
Start पर click करें और पूरा instance या विशिष्ट databases चुनें, वैकल्पिक रूप से start/end schedule के साथ। यह Job Manager में एक job के रूप में register होता है और tab से स्वतंत्र रूप से चलता रहता है।
- 3
उदाहरण — एक "new slow query"
कई docs पर पहली बार दिखा collection scan तुरंत flag हो जाता है, किसी baseline की ज़रूरत नहीं। किसी unindexed field पर filter classic मामला है:
// unindexed field -> COLLSCAN over the whole collection db.orders.find({ promoCode: "BLACKFRIDAY" }) // → card: New slow query — shop.orders // plan: COLLSCAN · docs examined 1,550,000 · p95 642 ms · WARN - 4
उदाहरण — एक baseline regression
एक query जो अपनी सीखी हुई baseline के मुक़ाबले सस्ती थी, अचानक बहुत ज़्यादा महँगी हो जाती है। वही fingerprint, सिर्फ़ plan/cost बदला — जैसे एक index drop हुआ तो IXSCAN पलटकर COLLSCAN बन गया:
// same query, same fingerprint — only the plan changed baseline (35 samples): IXSCAN { userId:1, status:1 } p95 2.5 ms now: COLLSCAN p95 185.0 ms // → card: Plan regression — shop.orders // delta 74x · cause: plan-change · CRITICAL // what changed nearby: dropIndex idx_user_status (2 min before) - 5
Card पढ़ें + AI root cause पाएँ (Level 5)
Severity, fingerprint, latency और docs examined के लिए Baseline → Now, plan diff, query shape, और आस-पास क्या बदला। फिर अपने अपने LLM के साथ Level-5 analysis चलाएँ — यह सिर्फ़ fact sheet पढ़ता है और सबसे संभावित एकमात्र कारण + एक confidence score के साथ समाप्त होता है।
- 6
इसे ठीक करें, और अगली बार alert पाएँ
Plan cache clear करें या index जोड़ें; Settings ▸ Alerting में एक बार OS + Slack/Discord/Teams alerting सेट करें ताकि अगली regression आप तक जहाँ भी हों पहुँच जाए।
वास्तविक use cases
चुपचाप वाली regression
एक nightly job ने एक index drop कर दिया। रात 2 बजे एक find() ने 1.5M-doc collection पर IXSCAN → COLLSCAN पलट दिया। Card plan diff के साथ fire हुआ और dropIndex event 2 मिनट पहले correlate हुआ — एक ही screen पर root cause, कोई log खंगालना नहीं।
एक ख़राब deploy पकड़ें
एक release ने query shape बदल दिया जिससे उसने composite index इस्तेमाल करना बंद कर दिया। Regression मिनटों में पुष्ट हुई और Level-4 timeline ने deploy marker की ओर इशारा किया — on-call को page होने से पहले rollback कर दिया।
Cosmos bill spike
एक selectivity collapse के बाद किसी query की RU cost तिगुनी हो गई। before/after RU के साथ AI narrative ने month-end billing से पहले partition/index का fix दे दिया।
Maintenance window में बिना घोषित बदलाव
Instance-wide capture ने एक ऐसे database में regression flag किया जो planned change का हिस्सा नहीं था — out-of-scope safety banner ने इसे incident बनने से पहले सामने ला दिया।
अपने फ़ोन से triage
पुष्ट regressions namespace और delta के साथ Slack / Discord / Teams पर push होती हैं; जब तक यह टूटी रहती है re-alert interval याद दिलाता रहता है, फिर ठीक होते ही चुप हो जाता है।
FAQ
यह slow-query log से कैसे अलग है?
एक slow log आपको अलग-थलग lines देता है। Query Regressions हर query के लिए एक स्थिर पहचान, एक सीखी हुई baseline, पाँच levels पर classify किया गया कारण, DDL/deploys के साथ correlation, एक AI narrative — साथ ही alerting और history देता है। यह बताता है कि क्या बदला, न कि सिर्फ़ यह कि कुछ धीमा था।
क्या यह सचमुच Cosmos DB और DocumentDB पर काम करता है?
हाँ — यही तो बात है। MongoDB slow log पढ़ता है, Cosmos Azure diagnostic logs पढ़ता है (metric के रूप में RU), DocumentDB CloudWatch profiler पढ़ता है। तीनों पर वही fingerprint + RCA model।
क्या मुझे app खुला रखना पड़ेगा?
Monitoring तब चलता है जब NoSqlStudio खुला हो (tab खुला हो या न हो) और persisted baselines फिर से load करके restart के बाद भी टिका रहता है। एक headless 24/7 agent roadmap पर एक अलग product है।
Alerts कहाँ जाते हैं?
एक native OS notification साथ ही एक वैकल्पिक webhook। एक ही URL Slack, Discord या Microsoft Teams के लिए काम करता है — payload provider के अनुसार ढल जाता है। Re-alert interval (seconds में) नियंत्रित करता है कि अभी भी regressed query कितनी बार दोबारा notify करे।
AI step LLM को क्या भेजता है?
सिर्फ़ एक compact fact sheet (before/after metrics, plan diff, index findings, cardinality, query shape)। आप AI Registry के ज़रिए अपना provider/key लाते हैं; जब तक आप analysis नहीं चलाते कुछ भी बाहर नहीं जाता।