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

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

नया चलन

मैं सॉफ्टवेयर उद्योग में कहने के लिए उचित से अधिक वर्षों से हूं, लेकिन फिर भी मैं केवल उन रुझानों का हिस्सा रहा हूं जो हमारे उद्योग को प्रभावित करते हैं। मैंने 4जीएल, एओपी, एजाइल, एसओए, वेब 2.0, एजेएक्स, ब्लॉकचैन... का उदय देखा है, यह सूची अंतहीन है। हर साल नए चलन होते हैं। कुछ तेजी से लुप्त हो रहे हैं, जबकि अन्य मौलिक रूप से सॉफ्टवेयर विकसित करने के तरीके को बदल रहे हैं।

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

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

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

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

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

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

सारा जोखिम आप पर है

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

निष्पक्ष होने के लिए, 10gen/MongoDB Inc. में कोई नहीं है। यह नहीं कहेंगे कि निम्नलिखित सत्य नहीं है, ये केवल समझौता हैं।

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

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

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

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

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

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

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

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

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

प्रश्न 2: मुझे क्या याद आ रहा है?

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

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

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

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

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

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

सारांश

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

• क्या यह उपकरण वास्तविक समस्या का समाधान करता है?
• क्या हम व्यापार-नापसंद को समझने में अच्छे हैं?

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

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

исклеймер

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

स्रोत: www.habr.com