MongoDB
 sql >> डेटाबेस >  >> NoSQL >> MongoDB

उत्पादन के लिए एक MongoDB सर्वर तैयार करना

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

वर्तमान संस्करण और नवीनतम ड्राइवरों का उपयोग करें

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

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

वायर्ड टाइगर स्टोरेज इंजन का उपयोग करने पर भी विचार करें क्योंकि यह आधुनिक सुविधाओं के साथ सबसे विकसित है जो आधुनिक डेटाबेस अपेक्षाओं के अनुरूप है

एक MongoDB मेलिंग सूची की सदस्यता लें ताकि नए संस्करणों और ड्राइवरों में परिवर्तन और बग फिक्स के संबंध में नवीनतम जानकारी प्राप्त की जा सके।

MongoDB चलाने के लिए 64-बिट सिस्टम का उपयोग करें

32-बिट सिस्टम में, MongoDB प्रक्रियाएं लगभग 2.5GB डेटा तक सीमित होती हैं क्योंकि डेटाबेस प्रदर्शन के लिए मेमोरी-मैप की गई फ़ाइलों का उपयोग करता है। यह उन प्रक्रियाओं के लिए एक सीमा बन जाती है जो क्रश की ओर ले जाने वाली सीमा को पार कर सकती हैं। मुख्य प्रभाव यह होगा:किसी त्रुटि के मामले में, जब तक आप अपना डेटा हटाते हैं या अपने डेटाबेस को 64-बिट जैसे उच्च सिस्टम में माइग्रेट नहीं करते हैं, तब तक आप सर्वर को पुनरारंभ नहीं कर पाएंगे, इसलिए आपके एप्लिकेशन के लिए उच्च डाउनटाइम।

यदि आपको 32-बिट सिस्टम का उपयोग करते रहना है, तो थ्रूपुट संचालन के लिए बग और विलंबता की संख्या को कम करने के लिए आपकी कोडिंग बहुत सरल होनी चाहिए।

हालाँकि कोड जटिलताओं जैसे कि एकत्रीकरण पाइपलाइन और जियोडेटा के लिए, 64-बिट सिस्टम का उपयोग करने की सलाह दी जाती है।

सुनिश्चित करें कि दस्तावेज़ 16MB आकार तक सीमित हैं

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

  {

   _id:1,

   post: 'What is in your mind?',

   datePosted: '12-06-2019',

   postedBy:'xyz',

   likes: 10,

   comments: 30

}

और दूसरा उस पोस्ट के लिए टिप्पणी करने के लिए।

     {

   _id: ObjectId('2434k23k4'),

   postId: 1,

   dateCommented: '12-06-2019',

   commentedBy:'ABCD',

   comment: 'When will we get better again',

}

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

सुनिश्चित करें कि वर्किंग सेट मेमोरी में फिट बैठता है

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

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

सुनिश्चित करें कि आपके पास प्रतिकृति सेट हैं

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

यदि प्राथमिक नोड विफल हो जाता है, तो द्वितीयक नोड विफलता के दौरान डाउनटाइम वाले एप्लिकेशन के बजाय लेखन कार्यों को बनाए रखने के लिए एक नए का चुनाव कर सकता है। वास्तव में, कुछ क्लाउड होस्टिंग प्लेटफ़ॉर्म जो प्रतिकृति के साथ काफी विचारशील हैं, उत्पादन वातावरण के लिए गैर-प्रतिकृति MongoDB का समर्थन नहीं करते हैं।

जर्नलिंग सक्षम करें

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

सुनिश्चित करें कि आप एक बैकअप रणनीति सेट अप करते हैं

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

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

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

धीमी क्वेरी के लिए तैयार रहें

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

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

एक मॉनिटरिंग टूल से कनेक्ट करें

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

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

ClusterControl सामुदायिक संस्करण में निःशुल्क MongoDB निगरानी प्रदान करता है।

सुरक्षा उपाय लागू करें

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

  • भूमिका-आधारित अभिगम नियंत्रण को कॉन्फ़िगर करना
  • पहुंच नियंत्रण सक्षम करना और प्रमाणीकरण लागू करना
  • इनकमिंग और आउटगोइंग कनेक्शन एन्क्रिप्ट करना (TLS/SSL)
  • नेटवर्क एक्सपोजर सीमित करना
  • डेटा को एन्क्रिप्ट और सुरक्षित करना
  • डेटाबेस कॉन्फ़िगरेशन तक पहुंच और परिवर्तनों पर एक ट्रैक योजना बनाएं

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

हार्डवेयर और सॉफ़्टवेयर संबंधी विचार 

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

  • पर्याप्त  RAM और CPU असाइन करें
  • WiredTiger स्टोरेज इंजन का उपयोग करें। फाइल सिस्टम कैश और WiredTiger आंतरिक कैश का उपयोग करने के लिए डिज़ाइन किया गया इसलिए प्रदर्शन में वृद्धि हुई। उदाहरण के लिए, 4GB RAM के सिस्टम के साथ काम करते समय WiredTiger कैश 1.5GB RAM (0.5 * (4GB -1GB) =1.5GB) का उपयोग करता है जबकि 1.2GB RAM वाला सिस्टम WiredTiger कैश केवल 256MB का उपयोग करता है।
  • NUMA हार्डवेयर। कई परिचालन मुद्दे हैं जिनमें धीमा प्रदर्शन और उच्च सिस्टम प्रक्रिया उपयोग शामिल हैं, इसलिए, किसी को मेमोरी इंटरलीव नीति को कॉन्फ़िगर करने पर विचार करना चाहिए।
  • डिस्क और स्टोरेज सिस्टम:सॉलिड स्टेट डिस्क (SSDs) का उपयोग करें:MongoDB SATA SSD के साथ बेहतर मूल्य-प्रदर्शन अनुपात दिखाता है

निष्कर्ष

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


  1. Redis
  2.   
  3. MongoDB
  4.   
  5. Memcached
  6.   
  7. HBase
  8.   
  9. CouchDB
  1. Queryable<T> का वापस IMongoQuery में अनुवाद करें

  2. MongoDB त्रुटि 111 . से कनेक्शन से इनकार कर दिया

  3. मोंगोडब-देशी findOne () में फ़ील्ड नाम के रूप में एक चर का उपयोग कैसे करें?

  4. MongoDB 4.4 में नया क्या है?

  5. आईडी के आधार पर अद्यतन सरणी वस्तु?