मैं एक ऐसे एप्लिकेशन के लिए Azure CosmosDB का उपयोग करके जांच कर रहा हूं जिसके लिए उच्च पठन थ्रूपुट और स्केल करने की क्षमता की आवश्यकता होगी। 99% गतिविधि पढ़ी जाएगी, लेकिन कभी-कभी हमें कुछ दस्तावेजों से संभावित रूप से कुछ मिलियन के बैच में कहीं डालने की आवश्यकता होगी।

मैंने 2500 आरयू/सेकंड के साथ परीक्षण और प्रावधान करने के लिए एक संग्रह बनाया है। हालांकि मैं केवल 120 छोटे (500 बाइट्स) दस्तावेज़ डालने के मुद्दों में भाग रहा हूं (मुझे "अनुरोध दर बड़ी है" त्रुटि मिलती है)।

मैं किसी भी उपयोगी तरीके से दस्तावेज़ डीबी का उपयोग कैसे कर सकता हूं, अगर किसी भी समय मैं कुछ दस्तावेज सम्मिलित करना चाहता हूं तो यह मेरे सभी आरयू का उपयोग करेगा और किसी को भी इसे पढ़ने से रोकेगा?

हां, मैं प्रावधानित आरयू को बढ़ा सकता हूं, लेकिन अगर मुझे पढ़ने के लिए केवल 2500 की जरूरत है, तो मैं कभी-कभार डालने के लिए 10000 का भुगतान नहीं करना चाहता।

पढ़ने को यथासंभव तेज़ होना चाहिए, आदर्श रूप से "single-digit-millisecond में " श्रेणी जिसे Microsoft विज्ञापित करता है। इन्सर्ट को जितना संभव हो उतना तेज़ होने की आवश्यकता नहीं है, लेकिन तेज़ होना बेहतर है।

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

मुझे ऐसा लगता है कि मुझे कुछ याद आ रहा है, क्या मुझे केवल लिखने के लिए प्रावधान आरयू को बड़े पैमाने पर करना है? क्या डालने के लिए आरयू उपयोग को सीमित करने के लिए किसी प्रकार की कार्यक्षमता बनाई गई है? उचित समय में और संग्रह को अनुपयोगी बनाए बिना सैकड़ों-हजारों दस्तावेज़ों को सम्मिलित करना कैसे संभव है?

11
QTom 11 अगस्त 2017, 13:19
अपने डेटा स्कीमा या विभाजन को देखे बिना, कुछ भी निश्चित देना कठिन है, लेकिन... आप अपनी अनुक्रमण नीति को आलसी (संगत से) में बदलने का प्रयास कर सकते हैं, साथ ही उन संपत्तियों को हटाने के लिए अपनी अनुक्रमण नीति को बदलने का प्रयास कर सकते हैं जिन्हें आपको अनुक्रमित करने की आवश्यकता नहीं है। इससे आपकी प्रति-दस्तावेज़ RU लागत प्रति प्रविष्टि कम होनी चाहिए (लेकिन मैं आपको यह नहीं बता सकता कि यह आपको कितना बचाएगा)।
 – 
David Makogon
11 अगस्त 2017, 13:22
धन्यवाद, मैं यह कोशिश कर सकता हूं लेकिन ऐसा लगता है कि समस्या को हल करने के बजाय इसे ऑफसेट करना है। मैं ऐसा कर सकता था और यह मुझे कुछ दस्तावेज़ डालने की अनुमति दे सकता है, लेकिन अगली बार मुझे और डालने की आवश्यकता हो सकती है और यह समस्या फिर से हो सकती है
 – 
QTom
11 अगस्त 2017, 13:34
जैसा मैंने कहा, मैं आपके समग्र डेटा मॉडल को नहीं समझता। लेकिन... एक और विचार: चूंकि आप केवल कभी-कभार ही इन्सर्ट करते हैं, प्रति मिनट आरयू बर्स्ट को सक्षम करने पर विचार करें, जो आपको प्रति मिनट की समयावधि में फैली 10x आरयू क्षमता प्रदान करता है। यह आपको आवेषण से निपटने के लिए पर्याप्त ओवरहेड दे सकता है, और प्रति मिनट फट लगातार उच्च आरयू दर की तुलना में अधिक लागत प्रभावी होना चाहिए।
 – 
David Makogon
11 अगस्त 2017, 13:36
बात यह है कि मैं वास्तव में कभी नहीं जान पाऊंगा कि कितना/कितना डेटा डाला जाना है, क्या मुझे आवश्यक आरयू की गणना करनी चाहिए और डालने पर इसे बदलना चाहिए? या DocumentDB तब तक उपयुक्त नहीं है जब तक कि आपके पास स्पष्ट परिभाषा न हो कि आपको कितने RU की आवश्यकता है?
 – 
QTom
11 अगस्त 2017, 14:05
क्या आप अपने संग्रह में विभाजन सक्षम हैं? आम तौर पर उच्च स्तर पर कॉन्फ़िगर किया गया RU/s तार्किक विभाजनों में समान रूप से वितरित किया जाता है। इसलिए यदि आप एकल विभाजन में बल्क इंसर्ट्स कर रहे हैं जो कि प्रावधानित RU/s. जैसा कि डेविड ने अनुशंसित किया है, RU/मिनट को सक्षम करने और अंतिम स्थिरता का विकल्प चुनने का प्रयास करें, या उन कुंजियों के लिए अनुक्रमण अक्षम करें जो क्वेरी में उपयोग नहीं की जाती हैं। यदि बल्क इंसर्ट्स ऑपरेशंस शेड्यूल किए गए हैं (दिन में एक बार), तो आप लिखने से पहले RU/s को बढ़ाने की कोशिश कर सकते हैं और एक बार कलेक्शन ओवर ऑपरेशंस के साथ उन्हें नीचे ला सकते हैं। मुझे बताएं कि क्या इससे मदद मिलती है।
 – 
Surender Singh Malik
11 अगस्त 2017, 17:16

3 जवाब

तेजी से सम्मिलन की कुंजी आपके लोड को कई भौतिक विभाजनों में वितरित करना है। आपके मामले में, संग्रह में मौजूद डेटा की कुल मात्रा के आधार पर, आपके पास न्यूनतम कुल वॉल्यूम/10GB विभाजन होगा। आपके कुल आरयू इन विभाजनों के बीच समान रूप से वितरित किए जाते हैं।

अपने डेटा मॉडल के आधार पर, यदि आप अपने डेटा को विभाजित कर सकते हैं, तो आप समानांतर में विभिन्न विभाजनों को लिखकर संभावित रूप से गति प्राप्त कर सकते हैं।

चूंकि आपने उल्लेख किया है कि आपको कभी-कभी कुछ मिलियन पंक्तियों का एक बैच लिखना पड़ता है, मैं उस अवधि के लिए आरयू की क्षमता को बढ़ाने और इसे आपके रीड लोड के लिए आवश्यक स्तरों तक कम करने की सलाह दूंगा।

संग्रहीत कार्यविधियों का उपयोग करते हुए लेखन, आपके द्वारा किए जाने वाले नेटवर्क कॉलों को सहेजते समय, अधिक लाभ नहीं दे सकता है, क्योंकि संग्रहीत कार्यविधि केवल एक ही विभाजन पर निष्पादित हो सकती है। तो यह केवल उस विभाजन को आवंटित आरयू का उपयोग कर सकता है।

https://docs.microsoft. com/en-us/azure/cosmos-db/partition-data#designing-for-partitioning के पास इस बारे में कुछ अच्छा मार्गदर्शन है कि किस प्रकार का विभाजन समझ में आता है।

0
KranthiKiran 12 अगस्त 2017, 03:03

यदि आप अपने निवेशनों की लागत में सुधार नहीं कर सकते हैं, तो आप दूसरी तरफ जा सकते हैं और प्रक्रिया को धीमा कर सकते हैं ताकि आपका समग्र प्रदर्शन प्रभावित न हो। अगर आप आधिकारिक प्रदर्शन बेंचमार्किंग नमूना (जो दस्तावेजों को सम्मिलित करता है), आप इसे एक विचार के रूप में ले सकते हैं कि कैसे आरयू/एस को सम्मिलित करने के लिए आपको आवश्यक है। यह बहुत सारे मापदंडों को दिखाता है जिन्हें प्रदर्शन में सुधार के लिए बदला जा सकता है, लेकिन स्पष्ट रूप से इनका उपयोग आपके आरयू / एस की खपत को एक निश्चित स्तर तक तैयार करने के लिए भी किया जा सकता है।

क्रांतिकिरण का उत्तर उन सभी चीजों का सार है जिनके बारे में मैं सोच सकता हूं।

0
Alex AIT 17 नवम्बर 2017, 22:13

आप नए ऑटोपायलट मोड का भी उपयोग कर सकते हैं। ऑटोपायलट मोड में कॉन्फ़िगर किए गए कंटेनर एप्लिकेशन के पीक लोड की जरूरतों को पूरा करने के लिए क्षमता को समायोजित करते हैं और गतिविधि का उछाल खत्म होने पर वापस स्केल करते हैं। आपको अधिकतम थ्रूपुट निर्दिष्ट करने की आवश्यकता है।

0
ravi tella 8 अप्रैल 2020, 00:44