मार्गदर्शिका

एक-से-कुछ संबंध मौजूद है जहाँ संबंधित डेटा सीमित, छोटा है और अक्सर एक साथ पढ़ा जाता है।

→मुख्य दस्तावेज़ के भीतर संबंधित डेटा को एक नेस्टेड ऑब्जेक्ट या ऐरे के रूप में एम्बेड करें।

क्यों: एकल पॉइंट रीड में सभी आवश्यक डेटा को पुनः प्राप्त करके पढ़ने के प्रदर्शन को अनुकूलित करता है, RU लागत और विलंबता को कम करता है। क्लाइंट-साइड जॉइन से बचाता है।

संदर्भ↗

एक-से-कई संबंध जहाँ "कई" पक्ष असीमित रूप से बढ़ता है या "एक" पक्ष से स्वतंत्र रूप से अपडेट होता है।

→संबंधित वस्तुओं को अलग दस्तावेज़ों के रूप में संग्रहीत करें और पैरेंट दस्तावेज़ के ID का संदर्भ के रूप में उपयोग करें।

क्यों: दस्तावेज़ों को 2 MB आकार सीमा से अधिक होने से रोकता है और बड़े एम्बेडेड ऐरे पर अपडेट के लिए उच्च RU लागतों से बचाता है।

संदर्भ↗

एक दस्तावेज़ में एक ऐरे होता है जो समय के साथ असीमित रूप से बढ़ सकता है, जिससे 2 MB दस्तावेज़ आकार सीमा का जोखिम होता है (जैसे, इवेंट लॉग, टिप्पणियाँ)।

→ऐरे को कई "बकेट" दस्तावेज़ों में विभाजित करें। जब एक बकेट आकार/वस्तु सीमा तक पहुँच जाए, तो एक नया बनाएँ।

क्यों: संबंधित डेटा के तार्किक समूहन को बनाए रखते हुए व्यक्तिगत दस्तावेज़ों के आकार को प्रबंधनीय रखता है।

कई-से-कई संबंध को मॉडलिंग करना, जैसे छात्र और पाठ्यक्रम, या लेख और टैग।

→सीमित संबंधों के लिए, दोनों तरफ संबंध डेटा को डुप्लिकेट करें (जैसे, छात्र दस्तावेज़ में पाठ्यक्रम ID, पाठ्यक्रम दस्तावेज़ में छात्र ID को एम्बेड करें)। असीमित के लिए, एक अलग "जोड़" या "एज" दस्तावेज़ कंटेनर का उपयोग करें।

क्यों: डीनोर्मलाइज़ेशन जॉइन की आवश्यकता के बिना दोनों क्वेरी दिशाओं (पाठ्यक्रम में छात्र, छात्र के लिए पाठ्यक्रम) के लिए अनुकूलन करता है। एक जॉइन कंटेनर असीमित मामलों के लिए है।

पदानुक्रमित डेटा (जैसे, संगठनात्मक चार्ट, उत्पाद श्रेणियाँ) को मॉडलिंग करना और एक नोड के सभी वंशजों के लिए क्वेरी करने की आवश्यकता होना।

→प्रत्येक दस्तावेज़ में सभी पूर्वज ID या नामों (पथ) का एक ऐरे संग्रहीत करें।

क्यों: एकल `ARRAY_CONTAINS` फ़िल्टर के साथ कुशल सबट्री क्वेरीज़ को सक्षम करता है, जिससे महंगी रिकर्सिव लुकअप से बचा जा सके।

एक दस्तावेज़ में एक असीमित ऐरे होता है (जैसे, ब्लॉग टिप्पणियाँ), लेकिन सबसे आम क्वेरी को केवल सबसे हाल के N आइटम की आवश्यकता होती है।

→मुख्य दस्तावेज़ में हाल के आइटम का एक सबसेट एम्बेड करें और सभी आइटम को अलग संदर्भित दस्तावेज़ों के रूप में संग्रहीत करें।

क्यों: प्रदर्शन और लागत के लिए प्राथमिक रीड पाथ को अनुकूलित करता है, जबकि आवश्यकता पड़ने पर भी पूर्ण डेटासेट तक पहुंच की अनुमति देता है।

एक इकाई के लिए अपरिवर्तनीय घटनाओं के अनुक्रम को संग्रहीत करना और वर्तमान स्थिति या विश्लेषणात्मक एग्रीगेट्स के लिए क्वेरी करने की आवश्यकता होना।

→घटनाओं को एक एकल कंटेनर में संग्रहीत करें जिसे इकाई ID द्वारा पार्टीशन किया गया हो। मैटेरियलाइज़्ड व्यू या एग्रीगेट्स को कंप्यूट और स्टोर करने के लिए Change Feed या Synapse Link का उपयोग करें।

क्यों: एक पूर्ण ऑडिट ट्रेल प्रदान करता है और राइट मॉडल को विभिन्न रीड मॉडल से अलग करता है, जिससे उच्च लचीलापन मिलता है।

किसी विशिष्ट समय पर संबंधित डेटा की स्थिति को संरक्षित करने की आवश्यकता है (जैसे, एक ऑर्डर पर ग्राहक का पता)।

→दस्तावेज़ में संबंधित डेटा की एक प्रति (स्नैपशॉट) एम्बेड करें, बजाय इसके कि इसे संदर्भित करें।

क्यों: संदर्भित डेटा में भविष्य के परिवर्तनों से दस्तावेज़ को अलग करके ऐतिहासिक सटीकता सुनिश्चित करता है।

उच्च-आवृत्ति टाइम-सीरीज़ डेटा (जैसे, IoT सेंसर रीडिंग) को इन्जेस्ट करना और समय-सीमा पर डिवाइस द्वारा क्वेरी करना।

→डिवाइस ID को पार्टीशन कुंजी के रूप में उपयोग करें। प्रत्येक रीडिंग के लिए एक दस्तावेज़ के बजाय रीडिंग को समय-बकेटेड दस्तावेज़ों (जैसे, प्रति घंटा या प्रति मिनट) में एग्रीगेट करें।

क्यों: दस्तावेज़ गणना और राइट RU को नाटकीय रूप से कम करता है, जबकि एक पार्टीशन के भीतर कुशल समय-सीमा क्वेरीज़ के लिए डेटा को सह-स्थानित करता है।

एकल परमाणु ट्रांजेक्शन के रूप में कई क्रिएट, अपडेट या डिलीट ऑपरेशंस करने की आवश्यकता है।

→SDK की TransactionalBatch सुविधा का उपयोग करें। सभी ऑपरेशंस को एक ही तार्किक पार्टीशन कुंजी को लक्षित करना चाहिए।

क्यों: एकल पार्टीशन के भीतर 100 ऑपरेशंस तक के लिए ACID गारंटी प्रदान करता है, यह सुनिश्चित करता है कि या तो सभी ऑपरेशंस सफल होते हैं या सभी एक साथ विफल होते हैं।

दस्तावेज़ों को एक विशिष्ट अवधि (जैसे, 30 दिन) के बाद एक कंटेनर से स्वचालित रूप से हटा दिया जाना चाहिए।

→कंटेनर पर Time to Live (TTL) सक्षम करें और डिफ़ॉल्ट `ttl` मान सेकंड में सेट करें (जैसे, 30 दिनों के लिए 2592000)। एक व्यक्तिगत दस्तावेज़ पर -1 का `ttl` डिफ़ॉल्ट को ओवरराइड करता है और समाप्ति को रोकता है।

क्यों: TTL एक नो-कॉस्ट सुविधा है जो बैकग्राउंड डिलीट ऑपरेशंस करने के लिए बचे हुए RU का उपयोग करती है, जिससे डेटा जीवनचक्र को प्रबंधित करने का एक कुशल, हैंड्स-ऑफ तरीका मिलता है।

Cosmos DB मेटाडेटा से जुड़े बड़े बाइनरी ऑब्जेक्ट्स (छवियां, वीडियो, दस्तावेज़ > 2 MB) को संग्रहीत करने की आवश्यकता है।

→बाइनरी ऑब्जेक्ट को Azure Blob Storage में संग्रहीत करें। Blob के URI को Cosmos DB दस्तावेज़ में मेटाडेटा के साथ संग्रहीत करें।

क्यों: Cosmos DB संरचित मेटाडेटा के लिए अनुकूलित है और इसकी 2 MB दस्तावेज़ सीमा है। Blob Storage बड़े ऑब्जेक्ट स्टोरेज के लिए एक लागत प्रभावी और स्केलेबल सेवा है।

एक ही डेटा को विभिन्न गुणों द्वारा क्वेरी करने की आवश्यकता होती है, जिससे अक्षम क्रॉस-पार्टीशन क्वेरीज़ होती हैं (जैसे, ग्राहक द्वारा ऑर्डर, फिर उत्पाद द्वारा क्वेरी)।

→Change Feed का उपयोग करके उसी डेटा के साथ एक दूसरा कंटेनर (एक मैटेरियलाइज़्ड व्यू) पॉपुलेट करें, लेकिन सेकेंडरी क्वेरी प्रॉपर्टी द्वारा पार्टीशन किया गया हो।

क्यों: कंप्यूट को रीड टाइम से राइट टाइम में बदलता है, जिससे कई एक्सेस पैटर्न के लिए कुशल, सिंगल-पार्टीशन क्वेरीज़ सक्षम होती हैं।

ट्रांजेक्शनल वर्कलोड को प्रभावित किए बिना लाइव ऑपरेशनल डेटा पर जटिल विश्लेषणात्मक क्वेरीज़ (एग्रीगेशन, जॉइन) चलाने की आवश्यकता है।

→Cosmos DB कंटेनर पर Azure Synapse Link सक्षम करें। Synapse serverless SQL या Spark पूलों का उपयोग करके कंटेनर के एनालिटिकल स्टोर के खिलाफ विश्लेषणात्मक क्वेरीज़ चलाएं।

क्यों: एक नो-ETL, क्लाउड-नेटिव HTAP समाधान प्रदान करता है। कॉलमिनर एनालिटिकल स्टोर के खिलाफ क्वेरीज़ ट्रांजेक्शनल RU का उपभोग नहीं करती हैं और अत्यधिक प्रदर्शनकारी होती हैं।

डेटा परिवर्तनों के जवाब में स्केलेबल, विश्वसनीय और सर्वरलेस तरीके से डाउनस्ट्रीम क्रियाओं को ट्रिगर करने की आवश्यकता है।

→Cosmos DB ट्रिगर के साथ एक Azure Function का उपयोग करें। ट्रिगर स्वचालित रूप से Change Feed Processor लाइब्रेरी का लाभ उठाता है।

क्यों: यह इवेंट-ड्रिवन आर्किटेक्चर के लिए अनुशंसित पैटर्न है। यह स्वचालित स्केलिंग, चेकपॉइंटिंग और पार्टीशन लीज़ प्रबंधन प्रदान करता है।

संदर्भ↗

एक ऑपरेशन को डेटाबेस को परमाणु रूप से अपडेट करना चाहिए और एक मैसेजिंग सिस्टम (जैसे, Service Bus, Event Hubs) को एक संदेश प्रकाशित करना चाहिए।

→डेटाबेस राइट करें। प्रतिबद्ध परिवर्तन को विश्वसनीय रूप से पढ़ने और संबंधित संदेश को प्रकाशित करने के लिए एक Change Feed प्रोसेसर का उपयोग करें, जिसमें रिट्राई लॉजिक हो।

क्यों: अविश्वसनीय दोहरे राइट्स और वितरित ट्रांजेक्शन की आवश्यकता से बचाता है। Change Feed एक टिकाऊ आउटबॉक्स के रूप में कार्य करता है, जो संदेश की अंततः डिलीवरी की गारंटी देता है।

प्रदर्शन और स्केलेबिलिटी सुनिश्चित करने के लिए एक नए कंटेनर के लिए पार्टीशन कुंजी चुनना।

→उच्च कार्डिनैलिटी वाली एक प्रॉपर्टी का चयन करें जो अधिकांश, यदि सभी नहीं, तो पॉइंट-रीड और क्वेरी ऑपरेशंस में मौजूद हो।

क्यों: पार्टीशन कुंजी को सबसे सामान्य क्वेरी फ़िल्टर के साथ संरेखित करने से यह सुनिश्चित होता है कि अधिकांश ऑपरेशंस एक एकल तार्किक पार्टीशन पर रूट किए जाते हैं, जो सबसे कुशल एक्सेस पैटर्न है।

संदर्भ↗

एकल पार्टीशन कुंजी मूल्य को असंगत रूप से उच्च मात्रा में अनुरोध प्राप्त होते हैं, जिससे थ्रॉटलिंग (एक "हॉट पार्टीशन") होता है।

→मूल कुंजी को एक रैंडम सफिक्स या किसी अन्य उच्च-कार्डिनैलिटी प्रॉपर्टी के साथ जोड़कर एक सिंथेटिक पार्टीशन कुंजी बनाएँ (जैसे, `userId + "-" + random(1-10)`)।

क्यों: एकल तार्किक इकाई के लिए राइट और रीड लोड को कई भौतिक पार्टीशनों में वितरित करता है, जिससे थ्रॉटलिंग कम होता है।

बड़े पार्टीशन से बचने और बहु-स्तरीय क्वेरीज़ का समर्थन करने के लिए डेटा को कई स्तरों (जैसे, किरायेदार, फिर वर्ष, फिर महीना) द्वारा पार्टीशन करने की आवश्यकता है।

→पाथ के एक क्रमित ऐरे के साथ एक पदानुक्रमित पार्टीशन कुंजी कॉन्फ़िगर करें, जैसे `["/tenantId", "/year"]`।

क्यों: 20 GB तार्किक पार्टीशन सीमा को रोकने के लिए उप-पार्टीशनिंग की अनुमति देता है और पदानुक्रम पर फ़िल्टर करने वाली क्वेरीज़ के लिए अधिक कुशल रूटिंग सक्षम करता है।

मल्टी-रीजन राइट्स सक्षम एक विश्व स्तर पर वितरित एप्लिकेशन को एक ही दस्तावेज़ में समवर्ती अपडेट्स को संभालने की आवश्यकता है।

→सरल ओवरराइट्स के लिए, Last-Writer-Wins (LWW) का उपयोग करें। मर्ज लॉजिक की आवश्यकता वाले ऑपरेशंस (जैसे, काउंटर बढ़ाना, इन्वेंट्री अपडेट करना) के लिए, एक मर्ज स्टोर्ड प्रोसीजर के साथ एक कस्टम संघर्ष समाधान नीति का उपयोग करें।

क्यों: कस्टम मर्ज लॉजिक डेटा हानि (जैसे, एक खोया हुआ इन्क्रीमेंट) को रोकता है जो LWW के साथ होगा, महत्वपूर्ण व्यावसायिक ऑपरेशंस के लिए डेटा अखंडता सुनिश्चित करता है।

विश्व स्तर पर वितरित एप्लिकेशन के लिए रीड लेटेन्सी, उपलब्धता और डेटा कंसिस्टेंसी को संतुलित करना।

→एक अच्छे संतुलन और रीड-योर-ओन-राइट्स के लिए डिफ़ॉल्ट रूप से Session कंसिस्टेंसी का उपयोग करें। अनुमानित रीड लैग के लिए Bounded Staleness का उपयोग करें। आवश्यकतानुसार विशिष्ट महत्वपूर्ण राइट/रीड ऑपरेशंस को Strong कंसिस्टेंसी में ओवरराइड करें।

क्यों: Session सबसे व्यापक रूप से उपयोग किया जाने वाला स्तर है, जो एक क्लाइंट सेशन के भीतर कम विलंबता और मजबूत गारंटी प्रदान करता है। प्रति-अनुरोध आधार पर ओवरराइडिंग लचीलेपन की अनुमति देता है।

राइट ऑपरेशंस अत्यधिक RU का उपभोग कर रहे हैं, और दस्तावेज़ गुणों का केवल एक छोटा सा सबसेट ही क्वेरी फ़िल्टर में उपयोग किया जाता है।

→डिफ़ॉल्ट इंडेक्सिंग नीति से एक कस्टम नीति पर स्विच करें। क्वेरी किए गए गुणों के लिए पाथ को स्पष्ट रूप से शामिल करें और अन्य सभी पाथ को बाहर करें (`excludedPaths` में `"/*"`)।

क्यों: प्रत्येक इंडेक्स की गई प्रॉपर्टी राइट्स पर RU लागत वहन करती है। अप्रयुक्त गुणों को बाहर करने से राइट RU खपत और इंडेक्स स्टोरेज आकार में काफी कमी आ सकती है।

संदर्भ↗

एक बार-बार आने वाली क्वेरी एक प्रॉपर्टी पर फ़िल्टर करती है और दूसरी द्वारा सॉर्ट करती है (जैसे, `WHERE c.status = "active" ORDER BY c.timestamp DESC`)।

→क्वेरी में जिस क्रम में वे दिखाई देते हैं, उस क्रम में गुणों पर एक कंपोजिट इंडेक्स बनाएँ: `(status ASC, timestamp DESC)`।

क्यों: क्वेरी इंजन को फ़िल्टर्ड और सॉर्टेड परिणाम को सीधे इंडेक्स से सेवा देने की अनुमति देता है, जिससे एक महंगी इन-मेमोरी सॉर्ट ऑपरेशन से बचा जा सके और RU चार्ज में भारी कमी आ सके।

एक क्वेरी बड़े दस्तावेज़ों को पुनः प्राप्त करती है लेकिन एप्लिकेशन को उनसे केवल एक या दो छोटे गुणों की आवश्यकता होती है।

→आवश्यक गुणों का चयन करने के लिए क्वेरी प्रोजेक्शन का उपयोग करें (जैसे, `SELECT c.id, c.name FROM c`) `SELECT *` के बजाय।

क्यों: डेटाबेस इंजन से क्लाइंट को स्थानांतरित किए गए डेटा पेलोड आकार को कम करके RU लागत को कम करता है।

एक एप्लिकेशन अक्सर दस्तावेज़ अपडेट के लिए पोल करता है, लेकिन डेटा शायद ही कभी बदलता है, जिससे रीड्स के लिए उच्च RU लागत आती है।

→अंतिम रीड से ETag संग्रहीत करें। बाद के रीड्स पर, `If-None-Match` हेडर में ETag भेजें।

क्यों: यदि दस्तावेज़ नहीं बदला है, तो Cosmos DB न्यूनतम RU चार्ज (आमतौर पर ~1 RU) के साथ 304 Not Modified स्थिति लौटाता है, जिससे लागत और बैंडविड्थ की बचत होती है।

एक वर्कलोड में परिवर्तनीय या अप्रत्याशित ट्रैफ़िक पैटर्न होते हैं, जिसमें महत्वपूर्ण उच्च और निम्न बिंदु होते हैं।

→डेटाबेस या कंटेनर पर ऑटोस्केल थ्रूपुट कॉन्फ़िगर करें। पीक लोड के लिए आवश्यक अधिकतम RU/s सेट करें।

क्यों: उपयोग के आधार पर थ्रूपुट को अधिकतम के 10% और अधिकतम RU/s के बीच स्वचालित रूप से स्केल करता है, निष्क्रिय प्रावधानित क्षमता के लिए भुगतान न करके लागत को अनुकूलित करता है।

एक वर्कलोड विकास, परीक्षण, या लंबी निष्क्रिय अवधियों वाले कम-ट्रैफ़िक एप्लिकेशन के लिए है।

→Cosmos DB खाते के लिए Serverless क्षमता मोड का उपयोग करें।

क्यों: आप प्रति ऑपरेशन उपभोग किए गए RU के लिए ही भुगतान करते हैं, जिसमें कोई न्यूनतम प्रावधानित क्षमता नहीं होती है। यह छिटपुट वर्कलोड के लिए सबसे लागत प्रभावी विकल्प है।

जितनी जल्दी हो सके बड़ी संख्या में दस्तावेज़ों (हजारों से लाखों) को इन्जेस्ट या संशोधित करने की आवश्यकता है।

→SDK की बल्क सपोर्ट सुविधा का उपयोग करें (जैसे, .NET SDK v3 में `AllowBulkExecution = true`)।

क्यों: SDK ऑपरेशंस को बैच करके, समवर्तीता का प्रबंधन करके, और रिट्राई/थ्रॉटलिंग को आंतरिक रूप से संभाल कर उच्च थ्रूपुट के लिए अनुकूलन करता है, जो अनुक्रमिक ऑपरेशंस से कहीं बेहतर प्रदर्शन करता है।

दस्तावेज़ों के एक बड़े बैच को संसाधित करने वाला एक स्टोर्ड प्रोसीजर टाइम आउट हो रहा है।

→सीमित निष्पादन लागू करें। स्टोर्ड प्रोसीजर को यह जांचना चाहिए कि क्या वह 5-सेकंड की निष्पादन सीमा के करीब पहुंच रहा है और यदि ऐसा है, तो क्लाइंट को एक कंटिन्यूशन टोकन वापस करना चाहिए। क्लाइंट फिर प्रोसेसिंग फिर से शुरू करने के लिए टोकन के साथ प्रोसीजर को फिर से इनवोक करता है।

क्यों: स्टोर्ड प्रोसीजर की एक कठोर निष्पादन समय सीमा होती है। एक कंटिन्यूशन पैटर्न लंबे समय तक चलने वाले, बहु-चरणीय सर्वर-साइड लॉजिक को संभालने का मानक तरीका है।

एक व्यवसाय-महत्वपूर्ण एप्लिकेशन को क्षेत्रीय आउटेज की स्थिति में न्यूनतम डेटा हानि (RPO) और तेज़ रिकवरी समय (RTO) के साथ उच्च उपलब्धता की आवश्यकता होती है।

→Cosmos DB खाते को कई राइट क्षेत्रों के साथ कॉन्फ़िगर करें और स्वचालित फ़ेलओवर सक्षम करें।

क्यों: सबसे कम RPO और RTO प्रदान करता है। डेटा क्षेत्रों में प्रतिकृति किया जाता है, और आउटेज की स्थिति में, Cosmos DB स्वचालित रूप से एक द्वितीयक क्षेत्र को नया प्राथमिक राइट क्षेत्र बनने के लिए बढ़ावा देता है।

डेटाबेस को किसी विशिष्ट समय पर पुनर्स्थापित करके आकस्मिक डेटा विलोपन या भ्रष्टाचार से उबरने की क्षमता की आवश्यकता है।

→Cosmos DB खाते पर Continuous Backup मोड सक्षम करें।

क्यों: Continuous backup आपको प्रतिधारण अवधि (7 या 30 दिन) के भीतर किसी भी समय बिंदु (सेकंड तक) पर पुनर्स्थापित करने की अनुमति देता है। पुनर्स्थापना ऑपरेशन एक नया खाता बनाता है।

संदर्भ↗

एक अनुपालन आवश्यकता अनिवार्य करती है कि डेटा एन्क्रिप्शन कुंजियों का प्रबंधन और नियंत्रण ग्राहक द्वारा किया जाना चाहिए।

→Azure Key Vault से एक कुंजी का उपयोग करके, Customer-Managed Keys (CMK) के साथ Cosmos DB खाते को कॉन्फ़िगर करें।

क्यों: सुरक्षा की एक अतिरिक्त परत प्रदान करता है जहाँ आप एन्क्रिप्शन-एट-रेस्ट के लिए कुंजी जीवनचक्र (घूर्णन और निरस्तीकरण सहित) को नियंत्रित करते हैं।

सबसे कम विशेषाधिकार के सिद्धांत का पालन करते हुए, डेटा तक एक एप्लिकेशन या उपयोगकर्ता को सूक्ष्म-दानेदार, पहचान-आधारित पहुंच प्रदान करने की आवश्यकता है।

→Azure AD एकीकरण का उपयोग करें और एक अंतर्निहित भूमिका (जैसे, Cosmos DB Built-in Data Reader) या एक कस्टम RBAC भूमिका असाइन करें, जो विशिष्ट कंटेनर या डेटाबेस तक सीमित हो।

क्यों: मास्टर कुंजियों को प्रबंधित और साझा करने की आवश्यकता को समाप्त करता है। RBAC ऑडिटेबल, पहचान-आधारित पहुंच नियंत्रण प्रदान करता है।

एक Cosmos DB खाता केवल एक विशिष्ट Azure Virtual Network (VNet) के भीतर से ही सुलभ होना चाहिए, सार्वजनिक इंटरनेट पर कोई ट्रैफ़िक नहीं।

→VNet में Cosmos DB खाते के लिए एक Private Endpoint बनाएँ और फ़ायरवॉल सेटिंग्स में सार्वजनिक नेटवर्क एक्सेस अक्षम करें।

क्यों: Private Endpoints आपके VNet के भीतर Cosmos DB खाते के लिए एक निजी IP पता प्रदान करते हैं, यह सुनिश्चित करते हुए कि सभी ट्रैफ़िक सुरक्षित Azure बैकबोन पर प्रवाहित होता है।

HTTP 429 (Too Many Requests) थ्रॉटलिंग त्रुटियों के मूल कारण का निदान करना।

→Azure Monitor में "Normalized RU Consumption" मेट्रिक की निगरानी करें। यह पहचानने के लिए Diagnostic Logs (`CDBPartitionKeyRUConsumption`) का उपयोग करें कि कौन सी पार्टीशन कुंजियाँ सबसे अधिक RU का उपभोग कर रही हैं।

क्यों: Normalized RU खपत दिखाता है कि क्या समग्र थ्रूपुट समाप्त हो गया है। पार्टीशन-स्तर के लॉग हॉट पार्टीशनों को इंगित करते हैं, जो थ्रॉटलिंग का एक सामान्य कारण है, भले ही समग्र उपयोग कम हो।

SLA अनुपालन सुनिश्चित करने के लिए अनुरोध विलंबता पर निगरानी और अलर्ट करने की आवश्यकता है।

→Azure Monitor में "Server Side Latency P99" मेट्रिक की निगरानी करें। जब यह मेट्रिक SLA थ्रेशोल्ड से अधिक हो जाए तो एक अलर्ट नियम बनाएँ।

क्यों: P99 विलंबता 99% अनुरोधों के लिए सबसे खराब-मामले के अनुभव का प्रतिनिधित्व करती है और यही वह है जिस पर Cosmos DB SLA आधारित हैं। यह औसत विलंबता की तुलना में प्रदर्शन समस्याओं का अधिक सार्थक संकेतक है।

एक अनुपालन आवश्यकता निर्धारित करती है कि सभी डेटा एक्सेस ऑपरेशंस (रीड, राइट, क्वेरी) का ऑडिट किया जाना चाहिए।

→Cosmos DB खाते पर Diagnostic Settings सक्षम करें और `DataPlaneRequests` लॉग श्रेणी को एक Log Analytics वर्कस्पेस या Storage Account पर फॉरवर्ड करें।

क्यों: `DataPlaneRequests` लॉग प्रत्येक डेटा ऑपरेशन पर विस्तृत जानकारी प्रदान करता है, जिसमें ऑपरेशन प्रकार, क्लाइंट IP और एक्सेस किया गया संसाधन शामिल है, जो सुरक्षा ऑडिटिंग के लिए आवश्यक है।

एक अविश्वसनीय क्लाइंट (जैसे, एक मोबाइल ऐप) को विशिष्ट Cosmos DB संसाधनों तक अस्थायी, सीमित पहुंच की आवश्यकता होती है (जैसे, केवल अपने स्वयं के पार्टीशन में दस्तावेज़)।

→एक विश्वसनीय मिडिल-टियर सेवा लागू करें जो उपयोगकर्ता को प्रमाणित करती है, फिर क्लाइंट को एक अल्पकालिक, अनुमति-सीमित संसाधन टोकन उत्पन्न करने और वापस करने के लिए एक मास्टर कुंजी का उपयोग करती है।

क्यों: यह क्लाइंट-साइड एक्सेस के लिए सबसे सुरक्षित पैटर्न है, क्योंकि यह मास्टर कुंजियों को उजागर करने से बचाता है और सूक्ष्म-दानेदार, अस्थायी पहुंच नियंत्रण प्रदान करता है।