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

यदि आपको अचानक ऐसा लगता है कि मैं MongoDB की सुरक्षा कर रहा हूं, तो कृपया लेख के अंत में अस्वीकरण पढ़ें।

नया चलन

मैं सॉफ्टवेयर उद्योग में शालीनता से बोलने के लिए पर्याप्त समय से अधिक समय से काम कर रहा हूं, लेकिन सभी एक ही, हमारे उद्योग को हिट करने वाले रुझानों का एक छोटा सा हिस्सा मेरे लिए जिम्मेदार है। मैंने 4GL, AOP, Agile, SOA, Web 2.0, AJAX, blockchain ... की वृद्धि देखी है, सूची अंतहीन है। हर साल नए ट्रेंड दिखाई देते हैं। कुछ जल्दी से दूर हो जाते हैं, जबकि अन्य मौलिक रूप से सॉफ्टवेयर विकसित करने के तरीके को बदलते हैं।

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

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

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

और डेवलपर्स ने उस पर हमला किया। यह स्कीमा के बिना एक डेटाबेस के लिए एक बहुत ही आकर्षक विचार था जो किसी भी समस्या को हल करने के लिए जादुई पैमाने पर होता है। 2014 के आसपास, ऐसा लगता है कि हर जगह जहां एक साल पहले एक रिलेशनल डेटाबेस का उपयोग किया जाता था, जैसे कि MySQL, Postgres या SQL Server, MongoDB डेटाबेस को तैनात किया जाने लगा। इस सवाल पर कि, आप इस विचारशील "वेब का पैमाना है" से अधिक "मेरे डेटा को बहुत खराब तरीके से संरचित किया गया है और एक योजना के बिना डेटाबेस में अच्छी तरह से फिट बैठता है"।

यह याद रखना महत्वपूर्ण है कि MongoDB और दस्तावेज़ डेटाबेस आमतौर पर पारंपरिक संबंधपरक डेटाबेस के साथ कई समस्याओं का समाधान करते हैं:

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

सभी जोखिम आप पर हैं।

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

निष्पक्षता में, 10gen / MongoDB इंक में कोई नहीं उसने यह नहीं कहा कि यह सच नहीं है, यह सिर्फ एक समझौता है।

• लेन - देन की हानि : लेन-देन कई संबंधपरक डेटाबेस की एक प्रमुख विशेषता है (सभी नहीं, लेकिन अधिकांश)। लेन-देन का मतलब है कि आप कई ऑपरेशनों को परमाणु रूप से कर सकते हैं और गारंटी दे सकते हैं कि डेटा सुसंगत रहेगा। बेशक, एक NoSQL डेटाबेस के साथ, लेन-देन एक ही दस्तावेज़ के भीतर हो सकता है, या आप ट्रांजेक्शनल शब्दार्थ प्राप्त करने के लिए दो-चरण का उपयोग कर सकते हैं। लेकिन आपको इस कार्यक्षमता को स्वयं लागू करना होगा ... जो एक जटिल और समय लेने वाला कार्य हो सकता है। अक्सर आप समस्या से अवगत नहीं होते हैं जब तक आप यह नहीं देखते हैं कि डेटाबेस में डेटा अस्वीकार्य अवस्थाओं में आता है, क्योंकि संचालन की परमाणुता की गारंटी करना असंभव है। नोट: कई लोगों ने मुझे बताया कि लेन-देन MongoDB 4.0 में पिछले साल दिखाई दिया था, लेकिन कई सीमाओं के साथ। लेख से निष्कर्ष समान रहता है: मूल्यांकन करें कि तकनीक आपकी आवश्यकताओं को कैसे पूरा करती है।
  
• संबंधपरक अखंडता का नुकसान (विदेशी चाबियाँ) : यदि आपके डेटा में कोई संबंध है, तो आपको इसे एप्लिकेशन में लागू करना होगा। इन रिश्तों के अनुपालन में डेटाबेस होने से काम का एक महत्वपूर्ण हिस्सा आवेदन से हट जाएगा और इसलिए, आपके प्रोग्रामर से।
  
• डेटा संरचना को लागू करने की क्षमता का अभाव : सख्त योजनाएं कभी-कभी एक बड़ी समस्या बन जाती हैं, लेकिन यह अच्छी डेटा संरचना के लिए एक शक्तिशाली तंत्र भी है, अगर इसका सही उपयोग किया जाए। MongoDB जैसे दस्तावेज़ डेटाबेस अविश्वसनीय स्कीमा लचीलापन प्रदान करते हैं, लेकिन यह लचीलापन डेटा को साफ रखने की ज़िम्मेदारी को हटा देता है। यदि आप उनकी देखभाल नहीं करते हैं, तो अंत में आपको उस डेटा के लिए खाते में बहुत सारे कोड लिखना होगा जो उस रूप में संग्रहीत नहीं है जो आप अपेक्षा करते हैं। जैसा कि हमारी कंपनी अक्सर सिंपल थ्रेड कहती है ... किसी दिन एप्लिकेशन को फिर से लिखा जाएगा, और डेटा हमेशा के लिए जीवित रहेगा। नोट: MongoDB स्कीमा सत्यापन का समर्थन करता है: यह उपयोगी है, लेकिन रिलेशनल डेटाबेस में समान गारंटी प्रदान नहीं करता है। सबसे पहले, स्कीमा चेक को जोड़ना या संशोधित करना संग्रह में मौजूदा डेटा को प्रभावित नहीं करता है। आपको स्वयं सुनिश्चित करना होगा कि आप नई योजना के अनुसार डेटा को अपडेट करें। अपने लिए तय करें अगर यह आपकी आवश्यकताओं के लिए पर्याप्त है।
  
• देशी क्वेरी भाषा / उपकरणों के पारिस्थितिकी तंत्र का नुकसान : एसक्यूएल का आगमन एक पूर्ण क्रांति बन गया है, और तब से कुछ भी नहीं बदला है। यह एक अविश्वसनीय रूप से शक्तिशाली भाषा है, लेकिन काफी जटिल भी है। JSON अंशों से मिलकर एक नई भाषा में डेटाबेस प्रश्नों को डिजाइन करने की आवश्यकता को SQL के साथ अनुभव करने वाले लोगों द्वारा एक बड़ा कदम माना जाता है। उपकरण का एक संपूर्ण ब्रह्मांड है जो SQL डेटाबेस के साथ बातचीत करता है: IDE से रिपोर्टिंग टूल तक। SQL का समर्थन नहीं करने वाले डेटाबेस में जाने का अर्थ है कि आप इनमें से अधिकांश टूल का उपयोग नहीं कर सकते हैं या आपको इनका उपयोग करने के लिए डेटा को SQL में बदलने की आवश्यकता है, और यह आपके विचार से अधिक कठिन हो सकता है।

कई डेवलपर्स जिन्होंने मोंगोबीडी की ओर रुख किया, वे वास्तव में ट्रेड-ऑफ्स को नहीं समझते थे, और अक्सर हेडलॉन्ग करते थे, इसे प्राथमिक स्टोर स्टोर के रूप में स्थापित किया। इसके बाद, वापस जाना अक्सर अविश्वसनीय रूप से मुश्किल था।

अलग तरीके से क्या किया जा सकता था?

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

सही तकनीक का चयन कैसे करें? प्रौद्योगिकियों के मूल्यांकन के लिए एक व्यवस्थित ढांचा बनाने के लिए कई प्रयास किए गए हैं, जैसे "सॉफ़्टवेयर संगठनों में प्रौद्योगिकियों को प्रस्तुत करने के लिए फ़्रेमवर्क" और "सॉफ़्टवेयर तकनीकों का मूल्यांकन करने के लिए फ़्रेमवर्क" , लेकिन यह मुझे लगता है कि यह अनावश्यक जटिलता है।

कई तकनीकों का मूल्यांकन केवल दो बुनियादी प्रश्न पूछकर किया जा सकता है। समस्या उन लोगों को ढूंढ रही है जो जवाब देने के लिए ज़िम्मेदारी से जवाब दे सकते हैं, समय बिता सकते हैं और बिना पूर्वाग्रह के खोज कर सकते हैं।

यदि आपको कोई समस्या नहीं आती है, तो आपको एक नए टूल की आवश्यकता नहीं है। बिंदु।

प्रश्न 1: मैं किन समस्याओं को हल करने की कोशिश कर रहा हूं?

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

प्रश्न 2: मैं क्या खो रहा हूँ?

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

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

लोग हमेशा सब कुछ खराब करते हैं

इन सवालों का निष्पक्ष रूप से यथासंभव जवाब देने की कोशिश करते हुए, एक बात याद रखें: आपको मानव स्वभाव से संघर्ष करना होगा। कई संज्ञानात्मक पूर्वाग्रह हैं जिन्हें प्रभावी ढंग से प्रौद्योगिकी का मूल्यांकन करने के लिए दूर किया जाना चाहिए। यहाँ कुछ ही हैं:

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

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

सारांश

जब एक निश्चित नवाचार प्रकट होता है, तो दो प्रश्नों का उत्तर बहुत सावधानी से दिया जाना चाहिए:

• क्या यह उपकरण एक वास्तविक समस्या को हल करता है?
  
• क्या हम समझौता करना अच्छी तरह समझते हैं?

यदि आप आत्मविश्वास से इन दो प्रश्नों का उत्तर नहीं दे सकते हैं, तो कुछ कदम पीछे लें और सोचें।

तो क्या MongoDB आम तौर पर सही विकल्प था? बेशक, हाँ; अधिकांश इंजीनियरिंग प्रौद्योगिकियों के साथ, यह कई कारकों पर निर्भर करता है। इन दो सवालों का जवाब देने वालों में, कई ने MongoDB से लाभ उठाया है और इससे लाभ उठा रहे हैं। जिसने भी ऐसा नहीं किया, मुझे उम्मीद है कि उन्हें प्रचार चक्र के साथ आंदोलन के बारे में एक मूल्यवान और बहुत दर्दनाक सबक नहीं मिला।

त्याग

मैं स्पष्ट करना चाहता हूं कि मुझे न तो मोंगोबीडी के लिए प्यार है और न ही नफरत है। यह सिर्फ इतना है कि हमारे पास ऐसी समस्याएं नहीं हैं जिनके लिए MongoDB सबसे उपयुक्त है। मुझे पता है कि 10gen / MongoDB इंक। सबसे पहले, उसने बहुत साहसपूर्वक काम किया, असुरक्षित डिफ़ॉल्ट मान सेट किया और किसी भी डेटा के साथ काम करने के लिए एक सार्वभौमिक समाधान के रूप में हर जगह (विशेषकर हैकाथॉन पर) मोंगोडीबी को बढ़ावा दिया। यह शायद एक बुरा निर्णय था। लेकिन यह यहां वर्णित दृष्टिकोण की पुष्टि करता है: इन समस्याओं को तकनीक के सतही मूल्यांकन के साथ भी बहुत जल्दी पता लगाया जा सकता है।