परिवर्तन धाराओं का उपयोग करके उत्पादन में MongoDB चलाने के लिए युक्तियाँ

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

MongoDB स्ट्रीम बदलें और संग्रह छोड़ें

डेटाबेस या संग्रह का नाम बदलने या छोड़ने से कर्सर बंद हो जाएगा यदि ड्रॉप किए गए संग्रह के विरुद्ध कोई खुली परिवर्तन स्ट्रीम काम कर रही थी। किसी संग्रह का नाम बदलने या छोड़ने से कर्सर को FullDocument:updateLookup किसी दिए गए लुकअप दस्तावेज़ पर शून्य वापस करने के लिए बनाता है। एक त्रुटि तब होती है जब कोई चल रहे परिवर्तन स्ट्रीम वाले डेटाबेस को छोड़ने के बाद फिर से शुरू करने का प्रयास करता है।

इसके अतिरिक्त, एक संग्रह का नाम बदलने से पहले किए गए डेटा में किए गए सभी परिवर्तन एक परिवर्तन स्ट्रीम के साथ चल रहे हैं जो खो गए हैं। चेंज स्ट्रीम के लिए दस्तावेज़ की सीमा अभी भी 16MB BSON है; इसलिए, 16MB से बड़े दस्तावेज़ स्वीकार नहीं किए जाते हैं। यदि कोई 16MB से बड़े दस्तावेज़ के साथ काम करने का प्रयास करता है, तो अधिसूचना विफल हो जाती है, और दस्तावेज़ को दूसरे दस्तावेज़ से बदल दिया जाता है जो निर्धारित सीमा को पूरा करता है।

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

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

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

MongoDB चेंज स्ट्रीम और रेप्लिका सेट

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

यदि डाउनटाइम का काफी अनुमान लगाया जाता है, उदाहरण के लिए, अपग्रेड करने के लिए या किसी आपदा की स्थिति में, तो ओप्लॉग का आकार बढ़ाना ऑपरेशन को उस अवधि के लिए बनाए रखने का सबसे अच्छा विकल्प होगा जो इससे अधिक है अनुमानित डाउनटाइम। ओप्लॉग स्थिति की जानकारी प्राप्त करने के लिए, उपयोग किया जाने वाला कमांड PrintReplicationInfo () है। कमांड न केवल ओप्लॉग स्थिति की जानकारी बल्कि ओप्लॉग आकार और संचालन के समय की सीमा को भी पुनः प्राप्त करेगा।

MongoDB स्ट्रीम उपलब्धता बदलें

MongoDB परिवर्तन धाराएं प्रतिकृति सेट और शार्प क्लस्टर के लिए प्राप्य हैं:चिंता "बहुमत" सक्षमता, संग्रहण इंजन और प्रतिकृति सेट प्रोटोकॉल संस्करण पढ़ें। चिंता पढ़ें "बहुमत" सक्षमता:MongoDB संस्करण 4.2 और इसके बाद के संस्करण के साथ शुरू, "बहुमत" पढ़ने की चिंता समर्थन की मौजूदा परिस्थितियों के बावजूद परिवर्तन धाराएं सुलभ हैं, जिसका अर्थ है कि पढ़ने की चिंता बहुमत समर्थन सक्षम या अक्षम किया जा सकता है। MongoDB संस्करण 4.0 में और पुराने संस्करण, परिवर्तन धाराएँ केवल तभी उपलब्ध होती हैं जब "बहुमत" पठन चिंता समर्थन सक्रिय हो।

1. स्टोरेज इंजन:WiredTiger स्टोरेज इंजन, रेप्लिका सेट और शार्प्ड क्लस्टर्स द्वारा उपयोग किया जाने वाला स्टोरेज इंजन प्रकार है।
2. रेप्लिका सेट प्रोटोकॉल वर्शन:रेप्लिका सेट और शार्प किए गए क्लस्टर को हमेशा रेप्लिका सेट प्रोटोकॉल (pv1) के संस्करण 1 का उपयोग करना चाहिए।

MongoDB साझा क्लस्टर

मोंगोडीबी में शार्डेड क्लस्टर्स में शार्ड्स, मोंगोस और कॉन्फिग सर्वर होते हैं। एक शार्क में शार्प किए गए डेटा का एक सबसेट होता है। MongoDB 3.6 के मामले में, शार्क का उपयोग प्रतिकृति सेट के रूप में किया जाता है। Mongos शार्प किए गए क्लस्टर और क्लाइंट एप्लिकेशन के बीच एक इंटरफ़ेस प्रदान करता है; mongos एक क्वेरी राउटर की भूमिका निभाता है। MongoDB संस्करण 4.4 और इसके बाद के संस्करण से, mongos विलंबता को कम करने के लिए हेज्ड रीड का समर्थन करता है। कॉन्फ़िगरेशन सर्वर क्लस्टर कॉन्फ़िगरेशन सेटिंग्स और मेटाडेटा के लिए संग्रहण स्थान हैं।

परिवर्तन धाराएं एक वैश्विक तार्किक घड़ी का उपयोग करती हैं ताकि शार्क में परिवर्तनों का वैश्विक क्रम प्रदान किया जा सके। MongoDB यह सुनिश्चित करता है कि परिवर्तनों का क्रम बना रहे और परिवर्तन स्ट्रीम की सूचनाओं को उनके प्राप्त होने के क्रम में सुरक्षित रूप से व्याख्यायित किया जा सके। उदाहरण के लिए, 3-शार्ड क्लस्टर के विरुद्ध खोला गया परिवर्तन स्ट्रीम का कर्सर तीन शार्क में परिवर्तनों के कुल क्रम से संबंधित परिवर्तन की सूचनाएं लौटाता है।

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

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

निष्कर्ष

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