MongoDB जीवन रक्षा गाइड

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



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

पहली मुश्किलें

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

यदि समस्याओं को ऐसे सरल तरीकों से हल किया जा सकता है, तो उन्हें इस तरह से हल किया जाना चाहिए।

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

धीमी रिकॉर्डिंग

यह उन समस्याओं में से एक है जिनका आप सामना कर सकते हैं। यदि आप उससे मिलते हैं तो क्या करें, और ऊपर दिए गए तरीके मदद नहीं करते हैं? उत्तर: डिफ़ॉल्ट रूप से MongoDB में स्थायित्व गारंटी मोड । तीन शब्दों में यह इस तरह काम करता है:

• हम प्राथमिक लाइन पर आए और कहा: "लिखो!"।
  
• प्राथमिक प्रतिकृति दर्ज की गई।
  
• उसके बाद, माध्यमिक प्रतिकृतियां उसके पास से पढ़ी गईं और उन्होंने कहा कि प्राथमिक: "हमने दर्ज किया!"
  

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

सौभाग्य से, MongoDB एक ऐसा डेटाबेस है जो आपको प्रत्येक व्यक्तिगत अनुरोध के लिए स्थायित्व की गारंटी देता है।

महत्वपूर्ण अनुरोधों के लिए, हम डिफ़ॉल्ट रूप से अधिकतम स्थायित्व की गारंटी छोड़ सकते हैं, और कुछ अनुरोधों के लिए हम उन्हें कम कर सकते हैं।

अनुरोध कक्षाएं

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

{w:1, j:true} 

यदि हम इस तरह की गारंटी के साथ रिकॉर्ड लिखते हैं, तो उस समय जब हम आवेदन में नियंत्रण प्राप्त करते हैं, हम अब यह नहीं जानते हैं कि किसी तरह की दुर्घटना के बाद रिकॉर्ड जीवित होगा या नहीं। लेकिन आमतौर पर, वह अभी भी जीवित है।

अगली गारंटी, जो बैंडविड्थ और विलंबता को भी प्रभावित करती है, लॉगिंग पुष्टि को अक्षम कर रही है । जर्नल प्रविष्टि वैसे भी लिखी जाती है। पत्रिका मूलभूत तंत्रों में से एक है। यदि हम इसे लिखने की पुष्टि बंद कर देते हैं, तो हम दो काम नहीं करते हैं: लॉग पर fsync और इसके समाप्त होने की प्रतीक्षा न करें । यह बहुत सारे डिस्क संसाधनों को बचा सकता है और गारंटी के स्थायित्व को बदलकर थ्रूपुट में कई वृद्धि प्राप्त कर सकता है ।

 {w:1, j:false} 

सबसे कठोर स्थायित्व गारंटी किसी भी स्वीकार्यता को अक्षम कर रही है। हम केवल पुष्टि प्राप्त करेंगे कि अनुरोध प्राथमिक प्रतिकृति तक पहुंच गया है। यह विलंबता को बचाएगा और किसी भी तरह से थ्रूपुट को नहीं बढ़ाएगा।

 {w:0, j:false} —   . 

हम विभिन्न अन्य चीजें भी प्राप्त करेंगे, उदाहरण के लिए, एक अद्वितीय कुंजी के साथ संघर्ष के कारण रिकॉर्डिंग विफल रही।

यह किन कार्यों पर लागू होता है?

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

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

स्केलिंग पढ़ें

अगली समस्या अपर्याप्त रीडिंग बैंडविड्थ है । याद रखें कि हमारे क्लस्टर में न केवल प्राथमिक प्रतिकृतियां हैं, बल्कि माध्यमिक भी हैं जिनसे आप पढ़ सकते हैं । चलो करते हैं।

आप पढ़ सकते हैं, लेकिन बारीकियां हैं। थोड़ा पुराने डेटा माध्यमिक प्रतिकृतियां - 0.5-1 सेकंड से आएंगे। ज्यादातर मामलों में, यह सामान्य है, लेकिन माध्यमिक प्रतिकृति का व्यवहार प्राथमिक प्रतिकृतियों के व्यवहार से अलग है।

द्वितीयक पर, अफीम का उपयोग करने की प्रक्रिया है, जो प्राथमिक प्रतिकृति पर नहीं है। यह प्रक्रिया कम विलंबता के लिए डिज़ाइन नहीं की गई है - बस MongoDB डेवलपर्स ने इससे परेशान नहीं किया। कुछ शर्तों के तहत, प्राथमिक से माध्यमिक तक ओप्लोग का उपयोग करने की प्रक्रिया में 10 एस तक की देरी हो सकती है।

उपयोगकर्ता प्रश्नों के लिए माध्यमिक प्रतिकृतियां उपयुक्त नहीं हैं - उपयोगकर्ता अनुभव बिन में एक तेज कदम उठाते हैं।

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

कनेक्शन की संख्या

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

हालाँकि, समवर्ती समवर्ती अनुरोध, वे धीमी गति से चलते हैं। प्रदर्शन नॉनलाइन तरीके से घटता है । इसलिए, यदि अनुरोधों की एक स्पाइक हमारे पास आती है, तो 100% की सेवा न करने की तुलना में 80% की सेवा करना बेहतर है। कनेक्शन की संख्या सीधे MongoDB तक सीमित होनी चाहिए।

लेकिन ऐसे कीड़े हैं जो इस वजह से परेशानी पैदा कर सकते हैं। विशेष रूप से, MongoDB पक्ष पर कनेक्शन पूल उपयोगकर्ता और सेवा इंट्राक्लस्टर कनेक्शन दोनों के लिए आम है । यदि आवेदन इस पूल से सभी कनेक्शनों को "खा जाता है", तो क्लस्टर में अखंडता का उल्लंघन हो सकता है।

हमें इस बारे में पता चला कि जब हम सूचकांक का पुनर्निर्माण करने जा रहे थे, और जब से हमें सूचकांक से विशिष्टता को हटाने की आवश्यकता हुई, प्रक्रिया कई चरणों में चली गई। MongoDB में, आप उसी के अनुक्रमणिका के बगल में निर्माण नहीं कर सकते, लेकिन विशिष्टता के बिना। इसलिए, हम चाहते थे:

• विशिष्टता के बिना एक समान सूचकांक बनाएँ
  
• सूचकांक को विशिष्टता के साथ हटा दें;
  
• रिमोट के बजाय विशिष्टता के बिना एक सूचकांक बनाएँ;
  
• अस्थायी हटाएं।
  

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

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

कहानी का नैतिक: कनेक्शन की संख्या की निगरानी की जानी चाहिए।

एक अच्छी तरह से ज्ञात MongoDB रेक है, जो अभी भी अक्सर हमला किया जाता है कि मैंने इस पर एक छोटी सैर करने का फैसला किया।

दस्तावेजों को मत खोना

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

संग्रह आकार

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

• विशिष्ट दस्तावेजों का आकार उनकी लंबाई के साथ खेलने के लिए: Object.bsonsize() ;
  
• संग्रह में दस्तावेज़ के औसत आकार के अनुसार : db.c.stats().avgObjectSize ।
  

दस्तावेज़ के आकार को कैसे प्रभावित करें?

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

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

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

सूचकांक आकार

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

दूसरे क्षण दृढ़ता से सूचकांक को बढ़ाता है : सूचकांक में सरणी फ़ील्ड इस सूचकांक में दस्तावेज़ से अन्य क्षेत्रों को गुणा करें । दस्तावेज़ों में बड़े सरणियों के साथ सावधान रहें: या तो किसी और चीज़ को अनुक्रमित न करें, या उस क्रम के साथ न खेलें जिसमें सूचकांक में फ़ील्ड सूचीबद्ध हैं।

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

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

दस्तावेज़ हटाएँ

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

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

यह थ्रॉटलिंग को चालू करने के लिए किसी प्रकार का "पेन" बनाने के लायक है - पहली बार स्तर को उठाना बहुत मुश्किल है। हम इसके माध्यम से इतनी बार गए कि तीसरे, चौथे समय से थ्रॉटलिंग का अनुमान लगाया जाता है। प्रारंभ में, इसे कसने की संभावना पर विचार करें।

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

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

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

Shardirovanie

हमने इस क्षण को स्थगित करने की कोशिश की, लेकिन यह आ गया है - हमें अभी भी क्षैतिज रूप से स्केल करना है। MongoDB के लिए, यह तेज है।

यदि आपको संदेह है कि आपको शार्किंग की आवश्यकता है, तो आपको इसकी आवश्यकता नहीं है।

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

कुछ चीजों को ठीक से काम नहीं करते। उदाहरण के लिए, skip साथ प्रश्नों का उपयोग करना एक बुरा विचार है, खासकर यदि आपके पास बहुत सारे दस्तावेज़ हैं। आप कमांड देते हैं: "100,000 दस्तावेज़ छोड़ें।"

MongoDB इस तरह से सोचता है: "पहले, दूसरे, तीसरे ... एक सौ हज़ारवें, चलो आगे चलते हैं। और हम इसे उपयोगकर्ता को वापस कर देंगे। ”

एक गैर-साझा संग्रह में, MongoDB अपने भीतर कहीं एक ऑपरेशन करेगा। शार्ग-लाइक में - वह वास्तव में एक तेजतर्रार प्रॉक्सी को सभी 100,000 दस्तावेजों को पढ़ती है और भेजती है - मोंगोस में , जो पहले से ही अपनी तरफ से किसी भी तरह से फ़िल्टर करेगा और पहले 100,000 को छोड़ देगा।

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

शार्क के संग्रह में, count ऑपरेशन टूट जाता है । वह वास्तविकता की तुलना में एक संख्या अधिक वापस करने लगती है - वह 2 बार झूठ बोल सकती है। कारण संतुलन प्रक्रिया में है, जब दस्तावेजों को एक शार्क से दूसरे में डाला जाता है। जब दस्तावेजों को पड़ोसी शारद पर डाला जाता है, लेकिन मूल एक पर अभी तक हटाया नहीं गया है, count उन्हें वैसे भी गिनेंगी। MongoDB डेवलपर्स इसे बग नहीं कहते हैं - यह ऐसी सुविधा है। मुझे नहीं पता कि वे इसे ठीक करेंगे या नहीं।

एक फेरबदल क्लस्टर को प्रशासित करना अधिक कठिन है । देवोप्स आपको नमस्कार करना बंद कर देंगे, क्योंकि बैकअप हटाने की प्रक्रिया मौलिक रूप से अधिक जटिल हो जाती है। जब तेज होता है, तो बुनियादी ढांचे के स्वचालन की आवश्यकता एक आग अलार्म की तरह चमकती है - ऐसा कुछ जो आप पहले बिना कर सकते थे।

MongoDB में कैसे काम करता है?

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

शेयरिंग की

क्या आप अभी भी तय करते हैं कि क्या करना है? खैर, पहला सवाल यह है कि शार्पिंग कुंजी कैसे चुनें। एक अच्छी कुंजी के कई पैरामीटर हैं: उच्च कार्डिनलिटी , गैर-स्थिरता और यह लगातार अनुरोधों में अच्छी तरह से फिट बैठता है ।

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

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

इसलिए, यह ध्यान में रखा जाना चाहिए कि कभी-कभी एक शार्प कुंजी स्वाभाविक रूप से असमान लोड वितरण के लिए जाती है।

संतुलन

जब हमारे लिए आवश्यक चीर-फाड़ होती है, तो हम आते हैं - हमारे मोंगोडीबी क्लस्टर क्रीक, इसके डिस्क, प्रोसेसर के साथ crunches - सब कुछ हम कर सकते हैं। कहाँ जाना है? कहीं नहीं, और हम वीरतापूर्वक संग्रह की ऊँची एड़ी के जूते फेरते हैं। हम शार्क, लॉन्च, और अचानक पता लगाते हैं कि संतुलन मुक्त नहीं है ।

संतुलन कई चरणों से गुजरता है। बाल्कन चांस और शार्क चुनता है, जहां और जहां से वह स्थानांतरित करेगा। आगे का काम दो चरणों में होता है: पहला, दस्तावेजों को स्रोत से लक्ष्य तक कॉपी किया जाता है, और फिर कॉपी किए गए दस्तावेजों को हटा दिया जाता है ।

हमारा शार्क अतिभारित है, इसमें सभी संग्रह हैं, लेकिन ऑपरेशन का पहला भाग उसके लिए आसान है। लेकिन दूसरा - हटाने - काफी अप्रिय है, क्योंकि यह कंधे के ब्लेड पर एक शार्क डाल देगा और पहले से ही लोड के तहत पीड़ित होगा।

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

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

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

शेयरिंग को सावधानीपूर्वक तैयार किया जाना चाहिए।

हाईलाड ++ साइबेरिया 2019 24 और 25 जून को नोवोसिबिर्स्क में आएगा। मॉस्को या सेंट पीटर्सबर्ग के लिए तीन हजार किलोमीटर से अधिक उड़ान भरने के बिना, हाईलोडेड ++ साइबेरिया साइबेरिया के डेवलपर्स के लिए एक अवसर है कि वे हाईड्रोइड विषयों पर बात करें, पर्यावरण पर बात करें और "जहाँ हर किसी के पास अपना है"। 80 आवेदनों में से, कार्यक्रम समिति ने 25 को मंजूरी दे दी, और हम अपनी मेलिंग सूची में कार्यक्रम में अन्य सभी परिवर्तनों, रिपोर्ट की घोषणाओं और अन्य समाचारों के बारे में बताते हैं। सूचित रहने के लिए सदस्यता लें ।