MongoDB क्लस्टर परिनियोजन के लिए सर्वश्रेष्ठ आर्किटेक्चर का निर्धारण

डेटा की उच्च उपलब्धता सुनिश्चित करने के साथ-साथ इसे सुरक्षित रखने के लिए क्लस्टर परिनियोजन का बहुत महत्व है। MongoDB प्रतिकृति और शार्डिंग के माध्यम से इसे बढ़ाता है, जिससे प्रतिकृति रिडंडेंसी उठाने के माध्यम से ऊर्ध्वाधर स्केलिंग सुनिश्चित करता है जबकि शार्डिंग क्षैतिज स्केलिंग को बढ़ाता है।

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

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

MongoDB परिनियोजन रणनीतियाँ

प्रतिकृति सेट की वास्तुकला MongoDB की क्षमता और क्षमता का बहुत निर्धारक है।

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

MongoDB शेयरिंग रणनीतियाँ

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

शार्क किए गए क्लस्टर के लिए कुछ बेहतरीन परिनियोजन रणनीतियों में शामिल हैं:

यह सुनिश्चित करना कि Shard Keys समान रूप से वितरित की जाती हैं

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

हिस्से को पूर्व-विभाजित और पहले वितरित किया जाना चाहिए

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

शार्ड की संख्या

शार्डिंग महत्व प्राप्त करने के लिए न्यूनतम संख्या के रूप में अक्सर दो शार्क की आवश्यकता होती है। एक शार्ड केवल तभी उपयोगी होता है जब आप भविष्य में शार्डिंग को सक्षम करने की नींव रखना चाहते हैं और परिनियोजन समय के दौरान इसकी कोई आवश्यकता नहीं है।

हैश-आधारित साझाकरण के बजाय श्रेणी-आधारित साझाकरण को प्राथमिकता दें

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

केवल बड़ी एकत्रीकरण क्वेरी के लिए स्कैटर-इकट्ठा क्वेरी का उपयोग करें

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

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

MongoDB प्रतिकृति रणनीतियाँ

प्रतिकृति MongoDB में लंबवत स्केलिंग को बढ़ाती है जैसे कि शामिल सदस्यों के बीच कार्यभार वितरित किया जाता है। उत्पादन के माहौल में, इष्टतम क्लस्टर आर्किटेक्चर के लिए इन कुछ बातों पर ध्यान देना चाहिए।

नोड्स की संख्या

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

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

गलती सहनशीलता के विचार

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

नीचे दी गई तालिका तीनों के बीच एक नमूना संबंध दिखाती है।

संबंध इतना सीधा नहीं है कि यदि आप सेट में अधिक सदस्यों को जोड़ते हैं तो यह नहीं दिया जाता है कि गलती सहनशीलता बढ़ जाएगी जैसा कि तालिका से देखा गया है। अतिरिक्त सदस्य बैकअप और रिपोर्टिंग जैसे समर्पित कार्यों के लिए सहायता प्रदान करते हैं।

भारी पढ़ने के लिए क्षमता योजना और भार संतुलन

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

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

आप विशिष्ट सदस्यों को पढ़ने के संचालन को लक्षित करने के लिए टैग सेट के साथ लक्ष्य संचालन का उपयोग कर सकते हैं या विशिष्ट सदस्यों से पावती का अनुरोध करने के लिए लेखन चिंता को संशोधित कर सकते हैं।

नोड्स को भौगोलिक रूप से वितरित किया जाना चाहिए

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

अप्रत्याशित विफलताओं के लिए जर्नलिंग को नियोजित करें

डिफ़ॉल्ट रूप से यह MongoDB में सक्षम है। आपको यह सुनिश्चित करना चाहिए कि यह विकल्प सक्षम है ताकि अचानक रिबूट और बिजली की विफलता जैसी सेवा रुकावटों की स्थिति में डेटा हानि से बचा जा सके।

परिनियोजन पैटर्न

मुख्य रूप से दो परिनियोजन दृष्टिकोण हैं:

• तीन सदस्य प्रतिकृति सेट जो प्रतिकृति सेट के लिए न्यूनतम अनुशंसित वास्तुकला प्रदान करते हैं।
• प्रतिकृति सेट को दो या अधिक डेटा केंद्रों में वितरित किया जाता है ताकि बिजली की कमी जैसी सुविधा-विशिष्ट विफलताओं से बचाव किया जा सके।

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

होस्टनाम और प्रतिकृति सेट नामकरण

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

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

निष्कर्ष

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