MongoDB: एप्लिकेशन सर्वर पर मोंगोस प्रक्रिया का सह-पता लगाता है

Question

मैं इस दस्तावेज़ में वर्णित सर्वोत्तम अभ्यास के बारे में एक प्रश्न पूछना चाहता हूं:

http://info.mongodb.com/rs/mongodb/images/MongoDB-Performance-Best-Practices.pdf

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

हमारी तैनाती के बारे में बस थोड़ी सी पृष्ठभूमि। हमारे पास बहुत सारे एप्लिकेशन सर्वर नोड हैं। उनमें से प्रत्येक स्टेटलेस RESTful WS के साथ एक JVM- आधारित प्रक्रिया चलाता है। जैसा कि यह सबसे अच्छा अभ्यास बताता है, हर एक अनुप्रयोग सर्वर नोड अपनी mongosप्रक्रिया चलाता है, जिसका अर्थ है कि जेवीएम प्रक्रियाओं की संख्या हमेशा प्रक्रियाओं की संख्या के बराबर होती mongosहै।

सभी mongosप्रक्रियाएं 3 कॉन्फिग सर्वर और कई मोंगो शार्क (प्रत्येक शार्प के भीतर प्रतिकृति सेट के साथ) से जुड़ती हैं। भले ही हम एक शार्प्ड परिनियोजन का उपयोग कर रहे हैं, हम वास्तव में अपने संग्रह में तेजी नहीं ला रहे हैं। वास्तव में हमारे पास बड़ी संख्या में डेटाबेस हैं जो उनके निर्माण समय के दौरान सभी शार्क के बीच फैले हुए हैं (और यह फिलहाल हमारा मुख्य उपयोग मामला है)।

चूँकि सर्वोत्तम अभ्यास यह भी बताता है कि "मोंगोस प्रक्रियाओं की उचित संख्या आवेदन और तैनाती की प्रकृति पर निर्भर करेगी" मुझे आश्चर्य है कि क्या हमारा उपयोग mongosवास्तव में उचित है या यदि हमारे लिए कई समर्पित mongosनोड्स होना बेहतर है या नहीं हमारे ऐप सर्वर mongosस्थानीय रूप से चलने के बिना उनसे कनेक्ट होते हैं ।

mongosएप्लिकेशन सर्वर इंस्टेंस काउंट या MongbDB क्लस्टर के आकार के संबंध में कितने उदाहरण उपयुक्त हैं, यह तय करने के लिए सबसे अच्छे दृष्टिकोण पर आपकी राय क्या है ?

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

Answer 1

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

सच यह है कि "वास्तव में आपका आवेदन डेटा का उपयोग कैसे करता है" पर विचार करना है, और यह भी कि "प्रभावित वातावरण" में कारकों के बारे में पता होना चाहिए और साथ ही आपके प्रस्तावित "कंटेनर पर्यावरण" जो इसे प्रभावित करते हैं।

पृष्ठभूमि का मामला

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

"डॉकटर" मामला जिसका आप उल्लेख करते हैं, वह कुछ हद तक मनमाना लगता है। हालांकि यह सच है कि कंटेनरों के प्राथमिक लक्ष्यों में से एक (और उससे पहले, बीएसडी जेल या चुरोट की तरह कुछ) आम तौर पर "प्रक्रिया अलगाव" के कुछ स्तर को प्राप्त करने के लिए है, जब तक आप कई प्रक्रियाओं को चलाने के साथ वास्तव में कुछ भी गलत नहीं है। निहितार्थ को समझें।

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

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

संस्करण विशिष्ट / उपयोग विशिष्ट

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

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

टेस्ट, टेस्ट और फिर टेस्ट

यहाँ अंतिम बिंदु वास्तव में आत्म व्याख्यात्मक है, और आपके प्रश्न के किसी भी समझदार प्रतिक्रिया की मूल सहमति के लिए नीचे आता है। यह MongoDB या किसी अन्य संग्रहण समाधान के लिए कोई नई बात नहीं है, लेकिन आपके वास्तविक परिनियोजन के वातावरण को "उपयोग पैटर्न" पर परीक्षण करने की आवश्यकता है जो वास्तविक वास्तविकता के करीब है जितना कि मुख्य घटकों से अपेक्षित कार्यक्षमता का कोई "यूनिट परीक्षण" नहीं है। समग्र परिणामों का परीक्षण करने की आवश्यकता है।

वास्तव में "इस तरह से कॉन्फ़िगर करें" या "इस तरह से उपयोग करें" कहने के लिए "निश्चित" बयान नहीं है जो वास्तव में आपके आवेदन प्रदर्शन और विश्वसनीयता के लिए "वास्तव में सबसे अच्छा काम करता है" परीक्षण के अलावा समझ में आता है।

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

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

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

Answer 2

चूँकि सर्वोत्तम प्रथा यह भी बताती है कि "मोंगोस प्रक्रियाओं की उचित संख्या अनुप्रयोग और परिनियोजन की प्रकृति पर निर्भर करेगी" मुझे आश्चर्य होने लगा कि क्या वास्तव में मोंगोस का उपयोग उचित है?

मुझे लगता है कि यह एक ऐसा सवाल है जिसका अंततः केवल आप ही जवाब दे सकते हैं, जैसा कि प्रलेखन का संदर्भ है।

अनुशंसित रणनीतियों में से एक mongosमें प्रत्येक एप्लिकेशन नोड पर एक सेवा है और संभवतः अतिरिक्त उपलब्धता के लिए एक अतिरिक्त समर्पित नोड भी है। जैसा कि वर्तमान में आपके पास है, मुझे आपकी वर्तमान तैनाती में कुछ भी गलत नहीं दिखता है। यदि आपकी वास्तुकला में कुछ भी नहीं बदल रहा है, तो आप वर्तमान में सर्वोत्तम प्रथाओं के भीतर हैं। हालाँकि...

यदि हम डॉकर का उपयोग कर रहे हैं, तो कंटेनर के भीतर एक से अधिक प्रक्रिया को चलाने के लिए आम तौर पर हतोत्साहित किया जाता है।

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

मैं व्यक्तिगत रूप से इन उत्पादों से बहुत परिचित नहीं हूं, लेकिन मैं विक्रेता के साथ उनकी सिफारिशों पर भी जांच करूंगा क्योंकि mongosआपके द्वारा अगल-बगल चलने वाली अधिकांश अन्य प्रक्रियाओं की तुलना में कम गहन हो सकता है।

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

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

आप इस वीडियो को MongoDB M102 ऑनलाइन पाठ्यक्रम से देख सकते हैं, जो इन विषयों पर जाता है और अगली बार सत्र (मुक्त, ऑनलाइन) में DBAs वर्ग के लिए M102 के लिए साइन अप करने का प्रयास करना चाहता है ।

Comments

महान उत्तर के लिए धन्यवाद! "लेकिन अगर आप समर्पित नोड्स का उपयोग करने जा रहे हैं, तो मैं एप्लिकेशन नोड्स की संख्या को यथासंभव निकटता से मिलान करने का प्रयास करूंगा।" इस कथन के पीछे क्या तर्क है?

— दसवीं

मेरी राय: ज्यादातर मामलों में शार्क की तुलना में कम एप्लिकेशन नोड होते हैं, और चूंकि एक सिफारिश के लिए ऐप नोड्स का उपयोग करना है mongos, इसलिए समान संख्या में समर्पित नोड्स प्रदान करना चाहिए कम से कम पर्याप्त mongosउदाहरण । यह एक सटीक विज्ञान नहीं है और आपकी आवश्यकताओं पर निर्भर करता है, लेकिन यह है कि मैं एक उत्पादन वातावरण कैसे पसंद करूंगा।

— लोवलीडा