MongoDB क्या है?
MongoDB अन्य चीजों के अलावा, एक डॉक्यूमेंट-ओरिएंटेड NoSQL डेटाबेस है। इसका मतलब है कि यह डेटा प्रबंधन और संगठन के लिए एक लचीला, क्षैतिज रूप से स्केलिंग मॉडल प्रस्तुत करने के लिए पारंपरिक, रिलेशनल मॉडल से विचलित होता है।
MongoDB AEM के साथ कैसे काम करता है?
MongoDB, crx3mongo रनमोड और JVM विकल्पों के माध्यम से Adobe Experience Manager (AEM) के साथ एकीकृत होता है: -Doak.mongo.uri और -Doak.mongo.db
मैं MongoDB क्यों उपयोग करूं?
मुख्य रूप से MongoDB पुराने CRX क्लस्टर कॉन्फ़िगरेशन के लिए एक वैकल्पिक HA कॉन्फ़िगरेशन प्रदान करता है। वास्तव में, आर्किटेक्चर NFS पर साझा कैटलॉग या NetApp की तुलना में अधिक समान है बजाय वास्तविक क्लस्टरिंग के। MongoDB का उपयोग करने वाले लेखक और प्रकाशक एक-दूसरे के बारे में जरूरी नहीं जानते हैं।
इसे रास्ते से हटा दें - CRX क्लस्टरिंग का ट्रैक रिकॉर्ड बेदाग नहीं है। स्थानीय-केवल ऑब्जेक्ट कैटलॉग की अंतर्निहित चुनौतियों में से एक यह है कि, पैमाने पर, एक सिंगल कैटलॉग कई लाभ प्रस्तुत करता है:
- डेटा के दोहराव में कमी
- प्रदर्शन विश्लेषण और ट्यूनिंग के लिए केंद्रित दायरा
- बहु-नोड इंटरैक्शन की आवश्यकता के बिना HA उपलब्धता
- अतिरेक और प्रदर्शन के लिए क्षैतिज स्केलिंग
यहां तक कि एक पूरी तरह से काम करने वाले CRX क्लस्टर के साथ, इनमें से कोई भी लाभ संबोधित नहीं होते हैं। साझा डेटा टियर के तथाकथित पुराने दिनों में प्रवेश करें।
5.6.1 और उससे पहले के साथ, बड़े और बढ़ते डिप्लॉयमेंट अपने ऑब्जेक्ट रिपॉजिटरी को साझा NFS के रूप में माउंट कर सकते थे, जहां प्रोटोकॉल, या NFS सर्वर, कम टकराव के साथ मल्टी-राइट व्यवहार के लिए लॉकिंग समर्थन प्रदान करता था। यह अभी भी एक व्यवहार्य विकल्प है, लेकिन, जब तक NetApp का उपयोग नहीं किया जाता, तब तक कंट्रोलर में, या डेटा टियर में जो n*9 आर्किटेक्चर को रोकता है, सिंगल पॉइंट ऑफ फेल्योर का जोखिम अक्सर होता है।
AEM 6.x में MongoDB माइक्रोकर्नेल का परिचय अनिवार्य रूप से उसी आर्किटेक्चर को प्रदान करता है लेकिन उस अधिक बज़वर्ड-भारी डेटाबेस के साथ जिसे हम प्यार करते हैं।
MongoMK का प्राथमिक उपयोग-मामला AEM लेखक इंस्टेंस के साथ है, जहां सक्रिय उपयोगकर्ता सीमा (~25-30) का मतलब है कि क्षैतिज स्केलिंग को पहले समवर्ती मुद्दे को संबोधित करना होगा। यहां, साझा डेटा टियर सबसे चमकदार चमकता है क्योंकि प्रदर्शन पैमाने और स्थिरता के बाद दूसरा स्थान लेता है जबकि नोड-टू-नोड संचार की आवश्यकता को समाप्त करता है।
इसी तरह के फैशन में प्रकाशकों को शामिल करना निश्चित रूप से संभव है, हालांकि, लाभ कम हो जाते हैं क्योंकि समवर्ती मुद्दे की कमी के कारण (यानी अधिक पैमाने के लिए बस अधिक प्रकाशक जोड़ें) और गैर-स्थानीय कैटलॉग के प्रदर्शन दंड के कारण।
तो बस यही है! अनंत और उससे आगे स्केल करें!
धीमा करें, बज़ लाइटइयर, एक समस्या है। सिंगल-साइट MongoDB से बहुत प्रभावी ढंग से स्केल करने की उम्मीद है क्योंकि इसके तेज़-एक्सेस डेटा और इन-लाइन नेटवर्किंग का विकल्प है। यहां, आकाश सीमा हो सकता है। हालांकि, एक मल्टी-साइट डिप्लॉयमेंट पर विचार करें जहां MongoDB रेप्लिका सेट को असमान डेटा केंद्रों और अज्ञात मील के फाइबर में संचार करना होगा। ऑपरेशन लॉग (oplog) दर्ज करें।
Oplog रेप्लिका को सिंक्रनाइज़ रखने के लिए मध्यस्थ है; अनिवार्य रूप से क्रम में लागू किए जाने वाले डेल्टा ऑपरेशन की एक श्रृंखला प्रदान करता है। यह कुछ अन्य डेटाबेस क्लस्टर कॉन्फ़िगरेशन के समान है।
अनुकूलित ऑपरेशन के दौरान, oplog को प्राथमिक के साथ यथासंभव रीयलटाइम के करीब निष्पादित किया जाता है, हालांकि MongoDB ड्रिफ्ट की अनुमति देता है। मल्टी-साइट ऑपरेशन के दौरान, हालांकि, वायर विलंबता और ऑपरेशन विलंबता स्टैक कर सकते हैं जिससे अधिक ड्रिफ्ट आ सकता है और इस कॉन्फ़िगरेशन के लिए निम्नलिखित चुनौतियां पेश कर सकते हैं:
- Oplog कार्यात्मक रूप से कमांड का एक स्टैक है।
- कई स्टैक की तरह, यह फर्स्ट-इन - फर्स्ट-आउट है।
- स्टैक व्यवहार निर्देश देता है कि, जब अगला पुश अन-पॉप्ड रिकॉर्ड को ओवरराइट करेगा, तो डेटा हानि होगी।
MongoDB प्रोग्रामर ने इस स्थिति को पकड़ने और संबोधित करने के लिए चुना है कि रेप्लिका को रोक दिया जाए, पुनर्निर्माण किया जाए, और इसके पुनर्निर्माण के बाद (नए) oplog से आगे सिंक किया जाए।
सतह पर, इस ऑपरेशन के बारे में कुछ भी विदेशी या खतरनाक नहीं है। पहले पुनर्निर्माण ऑपरेशन पर विचार करें, जो सभी डेटा को मिटा देता है और फिर ज्ञात-अच्छे प्राथमिक से एक ताजा प्रति खींचता है। यहां तक कि अगर निर्यात पूरा होने में शून्य सेकंड लगते हैं, तो एक विलंबित तार में डेटा वॉल्यूम की प्रति स्वाभाविक रूप से दूरस्थ रेप्लिका के आयात समाप्त होने से पहले ड्रिफ्ट पेश करेगी। यह भी मान लें कि वायर विलंबता एकमात्र चुनौती है, इसलिए, पुनर्निर्माण के बाद, oplog में केवल पुनर्निर्माण द्वारा पेश किया गया ड्रिफ्ट होता है। मूल मुद्दा जिसने रेप्लिकेशन लैग को ट्रिगर किया वह बना रहता है, इसलिए यह उम्मीद की जा सकती है कि, समय के साथ, नवनिर्मित द्वितीयक को फिर से पुनर्निर्माण करने के लिए मजबूर किया जाएगा।
कुछ मामलों में, यह व्यवहार रेप्लिकेशन लैग और पुनर्निर्माण के एक अंतहीन लूप में प्रवेश करता है, जिसके परिणामस्वरूप दूरस्थ द्वितीयक होते हैं जो कभी भी कार्यात्मक स्थिति में नहीं होते हैं।
AEM के लिए, इसका मतलब है कि क्रॉस-साइट ऑथरिंग के लिए प्राथमिक डेटा स्रोत के रूप में MongoDB रेप्लिका का उपयोग करना दूरस्थ लेखकों को महत्वपूर्ण जोखिम में डालता है।
