प्रति बाल्टी

Question

बाल्टी में बड़ी संख्या में डेटा (> 100 जीबी,> 100 एम दस्तावेज,> 12 दस्तावेज़ प्रकार) मानते हुए, प्रतिबिंब कितने विचार हैं, और मानते हैं कि प्रत्येक दृश्य केवल एक पर लागू होता है दस्तावेज़ का प्रकार? या किसी अन्य तरीके से पूछा, किस दस्तावेज़ पर कुछ दस्तावेज़ प्रकारों को सभी दस्तावेज़ प्रकारों पर सभी विचारों को संसाधित करने के ऊपरी हिस्से को बचाने के लिए अलग-अलग बाल्टी में विभाजित किया जाना चाहिए?

मुझे अपने डेटा को सोफेबेस बाल्टी में विभाजित करने और डेटा पर आवश्यक विचारों के प्रदर्शन प्रभाव को कैसे तय करना है, यह तय करने में कठिनाई हो रही है। मेरे डेटा में दर्जन से अधिक रिलेशनल डीबी शामिल हैं, जिनमें से कम से कम आधे लाखों पंक्तियों में लाखों पंक्तियां हैं।

http://www.couchbase.com/docs/couchbase-manual-2.0/couchbase-views-writing-bestpractice.html डॉक्टर अनुभाग "दस्तावेज़ प्रकारों का उपयोग" खंड में एक ही बाल्टी में एकाधिक दस्तावेज़ प्रकार होने का अर्थ आदर्श नहीं है क्योंकि विशिष्ट दस्तावेज़ प्रकारों पर विचार सभी दस्तावेजों के लिए अपडेट किए जाते हैं, यहां तक ​​कि वे कभी भी दृश्य से मेल नहीं खाते हैं। दरअसल, यह इस ओवरहेड से बचने के लिए डेटा को बाल्टी में अलग करने का सुझाव देता है।

फिर भी प्रदर्शन कारणों से प्रति क्लस्टर की 10 बाल्टी की सीमा है। मेरा एकमात्र निष्कर्ष इसलिए है कि प्रत्येक क्लस्टर कुशलतापूर्वक दस्तावेजों के अधिकतम 10 बड़े संग्रह को संभाल सकता है। क्या यह सही है?

Answer 1

टग की सलाह सही थी और मुझे कुछ परिप्रेक्ष्य भी जोड़ने की अनुमति दी गई।

आरडीएमएस दुनिया के भीतर एक बाल्टी को सबसे अधिक निकटता से संबंधित (हालांकि बिल्कुल नहीं) माना जा सकता है। उस "डेटाबेस" के भीतर कई टेबल/स्कीमा होंगे और उन सभी को बाल्टी के भीतर जोड़ा जा सकता है।

डेटा के लॉजिकल ग्रुपिंग के रूप में एक बाल्टी के बारे में सोचें जो सभी सामान्य कॉन्फ़िगरेशन पैरामीटर (रैम कोटा, प्रतिकृति गिनती इत्यादि) साझा करते हैं और आपको केवल अपने डेटा को कई बाल्टी में विभाजित करने की आवश्यकता होती है जब आपको कुछ डेटासेट नियंत्रित करने की आवश्यकता होती है अलग से। अन्य कारण अलग-अलग डेटासेट में बहुत अलग वर्कलोड से संबंधित हैं या अलग-अलग डेटासेट्स को वर्कलोड को ट्रैक करने में सक्षम होने की इच्छा से संबंधित हैं।

कुछ उदाहरण:

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

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

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

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

इस आखिरी बिंदु के बारे में, हां प्रत्येक बाल्टी को लिखना इंडेक्सिंग इंजन द्वारा उठाया जाएगा, लेकिन जेएसओएन के भीतर दस्तावेज़ प्रकारों का उपयोग करके, आप किसी दिए गए दस्तावेज़ के लिए प्रसंस्करण को बहुत जल्दी कर सकते हैं और वास्तव में यह नहीं होना चाहिए इसमें बहुत सारे डेटा आने के लिए एक हानिकारक प्रभाव कुछ विचारों पर लागू नहीं होता है। यदि आपको कोई फर्क नहीं पड़ता है, तो मैं विशेष रूप से उत्सुक हूं कि दस्तावेज़ीकरण के कुछ हिस्सों में अन्यथा यह संकेत दिया गया है कि निश्चित रूप से हमारा इरादा नहीं था।

तो आम तौर पर, हम कम संख्या में बाल्टी (2-3) और केवल 5 के ऊपर के साथ अधिकांश तैनाती देखते हैं।10 की हमारी सीमा कुछ ज्ञात सीपीयू और डिस्क आईओ ओवरहेड से आती है जो हमारे आंकड़ों की आंतरिक ट्रैकिंग (लोड या इसकी बाल्टी पर कमी का कोई फर्क नहीं पड़ता)। हम निश्चित रूप से भावी रिलीज के साथ इस ओवरहेड को कम करने की योजना बना रहे हैं, लेकिन यह अभी भी कुछ बाल्टी रखने की हमारी सिफारिश को नहीं बदलेगा। एक ही लॉजिकल ग्रुपिंग में कई "स्कीमा" को गठबंधन करने में सक्षम होने के फायदे और उस पर दृश्य/अनुक्रमणिका लागू करें जो अभी भी मौजूद हैं।

हम अभी और अधिक विशिष्ट दिशानिर्देशों और आकार बदलने की सिफारिशों के साथ आने की प्रक्रिया में हैं (मैंने उन पहले दो ब्लॉगों को स्टॉप-गैप के रूप में लिखा है)।

प्रारंभिक दृष्टिकोण के रूप में, आप डिज़ाइन दस्तावेज़ों की संख्या को 4 के आसपास रखना और रखना चाहते हैं क्योंकि डिफ़ॉल्ट रूप से हम समानांतर में 4 तक संसाधित करते हैं। आप इस नंबर को बढ़ा सकते हैं, लेकिन इसे सीपीयू और डिस्क आईओ क्षमता में बढ़ाया जाना चाहिए। इसके बाद आप प्रत्येक दस्तावेज़ के भीतर अपेक्षाओं की संख्या को अपेक्षाकृत कम रखना चाहते हैं, शायद 10 से नीचे, क्योंकि प्रत्येक धारावाहिक में संसाधित होते हैं।

मैंने हाल ही में एक ऐसे उपयोगकर्ता के साथ काम किया जिसकी काफी संख्या में विचार थे (लगभग 8 डिज़ाइन दस्तावेज़ और लगभग 20 विचारों के साथ कुछ डीडी) और हम इसे कई विचारों को एक साथ जोड़कर काफी नीचे लाने में सक्षम थे। जाहिर है यह बहुत ही निर्भर है, लेकिन आपको एक सूचकांक से कई अलग-अलग "प्रश्न" उत्पन्न करने का प्रयास करना चाहिए। कटौती का उपयोग करना, कुंजी-उपसर्ग (विचारों के भीतर), और संयोजन, सभी अलग-अलग सीमाओं और समूहीकरण क्वेरी के साथ मिलकर एक एकल इंडेक्स बना सकते हैं जो पहले भीड़ में दिखाई दे सकता है, लेकिन वास्तव में बहुत लचीला है।

आपके पास कम डिज़ाइन दस्तावेज़ और विचार हैं, कम डिस्क स्थान, आईओ और सीपीयू संसाधनों की आपको आवश्यकता होगी। दुर्भाग्यवश कभी जादू बुलेट या हार्ड-एंड-फास्ट दिशानिर्देश संख्या होने वाला नहीं है। अंत में, वाईएमएमवी और आपके डेटासेट पर परीक्षण किसी भी बहु पृष्ठ प्रतिक्रिया से बेहतर है ;-)

आशा है कि मदद करता है, अगर आपके पास विशिष्ट प्रश्न हैं तो कृपया हमसे सीधे संपर्क करने में संकोच न करें आपका विशिष्ट उपयोग केस जिसे आप प्रकाशित नहीं करना चाहते हैं।

पेरी

Answer 2

जैसा कि आप कोचबेस दस्तावेज़ से देख सकते हैं, आपको एक सटीक सदस्य देने के लिए "सार्वभौमिक" नियम प्रदान करना वास्तव में संभव नहीं है।

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

के अंतिम सवाल के साथ शुरू करते हैं:

हाँ कारण है कि काउचबेस सलाह बाल्टी की एक छोटी संख्या प्रदर्शन के लिए है के लिए - अधिक महत्वपूर्ण संसाधन खपत कारण और।

• 1 नौकरशाही का आकार घटाने: http://blog.couchbase.com/how-many-nodes-part-1-introduction-sizing-couchbase-server-20-cluster
• नौकरशाही का आकार घटाने 2: http://blog.couchbase.com/how-many-nodes-part-2-sizing-couchbase-server-20-cluster
• संघनन: http://blog.couchbase.com/compaction-magic-couchbase-server-20

मैं इन ब्लॉग पोस्ट को समझने के लिए पर "अंदर" काउचबेस जा रहा है मदद को पढ़ने के लिए आमंत्रित कर रहा हूँ तो आप देखेंगे कि अधिकांश "ऑपरेशन" बाल्टी द्वारा किए जाते हैं।

तो चलो अब मूल प्रश्न पर ध्यान दें:

• हाँ सबसे अधिक समय अपने दस्तावेज़ के प्रकार के आधार पर डिजाइन दस्तावेज़/और विचारों का आयोजन करेगा।
• किसी भी (कुछ) बाल्टी में सभी दस्तावेज़ "प्रकार" रखने में कोई समस्या नहीं है, वास्तव में यह आपके काम कोचबेज
• देखने के लिए सबसे महत्वपूर्ण हिस्सा है, आपके दस्तावेज़ का आकार (यह देखने के लिए कि "लंबे समय" जेएसओएन का पार्सिंग कैसे होगा) और दस्तावेज़ कितनी बार बनाया जाएगा/अपडेट किया जाएगा, और हटा दिया जाएगा, क्योंकि जब आप दस्तावेज़ बनाते/बदलते हैं तो जेएस कोड दृश्य को निष्पादित किया जाता है।

तो आपको क्या करना चाहिए:

• 1 एकल बाल्टी
• कितने डिजाइन दस्तावेजों? (आपके पास कितने प्रकार हैं?)
• आपके पास प्रत्येक दस्तावेज़ में कोई विचार कैसा होगा?

वास्तव में सबसे महंगी हिस्सा अनुक्रमण के दौरान नहीं है या quering इसे और अधिक आप डेटा को संतुलित करने के लिए है जब है और अंत में नोड्स (जोड़ने, हटाने, नोड्स की विफलता) के बीच

सूचकांक, लेकिन यह ऐसा लगता है कि आप इसे पहले ही जानते हैं, यह अध्याय यह समझने के लिए काफी अच्छा है कि विचार कैसे काम करते हैं (इंडेक्स कैसे बनाया और उपयोग किया जाता है): http://www.couchbase.com/docs/couchbase-manual-2.0/couchbase-views-operation.html

यदि आवश्यक हो तो अधिक जानकारी जोड़ने में संकोच न करें।