क्या जानना है जब उत्पादन में MongoDB के साथ काम करना शुरू करें - दस युक्तियाँ

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

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

हाल ही में "सबसे खराब स्थिति" के अनुभव में, मैं उन दस्तावेज़ों के संग्रह को क्वेरी करने का प्रयास कर रहा था जिनमें बड़ी सरणियाँ थीं और परिणाम वापस पाने में मुझे उम्र लग गई। मैंने इस ब्लॉग को लिखने का फैसला किया क्योंकि मुझे पता था कि अगर कोई ऐसी ही समस्याओं का अनुभव करता है तो यह ब्लॉग बहुत मददगार होगा।

उत्पादन में MongoDB के लिए मुख्य विचार

1. सुरक्षा और प्रमाणीकरण।
2. आपके दस्तावेज़ों को अनुक्रमित करना
3. अपने संग्रह में स्कीमा का उपयोग करना
4. कैप्ड संग्रह
5. दस्तावेज़ का आकार
6. एम्बेडेड दस्तावेज़ों के लिए सरणी आकार
7. एकत्रीकरण पाइपलाइन चरण
8. हैश ऑब्जेक्ट में कुंजियों का क्रम
9. MongoDB में 'अपरिभाषित' और 'शून्य'
10. ऑपरेशन लिखें

MongoDB सुरक्षा और प्रमाणीकरण

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

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

डेटा को बाहरी इंजेक्शन हमलों से बचाना भी एक आवश्यक उपक्रम है। कुछ ऑपरेटर जैसे $group, $जिसके द्वारा और mapReduce संचालन जावास्क्रिप्ट (js) विकसित होते हैं इसलिए js हेरफेर के लिए प्रवण होते हैं। परिणामस्वरूप डेटा अखंडता के किसी भी उदाहरण से बचने के लिए, यदि आपने किसी भी उल्लिखित ऑपरेटर का उपयोग नहीं किया है, तो आप पैरामीटर को कॉन्फ़िगर करके मनमाने ढंग से जेएस सेटिंग को अक्षम कर सकते हैं जावास्क्रिप्ट सक्षम:गलत कॉन्फ़िगरेशन फ़ाइल में। इसके अलावा, आप MongoDB सुरक्षा चेकलिस्ट में हाइलाइट की गई कुछ प्रक्रियाओं को लागू करके नेटवर्क उल्लंघनों के माध्यम से डेटा एक्सेस के जोखिम को कम कर सकते हैं।

आपके दस्तावेज़ों को अनुक्रमित करना

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

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

अपने संग्रह में किसी स्कीमा का उपयोग करना

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

अपना मॉडल बनाने से पहले आपको दस्तावेज़ों के बीच मुख्य संबंध को समझना होगा। कुछ नियम जो आपको एक इष्टतम स्कीमा बनाने में मदद करेंगे, वे हैं:

1. कुछ डेटा तक पहुंचने से पहले आपको जिन प्रश्नों को निष्पादित करने की आवश्यकता होगी उन्हें कम करने के लिए और यदि कुछ फ़ील्ड या सरणी तत्व शामिल हैं, तो आप उप-दस्तावेज़ एम्बेड कर सकते हैं। नीचे दिए गए मॉडल का एक उदाहरण लें:
   1. ​

      {
       Name: ‘John Doh’,
       Age:20
       Addresses:[
         {street: ‘Moi Avenue’, city:’Nairobi’, countryCode: ‘KE’},
         {street: ‘Kenyatta Avenue’, city:’Nairobi’, countryCode: ‘KE’},
       ]
      }
      

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

स्कीमा की मॉडलिंग अक्सर एप्लिकेशन एक्सेस पैटर्न द्वारा निर्धारित की जाती है। आप अधिक प्रक्रियाएँ पा सकते हैं जो आपके मॉडल के डिज़ाइन में मदद कर सकती हैं ब्लॉग 6 नियम MongoDB स्कीमा डिज़ाइन के लिए अंगूठे के नियम

हाल के दस्तावेज़ों की प्राथमिकता के लिए कैप्ड संग्रह का उपयोग करें

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

कैप्ड संग्रह का उदाहरण उपयोग के मामले:

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

MongoDB दस्तावेज़ आकार पर ध्यान दें

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

एम्बेडेड दस्तावेज़ों के सरणी आकार पर ध्यान दें

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

एकत्रीकरण पाइपलाइन चरण 

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

$limit और $sort का उपयोग करने से हर बार क्वेरी निष्पादित होने पर हमेशा एक ही परिणाम देना चाहिए। यदि आप $limit का उपयोग करते हैं तो लौटाया गया डेटा नियतात्मक नहीं होगा और कुछ ऐसे मुद्दों को प्रस्तुत कर सकता है जिन्हें ट्रैक करना मुश्किल है।

हैश ऑब्जेक्ट्स में चाबियों का क्रम जांचें

नमूना डेटा वाले दो बड़े दस्तावेज़ रखने पर विचार करें 

{

   FirstName: ‘John’,

   LastName: ‘Doh’

}

यदि आप {प्रथम नाम:'जॉन', अंतिम नाम:'दोह'} क्वेरी के साथ कोई खोज कार्रवाई करते हैं, तो कार्रवाई क्वेरी से मेल नहीं खाती {अंतिम नाम:'दोह' प्रथम नाम:'जॉन' }. इसलिए आपको अपने दस्तावेज़ों में नाम और मूल्य जोड़े के क्रम को बनाए रखने की आवश्यकता है।

MongoDB में 'अपरिभाषित' और 'नल' से बचें

MongoDB अपने दस्तावेज़ों के लिए BSON प्रारूप का उपयोग करता है। JSON सत्यापन के साथ, 'अपरिभाषित' समर्थित नहीं है और आपको इसका उपयोग करने से बचना चाहिए। $null समाधान के रूप में आता है लेकिन आपको इससे भी बचना चाहिए।

लेखन संचालन पर विचार करें

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

निष्कर्ष

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