परिचय
Query Regressions स्क्रीन को खोलने, उपयोग करने और सत्यापित करने में आपकी मदद के लिए एक चरण-दर-चरण गाइड — यह NoSqlStudio में अंतर्निहित परफ़ॉर्मेंस-रिग्रेशन और विसंगति (anomaly) डिटेक्टर है। Step 1 से अंत तक, क्रम में चलें। हर स्टेप आपको बताता है कि क्या करना है और आप क्या देखेंगे।
इस मैनुअल को कैसे पढ़ें
हर स्टेप में होता है:
- करें — सटीक क्रिया (क्लिक करें, टाइप करें, फलाँ-फलाँ कमांड चलाएँ)।
- देखें — स्क्रीन पर क्या होना चाहिए। यही आपका “पास / फ़ेल” है।
- क्यों — अतिरिक्त संदर्भ, केवल तभी जब यह मददगार हो (अगर जल्दी में हैं तो इसे छोड़ दें)।
Query Regressions क्या है
संकल्पना
एक स्थिर fingerprint, Oracle के sql_id जैसा
हर query shape को एक स्थिर fingerprint मिलता है जो रन-दर-रन कभी नहीं बदलता — ठीक वही विचार जो Oracle के sql_id का है। NoSqlStudio हर fingerprint के लिए एक रोलिंग baseline सीखता है और तब अलर्ट उठाता है जब वही query अधिक महँगी पड़ने लगती है: धीमा wall-clock, अधिक documents examined, अधिक RU, या एक ख़राब plan (उदाहरण के लिए IXSCAN → COLLSCAN)।
संकल्पना
एक स्क्रीन, तीन engines
यही स्क्रीन MongoDB, Azure Cosmos DB (Mongo API) और AWS DocumentDB पर काम करती है। कैप्चर instance-wide होता है — यह हर client और हर database से धीमी queries देखता है, न कि केवल उन्हें जो आप NoSqlStudio से चलाते हैं। यही वह चीज़ है जो मेंटेनेंस विंडो के दौरान किसी अघोषित बदलाव को पकड़ती है।
संकल्पना
रूट-कॉज़ विश्लेषण के पाँच स्तर
हर अलर्ट को परतों में समझाया जाता है: L1 before/after मेट्रिक्स · L2 plan diff · L3 investigators (indexes, collection stats, cardinality) · L4 ±5 मिनट की विंडो में सहसंबद्ध DDL/deploy घटनाएँ (“इसके धीमे होने से ठीक पहले क्या बदला”) · L5 एक AI विवरण।
शुरू करने से पहले
आप पूरे UI को डेमो डेटा के साथ और बिना किसी database के एक्सप्लोर कर सकते हैं (Stages 1–3)। लाइव कैप्चर (Stages 4–6) के लिए एक कनेक्शन चाहिए, और डेटा स्रोत engine पर निर्भर करता है:
- 1MongoDB — server slow-query log को
getLog:'global'के ज़रिए पढ़ता है। self-hosted replica sets और dedicated Atlas clusters पर काम करता है। Atlas shared tiers (M0/M2/M5) पर उपलब्ध नहीं, जोgetLogको ब्लॉक करते हैं। - 2Cosmos DB — Azure Log Analytics से diagnostic logs पढ़ता है। इसके लिए Cloud Credentials (Cosmos Optimizer) में Log Analytics जुड़ा होना चाहिए।
- 3DocumentDB — Amazon CloudWatch Logs से DocDB profiler स्ट्रीम पढ़ता है। इसके लिए cluster parameter group पर profiler सक्षम हो, CloudWatch में export हो, और Cloud Credentials में AWS credentials सेट हों।
- 4एक दूसरा टैब जहाँ आप shell कमांड चला सकें — Scratchpad या Mongo Shell — ताकि धीमी queries उत्पन्न की जा सकें।
पूरे वॉकथ्रू का अनुमानित समय: ~25 मिनट।
स्क्रीन खोलें (किसी database की ज़रूरत नहीं)
स्क्रीन खोलें और अंतर्निहित डेमो लोड करें ताकि किसी लाइव स्रोत को जोड़ने से पहले आप लेआउट सीख सकें।
Query Regressions खोलें
toolbar में, Monitoring ▼ → Query Regressions चुनें (कीबोर्ड शॉर्टकट Ctrl+Alt+Shift+Q)।
एक नया टैब खुलता है जिसमें बायीं ओर Query Regressions हेडर, एक master list, और दायीं ओर एक detail panel होता है।
डेमो डेटा लोड करें
अगर list खाली है, तो empty state में Load demo data पर क्लिक करें।
एक SHOP समूह के अंतर्गत दो नमूना अलर्ट दिखाई देते हैं: एक Plan regression — shop.orders और एक Selectivity collapse — shop.events। हेडर पर एक लाल 2 CRITICAL बैज दिखता है।
डेमो पूरी तरह मेमोरी में चलता है — कोई server नहीं, कोई permissions नहीं। यह सीखने का सबसे तेज़ तरीका है कि किसी card का हर सेक्शन क्या मायने रखता है।
एक अलर्ट चुनें
list में Plan regression — shop.orders card पर क्लिक करें।
detail panel भर जाता है। हेडर एक CRIT बैज, शीर्षक, और उसके नीचे fingerprint (एक स्थिर hash), namespace, और occurrence count दिखाता है।
एक अलर्ट की संरचना
detail panel के हर सेक्शन को ऊपर से नीचे पढ़ें — यह हर engine के लिए वही लेआउट है।
WHAT CHANGED (Level 1)
एक टेबल जिसमें Signal · Baseline · Now · Δ हो। MongoDB/DocumentDB के लिए मेट्रिक p95 duration (ms) है; Cosmos के लिए यह RU है। एक दूसरी row docs examined / returned दिखाती है। जब वे regress हुए हों तो “Now” और “Δ” कॉलम हाइलाइट हो जाते हैं (उदाहरण के लिए 2.6 → 197 = 75.8×)।
यही मुख्य बात है: वही query अब अपने ही सीखे गए baseline से कहीं अधिक महँगी पड़ रही है।
HOW IT CHANGED — plan diff (Level 2)
before/after plan, उदाहरण के लिए IXSCAN { userId:1, status:1 } ⇩ COLLSCAN। कोई हटा दिया गया index या एक ख़राब plan-cache entry यहाँ तुरंत दिख जाती है।
WHY — रूट कॉज़ (Level 3)
investigators से बुलेट निष्कर्ष: collection पर कौन-से indexes मौजूद हैं, क्या plan बदला, क्या plan-cache key बदली। हर बुलेट हरे (ok) या एम्बर (संदिग्ध) रंग में होता है।
WHAT CHANGED NEARBY (Level 4)
detection के ±5 मिनट के भीतर DDL और deploy घटनाओं की एक timeline — उदाहरण के लिए 2m before · dropIndex · shop.orders · idx_user_status।
यही “इसके धीमे होने से ठीक पहले क्या बदला” का उत्तर है। COLLSCAN में plan पलटने से दो मिनट पहले हटा दिया गया एक index लगभग निश्चित रूप से रूट कॉज़ है।
QUERY SHAPE और AI Root Cause (Level 5)
canonical shape (op, filter fields, sort fields), फिर एक AI Analysis panel जिसमें एक model picker और एक Run analysis बटन हो।
Run analysis पर क्लिक करें।
जब model काम करता है तो बटन चमकता है, फिर एक संक्षिप्त रूट-कॉज़ विवरण + remediation दिखता है, जो इस अलर्ट की fact sheet से लिखा जाता है।
विवरण modal खोलें
detail panel के ऊपर-दायें कोने में ··· बटन पर क्लिक करें।
एक modal खुलता है जिसमें एक fixed header (severity + title + fingerprint) और एक scrolling body होता है: वास्तविक executed command, एक Explain plan बटन, और एक AI सेक्शन।
संकल्पना
Command वह वास्तविक command है जो slow-query स्रोत से कैप्चर हुई — कोई पुनर्निर्माण नहीं — इसलिए Explain असली query shape को चलाता है।
सुझाई गई remediation
सबसे नीचे: Clear plan cache (MongoDB plan-change अलर्ट्स के लिए सक्षम), Acknowledge, और Snooze 24h।
Acknowledge पर क्लिक करें, फिर Snooze 24h, और list में अलर्ट की स्थिति बदलते हुए देखें।
ध्यान दें
Clear plan cache लाइव server पर लिखता है। यह हमेशा पहले पुष्टि माँगता है — पुष्टि से पहले डायलॉग पढ़ें, विशेषकर production पर।
दायरा और अघोषित-बदलाव गार्ड
दायरा बदलें
SCOPE बार में, एक database chip पर क्लिक करें (या All databases)।
list चयनित databases पर फ़िल्टर हो जाती है। All databases डिफ़ॉल्ट है और मेंटेनेंस विंडो के दौरान यही आप चाहते हैं।
detection हमेशा instance-wide चलता है। दायरा केवल यह फ़िल्टर करता है कि आप क्या देखते हैं — यह engine को हर database देखने से कभी नहीं रोकता।
out-of-scope critical बैनर
अगर आप दायरा संकीर्ण करते हैं और आपके फ़िल्टर से बाहर किसी database में कोई critical regression चलता है, तो एक चेतावनी बैनर दिखता है: “N critical regression(s) in databases outside your filter”।
यह उस क्लासिक घटना के विरुद्ध गार्ड है: एक बदलाव कहता है कि वह database X को छूता है, पर एक छिपी स्क्रिप्ट किसी अघोषित database Y को बदल देती है। बैनर Y को तब भी सामने ले आता है जब आप उसकी ओर देख ही नहीं रहे थे।
MongoDB पर लाइव कैप्चर
अब एक असली स्रोत जोड़ें। MongoDB को किसी credential सेटअप की ज़रूरत नहीं — यह server slow-query log को सीधे पढ़ता है।
एक replica set या dedicated Atlas cluster कनेक्ट करें
NoSqlStudio को किसी MongoDB replica set या एक dedicated Atlas cluster से कनेक्ट करें, फिर उस कनेक्शन पर Query Regressions खोलें।
हेडर लाइव स्थिति को live (हरा) दिखाता है।
ध्यान दें
Atlas shared tiers (M0/M2/M5) getLog admin command को ब्लॉक करते हैं, इसलिए लाइव स्थिति unavailable पढ़ेगी। किसी dedicated cluster या self-hosted replica set का उपयोग करें।
एक स्पष्ट रूप से ख़राब scan उत्पन्न करें
एक shell टैब में, किसी ऐसे field पर धीमा collection scan चलाएँ जिस पर कोई index न हो — किसी unindexed field पर sort करना पूरी collection पर COLLSCAN को बाध्य करता है:
use <database>
db.<collection>.find({}).sort({ <unindexedField>: -1 }).limit(25).toArray()query 100 ms से कहीं अधिक लेती है और पूरी collection को scan करती है।
New slow query card देखें
Query Regressions टैब पर वापस जाएँ और कुछ सेकंड प्रतीक्षा करें (slow log हर ~5 s पर पोल होता है)।
एक WARN card जिसका शीर्षक New slow query — <namespace> हो (कोड Q7) दिखता है, जिसमें plan COLLSCAN और एक उच्च docs examined गिनती हो।
कभी न देखी गई query जो पहले से ही एक बड़ा COLLSCAN है, उसे पहली नज़र में ही फ़्लैग कर दिया जाता है — किसी baseline की ज़रूरत नहीं। यह उन बदलावों के लिए गार्ड है जो मेंटेनेंस विंडो के दौरान आते हैं।
सिद्ध करें कि fingerprint स्थिर है (dedup)
बिल्कुल वही query कई बार और चलाएँ।
कोई नया card नहीं दिखता। दोहराव उसी अलर्ट में समा जाते हैं — समान fingerprint = समान पहचान।
यही स्थिर fingerprint का पूरा मकसद है: किसी query को दोबारा चलाने पर कभी डुप्लिकेट अलर्ट की बाढ़ नहीं आती। एक query = एक पहचान, sql_id जैसी।
सिद्ध करें कि एक अलग shape एक नया अलर्ट है
एक अलग shape के साथ COLLSCAN चलाएँ — किसी अलग unindexed field पर sort करें:
use <database>
db.<collection>.find({}).sort({ <anotherUnindexedField>: -1 }).limit(25).toArray()एक दूसरा, अलग card दिखता है जिसका fingerprint अलग हो। अलग shape = नई पहचान = नया अलर्ट।
Cosmos DB पर लाइव कैप्चर (RU मोड)
Cosmos में पोल करने के लिए कोई slow-query log नहीं है, इसलिए कैप्चर Azure Log Analytics से diagnostic logs पढ़ता है। मेट्रिक RU है, मिलीसेकंड नहीं।
Cloud Credentials में Log Analytics जोड़ें
किसी Cosmos DB (Mongo API) कनेक्शन पर, Cosmos Optimizer (Ctrl+Alt+Shift+O) → Configuration → Cloud Credentials खोलें, और Azure सेक्शन भरें: Cosmos account Resource ID और Log Analytics workspace ID। Save पर क्लिक करें।
एक हरी पुष्टि दिखती है (credentials saved … MetricsBridge promoted)।
ध्यान दें
Log Analytics एक सशुल्क tier है (ingestion + retention)। यही एकमात्र रास्ता है जो अन्य clients से queries देखता है — मुफ़्त header रास्ता केवल वही देखता है जो NoSqlStudio स्वयं चलाता है, जो अघोषित-बदलाव परिदृश्य के लिए पर्याप्त नहीं।
लाइव स्थिति की पुष्टि करें और एक महँगी query उत्पन्न करें
Cosmos कनेक्शन पर Query Regressions खोलें; पुष्टि करें कि स्थिति live पढ़ती है। फिर एक cross-partition या unindexed query चलाएँ जो RU खर्च करे।
Log Analytics द्वारा row को ingest करने के बाद (मिनटों का विलंब), एक card दिखता है जिसमें मुख्य मेट्रिक के रूप में RU का before/after हो।
संकल्पना
Cosmos RU मोड पर Explain उपलब्ध नहीं है — modal यह कहता है और आपको इसके बजाय RU मेट्रिक और Index Policy pane की ओर इंगित करता है।
DocumentDB पर लाइव कैप्चर
DocumentDB getLog का समर्थन नहीं करता, इसलिए कैप्चर CloudWatch Logs से DocDB profiler स्ट्रीम पढ़ता है। इसके लिए profiler सक्षम और AWS credentials चाहिए।
DocDB profiler सक्षम करें
AWS में, profiler = enabled और एक कम profiler_threshold_ms (उदाहरण के लिए 50) वाला एक कस्टम cluster parameter group बनाएँ, उसे लागू करें (एक reboot आवश्यक है), और cluster के Log exports to CloudWatch में profiler जोड़ें।
धीमे ops CloudWatch log group /aws/docdb/<cluster>/profiler में आने लगते हैं।
Cloud Credentials में AWS credentials सेट करें
DocumentDB कनेक्शन पर, Cosmos Optimizer (Ctrl+Alt+Shift+O) → Configuration → Cloud Credentials खोलें, और AWS DocumentDB सेक्शन भरें: Region, DocDB cluster identifier, और वैकल्पिक रूप से एक AWS profile (मशीन की डिफ़ॉल्ट credential chain का उपयोग करने के लिए खाली छोड़ दें)। नीचे स्क्रॉल करें और Save credentials पर क्लिक करें।
सेक्शन एक हरा CONFIGURED बैज दिखाता है, और इस कनेक्शन के लिए aws-documentdb MetricsBridge पंजीकृत हो जाता है।
संकल्पना
यह pane AWS DocumentDB और Azure Cosmos के बीच साझा है और प्रति कनेक्शन है — DocumentDB कनेक्शन पर AWS सेक्शन भरें, किसी Cosmos कनेक्शन पर Azure सेक्शन। हर कनेक्शन अपना अलग region/cluster रखता है, इसलिए अलग-अलग regions में कई DocDB clusters स्वतंत्र रूप से संभाले जाते हैं।
स्क्रीन खोलें और एक धीमा scan उत्पन्न करें
DocumentDB कनेक्शन पर Query Regressions खोलें (स्थिति live की पुष्टि करें), फिर एक shell टैब में एक धीमा COLLSCAN चलाएँ:
use <database>
db.<collection>.find({}).sort({ <unindexedField>: -1 }).limit(25).toArray()~15 s के भीतर एक New slow query card दिखता है, जिसमें plan COLLSCAN और एक व्युत्पन्न docs examined गिनती हो।
ध्यान दें
DocumentDB docsExamined को सीधे नहीं उत्सर्जित करता, इसलिए मान profiler execStats scan stage से व्युत्पन्न किया जाता है — unfiltered scans के लिए सटीक, और जब कोई stage filter rows को बाहर करता है तो एक निचली सीमा। एक कुशल index-only count (IXONLYSCAN) को जानबूझकर फ़्लैग नहीं किया जाता, भले ही वह थोड़ा धीमा हो — केवल वे COLLSCANs फ़्लैग होते हैं जो कई docs examine करते हैं।
दृढ़ता (persistence) और व्यवहार
स्थिति किसी reopen के बाद बनी रहती है
किसी अलर्ट को acknowledge या snooze करें, फिर Query Regressions टैब को बंद करके फिर से खोलें।
acknowledged/snoozed स्थिति और आपका दायरा चयन अब भी वहीं रहते हैं।
वही स्क्रीन, हर engine
स्क्रीन को बारी-बारी से एक MongoDB, एक Cosmos, और एक DocumentDB कनेक्शन पर खोलें। लेआउट, cards, पाँच RCA स्तर, और AI panel समान हैं — केवल मुख्य मेट्रिक (ms बनाम RU) और Explain की उपलब्धता भिन्न होती है।
सफ़ाई (जब आप समाप्त कर लें)
आपने जो भी अस्थायी परीक्षण collections बनाई थीं उन्हें drop करें:
use <database>
db.<collection>.drop()DocumentDB के लिए, अगर profiler केवल इस परीक्षण के लिए सक्षम किया गया था, तो आप इसे parameter group पर अक्षम कर सकते हैं और ingestion लागत रोकने के लिए CloudWatch log group को हटा सकते हैं। Cosmos के लिए, अगर आपको निरंतर कैप्चर की ज़रूरत नहीं है तो Log Analytics diagnostic settings को घटाएँ या अक्षम करें।
परीक्षण डेटा हट गया है और परीक्षण के लिए आपने जो भी सशुल्क cloud tiers सक्षम किए थे वे बंद कर दिए गए हैं।
आपने जो सत्यापित किया उसका सारांश
| चरण | विशेषता |
|---|---|
| 1 | Query Regressions खोलें और बिना किसी database के डेमो डेटा लोड करें |
| 2 | एक अलर्ट पढ़ें: L1 मेट्रिक्स, L2 plan diff, L3 निष्कर्ष, L4 निकटवर्ती घटनाएँ, L5 AI, विवरण modal, remediation |
| 3 | दायरा फ़िल्टर और out-of-scope critical बैनर (अघोषित-बदलाव गार्ड) |
| 4 | लाइव MongoDB कैप्चर: New slow query, स्थिर-fingerprint dedup, नया shape = नया अलर्ट |
| 5 | Log Analytics के ज़रिए लाइव Cosmos DB कैप्चर, मेट्रिक के रूप में RU के साथ |
| 6 | CloudWatch profiler स्ट्रीम के ज़रिए लाइव DocumentDB कैप्चर |
| 7 | स्थिति/दायरे की दृढ़ता और तीनों engines में एक सुसंगत स्क्रीन |