🕚 👂 🍈 डेवलपर्स और डीबीए के लिए MongoDB 🙂 💪 👸🏽

10gen , एक MongoDB डेवलपर कंपनी से डेवलपर्स और डेटाबेस आर्किटेक्ट के लिए MongoDB पाठ्यक्रम समाप्त हो रहे हैं।
अंतिम परीक्षा सत्यापन के लिए भेजी गई थी और मैं कोर्स के अपने इंप्रेशन और प्राप्त जानकारी को साझा करना चाहूंगा, जो कि MongoDB के पेशेवरों और विपक्षों के बारे में बात करना है।

पाठ्यक्रम की सामान्य छाप

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

ताकत

प्रतिकृति ( मैनुअल )

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

शेयरिंग ( मैनुअल )

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

भौगोलिक संकेत ( मैनुअल )

अब कई स्टार्टअप या सामाजिक सेवाएं। नेटवर्क एक कार्यात्मक का उपयोग करते हैं: उपयोगकर्ता से एक्स किमी की तुलना में कुछ आगे नहीं खोजें। यहां MongoDB में ऐसी कार्यक्षमता के लिए आप भौगोलिक अनुक्रमित का उपयोग कर सकते हैं।

स्कीमा-

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

कैप्ड कलेक्शंस ( मैनुअल )

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

एकत्रीकरण ढांचा ( मैनुअल )

इस ढांचे का उपयोग करके, आप सोर्सिंग डेटा से ग्रुपिंग, समिट, काउंटिंग रिकॉर्ड आदि के साथ नमूने बना सकते हैं। संक्षेप में, यह GROUP BY, COUNT, HAVING, आदि का कार्यान्वयन है। SQL में निर्माण। स्रोत डेटा तथाकथित पाइप की एक सरणी से गुजरता है, जो डेटा को रूपांतरित करता है और इसे अगले पाइप में स्थानांतरित करता है। बहुत कुछ सांत्वना कमांड के समान है: "बिल्ली फ़ाइल | grep स्तन | grep -v छोटा। "

मैप-रिड्यूस ( मैनुअल )

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

नुकसान

यौगिक सूचकांक बाधा

यदि आपके पास कोई प्रविष्टि है जैसे: {a: [1, 2], b: [1, 2]} - अनुक्रमणिका बनाएं a: 1, b: 1} विफल हो जाएगा। वास्तव में, अनुक्रमित क्षेत्रों के साथ एक समान रिकॉर्ड सम्मिलित करना। यहां पढ़ें, "कंपाउंड मल्टीके इंडेक्स को देखें। केवल एक एरियर फील्ड को शामिल करें"

विरल सूचकांक और विशिष्टता ( मैनुअल , विरल सूचकांक)

मान लीजिए कि हमारे पास संग्रह में प्रविष्टियाँ हैं:
{"_id": ObjectId ("50caeec479705c3852e9e61b"), "a": "1"}
{"_id": ObjectId ("50caeeeb79705c3852e9e61d"), "a:" 2 ", 'b': 1}
{"_id": ObjectId ("50caefb179705c3852e9e621"), "a": "3"}
और हम चाहते हैं कि दस्तावेजों की "बी" संपत्ति अद्वितीय हो। यह सामान्य अद्वितीय सूचकांक बनाने के लिए काम नहीं करेगा, पहला और तीसरा रिकॉर्ड माना जाएगा कि b: null और यह विशिष्टता का उल्लंघन करता है।
लेकिन हम एक अनोखा विरल सूचकांक बना सकते हैं, और फिर जिन अभिलेखों में "बी" नहीं है उन्हें इस सूचकांक में शामिल नहीं किया जाएगा। ऐसा लगेगा कि सब कुछ ठीक है, एक सूचकांक बनाया गया है, विशिष्टता है। लेकिन! यदि हम अनुमति देते हैं, तो हम आपको हमारे संग्रह से सभी रिकॉर्डों का चयन करने के लिए कहेंगे और उन्हें फ़ील्ड b द्वारा सॉर्ट करने के लिए कहेंगे, MongoDB ने हमारे द्वारा बनाए गए विरल सूचकांक का उपयोग किया है, जिसमें "b" के बिना कोई रिकॉर्ड नहीं है। नतीजतन, हमें केवल एक प्रविष्टि मिलती है।

अनुप्रयोग इंटरफ़ेस निर्भरता

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

आप शार्प की को नहीं बदल सकते

संग्रह पोस्ट किए जाने के बाद, कुंजी को बदलना स्वचालित रूप से काम नहीं करेगा। इसलिए, कुंजी चुनना एक बहुत ही महत्वपूर्ण ऑपरेशन है। और अधिक पढ़ें docs.mongodb.org/manual/faq/sharding/#faq-change-shard-key

कई दस्तावेजों के भीतर कोई लेनदेन नहीं

एक दस्तावेज़ पर कार्रवाई परमाणु है, लेकिन कई दस्तावेजों के लिए आवेदन स्तर पर लेनदेन का उपयोग करने का प्रस्ताव है। डॉक्स। Mongodb.org/manual/tutorial/perform-two-phase-commits

निष्कर्ष

महान पाठ्यक्रम। MongoDB अपने लचीलेपन और सरलता के साथ लुभावना है, विभिन्न स्थितियों में इसका उपयोग बहुत, बहुत ही उचित है।
यदि किसी को पाठ्यक्रम लेने की इच्छा है, तो 21 जनवरी को पाठ्यक्रम फिर से शुरू होंगे। साथ ही 25 फरवरी को जावा डेवलपर्स के लिए कोर्स शुरू होंगे। https://education.10gen.com/

डेवलपर्स और डीबीए के लिए MongoDB