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

यदि तपाईंलाई म MongoDB को रक्षा गर्दैछु जस्तो लाग्छ भने, कृपया पढ्नुहोस् अस्वीकरण लेखको अन्त्यमा।

नयाँ प्रवृत्ति

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

प्रत्येक नयाँ प्रवृतिले सामान्य उत्साह सिर्जना गर्दछ: मानिसहरू या त बोर्डमा हाम फाल्छन्, वा अरूले उत्पन्न गरेको आवाज देख्छन् र भीडलाई पछ्याउँछन्। यो प्रक्रिया गार्टनर द्वारा संहिताबद्ध गरिएको छ प्रचार चक्र। विवादास्पद भए तापनि, यो टाइमलाइनले प्रविधिहरूलाई अन्ततः उपयोगी हुन अघि के हुन्छ भनेर वर्णन गर्छ।

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

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

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

यो सम्झना महत्त्वपूर्ण छ कि MongoDB, र सामान्यतया कागजात डाटाबेसहरू, परम्परागत रिलेशनल डाटाबेसहरूसँग धेरै समस्याहरू समाधान गर्छन्:

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

सबै जोखिम तपाईं मा छन्

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

निष्पक्ष हुन, 10gen/MongoDB Inc मा कोही पनि छैन। निम्न सत्य होइन भन्ने छैन, यी केवल सम्झौताहरू हुन्।

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

MongoDB मा फर्केका धेरै विकासकर्ताहरूले ट्रेड-अफहरू वास्तवमै बुझेनन्, र प्रायः यसलाई आफ्नो प्राथमिक डाटा स्टोरको रूपमा स्थापना गर्न हेडफर्स्टमा डुबे। यस पछि यो अक्सर अविश्वसनीय रूपमा फर्कन गाह्रो थियो।

यसभन्दा फरक के गर्न सकिन्थ्यो र ?

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

सही प्रविधि कसरी छनौट गर्ने? प्रविधि मूल्याङ्कनका लागि व्यवस्थित ढाँचा सिर्जना गर्ने धेरै प्रयासहरू भएका छन्, जस्तै "सफ्टवेयर संगठनहरूमा टेक्नोलोजीहरू परिचयको लागि फ्रेमवर्क" и "सफ्टवेयर प्रविधिहरू मूल्याङ्कन गर्न फ्रेमवर्क"तर यो अनावश्यक जटिलता हो जस्तो लाग्छ।

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

यदि तपाइँ कुनै समस्याको सामना गरिरहनुभएको छैन भने, तपाइँलाई नयाँ उपकरणको आवश्यकता पर्दैन। डट।

प्रश्न १: म कुन समस्याहरू समाधान गर्न खोज्दै छु?

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

प्रश्न 2: म के हराइरहेको छु?

यो पक्कै पनि धेरै गाह्रो प्रश्न हो किनभने तपाईले पुरानो र नयाँ टेक्नोलोजी दुवैको राम्रोसँग बुझ्नु पर्छ। कहिलेकाहीँ तपाईले नयाँलाई बुझ्न सक्नुहुन्न जबसम्म तपाईले यसको साथ केहि निर्माण गर्नुहुन्न वा त्यो अनुभव भएको कसैलाई छैन।

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

मानिसहरूले सधैं सबै कुरा बर्बाद गर्छन्

तपाईंले यी प्रश्नहरूको जवाफ सकेसम्म निष्पक्ष रूपमा दिने प्रयास गर्दा, एउटा कुरा याद गर्नुहोस्: तपाईंले मानव प्रकृतिसँग लड्नु पर्नेछ। त्यहाँ धेरै संज्ञानात्मक पूर्वाग्रहहरू छन् जुन टेक्नोलोजीलाई प्रभावकारी रूपमा मूल्याङ्कन गर्न परास्त गर्नुपर्छ। यहाँ केही मात्र छन्:

• बहुमतमा सामेल हुनुको प्रभाव - सबैलाई उनको बारेमा थाहा छ, तर अझै पनि उहाँसँग लड्न गाह्रो छ। केवल निश्चित गर्नुहोस् कि टेक्नोलोजी वास्तवमा तपाईंको वास्तविक आवश्यकताहरूसँग मेल खान्छ।
• नवीनता प्रभाव — धेरै विकासकर्ताहरूले उनीहरूले लामो समयदेखि काम गरेका प्रविधिहरूलाई कम आँकलन गर्ने र नयाँ प्रविधिका फाइदाहरूलाई बढी मूल्याङ्कन गर्ने गर्छन्। यो केवल प्रोग्रामरहरू होइन, सबैजना यस संज्ञानात्मक पूर्वाग्रहको लागि संवेदनशील छन्।
• सकारात्मक विशेषताहरु को प्रभाव - हामी त्यहाँ के छ भनेर हेर्ने झुकाव राख्छौं र के हराइरहेको छ भन्ने कुरालाई गुमाउँछौं। नवीनता प्रभावसँग जोड्दा यसले अराजकता निम्त्याउन सक्छ, किनकि तपाईंले स्वाभाविक रूपमा नयाँ प्रविधिलाई अतिमूल्य मात्र होइन, तर यसका कमजोरीहरूलाई पनि बेवास्ता गर्नुहुन्छ।.

वस्तुगत मूल्याङ्कन सजिलो छैन, तर अन्तर्निहित संज्ञानात्मक पूर्वाग्रहहरू बुझ्नले तपाईंलाई थप तर्कसंगत निर्णयहरू गर्न मद्दत गर्नेछ।

सारांश

जब कुनै नवीनता देखा पर्दछ, दुई प्रश्नहरूको जवाफ धेरै सावधानीका साथ दिनुपर्दछ:

• के यो उपकरणले वास्तविक समस्या समाधान गर्छ?
• के हामीले ट्रेड-अफहरू राम्ररी बुझेका छौं?

यदि तपाइँ यी दुई प्रश्नहरूको निर्धक्क जवाफ दिन सक्नुहुन्न भने, केहि कदम पछाडि जानुहोस् र सोच्नुहोस्।

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

अस्वीकरण

म यो स्पष्ट गर्न चाहन्छु कि म MongoDB सँग प्रेम र घृणाको सम्बन्ध छैन। हामीसँग त्यस प्रकारको समस्याहरू छैनन् जुन मोन्गोडीबी समाधान गर्नका लागि उपयुक्त छ। मलाई थाहा छ कि 10gen/MongoDB Inc. सुरुमा धेरै बोल्ड थियो, असुरक्षित पूर्वनिर्धारितहरू सेट गर्दै र मङ्गोडीबीलाई जताततै (विशेष गरी ह्याकाथनहरूमा) कुनै पनि डेटासँग काम गर्नको लागि विश्वव्यापी समाधानको रूपमा प्रवर्द्धन गर्दै। यो शायद एक खराब निर्णय थियो। तर यसले यहाँ वर्णन गरिएको दृष्टिकोणलाई पुष्टि गर्छ: प्रविधिको सतही मूल्याङ्कन गरेर पनि यी समस्याहरू चाँडै पत्ता लगाउन सकिन्छ।

स्रोत: www.habr.com