क्या कॉच डीबी हजारों अलग-अलग डेटाबेस संभाल सकता है?

Question

क्या कॉच डीबी एक ही मशीन पर हजारों अलग-अलग डेटाबेस संभाल सकता है?

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

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

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

क्या इस समस्या का मॉडल करने का एक अलग तरीका है? (क्या विभाजन अलग मशीनों के बीच होता है, एक ही मशीन पर अलग डेटाबेस नहीं?) यदि नहीं, तो क्या CouchDB विभाजनों को छोटा रखने के लिए हजारों डेटाबेस को संभाल सकता है?

(धन्यवाद!)

Answer 1

[चेतावनी, मैं तुम्हें उत्पादन वातावरण में किसी प्रकार का में इस चला रहे हैं यह सोचते हैं रहा हूँ। अगर यह किसी स्कूल या पालतू परियोजना के लिए है तो संक्षिप्त उत्तर के साथ जाएं।]

संक्षिप्त उत्तर "हाँ" है।

लंबा उत्तर वहाँ कुछ चीजें आप के लिए ...

• आप अधिकतम फ़ाइल की तरह सिस्टम सेटिंग्स का एक बहुत कुछ के साथ अजीब एक तिल खेल रहे करने जा रहे हैं बाहर देखने की जरूरत यह है कि वर्णनकर्ता।

• आप एरलांग वीएम सेटिंग्स के साथ व्हाक-ए-मोल भी खेलेंगे।

• कॉच डीबी के पास "अधिकतम खुले डेटाबेस" विकल्प हैं। इसे बढ़ाएं या आपके पास लंबित अनुरोध लंबित होने जा रहे हैं।

• यह रिपोर्ट उत्पन्न करने के लिए कई डेटाबेस एकत्र करने के लिए एक पिटा होने जा रहा है। आप प्रत्येक डेटाबेस की _changes फ़ीड को मतदान करके, डेटा को संशोधित करके और फिर उसे केंद्रीय/समेकित डेटाबेस में फेंक कर ऐसा कर सकते हैं। इसे आसान बनाने के लिए टूलिंग अभी तक कॉच डीबी के एपीआई में नहीं है। लगभग, लेकिन काफी नहीं।

हालांकि, सबसे बड़ी समस्या यह है कि आप अगर आप ऐसा करने की कोशिश में चलाने के लिए जा रहे है कि CouchDB नहीं क्षैतिज पैमाने [अच्छी तरह से] अपने आप में करता है। यदि आप अधिक कॉच डीबी सर्वर जोड़ते हैं तो वे सभी डेटा के डुप्लीकेट होने जा रहे हैं। निश्चित रूप से, आपकी अधिकतम खुली डीबीएस गिनती प्रत्येक नोड के साथ रैखिक रूप से स्केल करेगी, लेकिन निर्माण की समय जैसी अन्य चीजें नहीं होगी (उदा।, उन्हें सभी को अपना स्वयं का दृश्य बनाने की आवश्यकता होगी)।

जबकि मैंने BigCouch क्लस्टर पर हजारों खुले डेटाबेस देखे हैं।अनजाने में यह डायनेमो क्लस्टरिंग की वजह से है: अधिक नोड्स समानांतर में अलग-अलग चीजें कर रहे हैं, बनाम कॉच डीबी सर्वरों को एक दूसरे के लिए प्रतिलिपि बनाते हैं।

चीयर्स।

Answer 2

एकाधिक डेटाबेस संभव हैं, लेकिन ज्यादातर मामलों में मुझे लगता है कि कुल डेटाबेस वास्तव में आपकी शाखाओं को बेहतर प्रदर्शन देगा। ध्यान रखें कि जब आप किसी दस्तावेज़ को दृश्य में अपडेट करते हैं तो आप केवल अनुकूलन कर रहे हैं; प्रत्येक दस्तावेज़ को केवल प्रति दृश्य एक बार पार्स किया जाएगा।

एक समग्र डेटाबेस में अंतिम दिन मतदान के लिए, पहली शाखा नए दस्तावेज़ों का 100% संसाधित होने का कारण बनती है, और देरी का 100% भुगतान करती है। अन्य सभी शाखाएं 0% का भुगतान करेंगी। तो ज्यादातर शाखाओं का लाभ होता है। अलग-अलग डेटाबेस में मतदान के दिन के लिए, सभी शाखाएं अपने वॉल्यूम के आनुपातिक दंड का एक हिस्सा देती हैं, इसलिए अधिकतर पीछे आते हैं।

पूरे दिन लगातार दृश्य अपडेट के लिए, सक्रिय शाखाएं कुल और निम्न-मात्रा वाली शाखाओं को अलग करना पसंद करती हैं। यदि 10 में से एक शाखा 99% दस्तावेजों को जोड़ती है, तो अधिकांश अपडेट का काम अन्य शाखा के चुनावों पर किया जाएगा, इसलिए 10 में से 9 अलग-अलग डीबीएस पसंद करते हैं।

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

Answer 3

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