हे मला नुकतेच कळले Red Hat उपग्रह वरून MongoDB समर्थन काढून टाकते (ते परवान्यातील बदलांमुळे म्हणतात). हे मला विचार करायला लावले कारण गेल्या काही वर्षांत मी MongoDB किती भयंकर आहे आणि कोणीही त्याचा वापर कसा करू नये याबद्दल अनेक लेख पाहिले आहेत. परंतु या काळात, मोंगोडीबी अधिक परिपक्व उत्पादन बनले आहे. काय झालं? नवीन डीबीएमएसच्या सुरुवातीच्या मार्केटिंगमधील चुकांमुळे सर्व द्वेष खरोखरच आहे का? किंवा लोक फक्त चुकीच्या ठिकाणी MongoDB वापरत आहेत?

मी MongoDB चा बचाव करत आहे असे तुम्हाला वाटत असल्यास, कृपया वाचा अस्वीकरण लेखाच्या शेवटी.

नवीन ट्रेंड

मी सांगू शकेन त्यापेक्षा जास्त वर्षे मी सॉफ्टवेअर उद्योगात काम करत आहे, परंतु तरीही मला आमच्या उद्योगाला फटका बसलेल्या ट्रेंडचा फक्त एक छोटासा भागच समोर आला आहे. मी 4GL, AOP, Agile, SOA, Web 2.0, AJAX, Blockchain चा उदय पाहिला आहे... यादी अंतहीन आहे. दरवर्षी नवीन ट्रेंड दिसतात. काही त्वरीत नष्ट होतात, तर काही मूलभूतपणे सॉफ्टवेअर विकसित करण्याचा मार्ग बदलतात.

प्रत्येक नवीन ट्रेंड एक सामान्य उत्साह निर्माण करतो: लोक एकतर बोर्डवर उडी मारतात किंवा इतरांनी निर्माण केलेला आवाज पाहतात आणि गर्दीचे अनुसरण करतात. ही प्रक्रिया गार्टनरने संहिताबद्ध केली आहे हायप सायकल. जरी विवादास्पद असले तरी, ही टाइमलाइन तंत्रज्ञानाचा उपयोग होण्यापूर्वी त्यांचे काय होते याचे अंदाजे वर्णन करते.

परंतु वेळोवेळी, एक नवीन नवकल्पना दिसून येते (किंवा या प्रकरणात दुसरे येत आहे) केवळ एका विशिष्ट अंमलबजावणीद्वारे चालविले जाते. NoSQL च्या बाबतीत, मोंगोडीबीच्या उदय आणि उल्कापातामुळे हाईप मोठ्या प्रमाणावर चालला होता. मोंगोडीबीने हा ट्रेंड सुरू केला नाही: खरं तर, मोठ्या इंटरनेट कंपन्यांना मोठ्या प्रमाणात डेटावर प्रक्रिया करण्यात समस्या येऊ लागल्या, ज्यामुळे गैर-रिलेशनल डेटाबेस परत आले. Google च्या Bigtable आणि Facebook च्या Cassandra सारख्या प्रकल्पांपासून एकंदरीत चळवळ सुरू झाली, परंतु हे MongoDB हे सर्वात सुप्रसिद्ध आणि प्रवेश करण्यायोग्य NoSQL डेटाबेस अंमलबजावणी बनले ज्यामध्ये बहुतेक विकासकांना प्रवेश होता.

टीप: तुम्हाला असे वाटेल की मी स्तंभीय डेटाबेसेस, की/व्हॅल्यू स्टोअर्स किंवा सामान्य NoSQL व्याख्ये अंतर्गत येणाऱ्या इतर असंख्य प्रकारच्या डेटा स्टोअर्ससह दस्तऐवज डेटाबेस गोंधळात टाकत आहे. आणि तू बरोबर आहेस. मात्र त्यावेळी अराजकतेचे राज्य होते. प्रत्येकाला NoSQL चे वेड आहे, ते प्रत्येकाला झाले आहे अगदी आवश्यक आहे, जरी अनेकांना वेगवेगळ्या तंत्रज्ञानातील फरक दिसला नाही. अनेकांसाठी, मोंगोडीबी बनले आहे समानार्थी NoSQL.

आणि विकासकांनी त्यावर जोरदार हल्ला चढवला. कोणत्याही समस्येचे निराकरण करण्यासाठी जादुई रीतीने मोजमाप करणाऱ्या स्कीमलेस डेटाबेसची कल्पना खूपच मोहक होती. 2014 च्या आसपास, असे दिसते की सर्वत्र एक वर्षापूर्वी मायएसक्यूएल, पोस्टग्रेस किंवा एसक्यूएल सर्व्हर सारखा रिलेशनल डेटाबेस वापरला होता, ज्याने मोंगोडीबी डेटाबेस तैनात करण्यास सुरुवात केली. का असे विचारले असता, तुम्हाला "हे वेबचे स्केल आहे" ते अधिक विचारशील असे उत्तर मिळू शकते "माझा डेटा अतिशय शिथिलपणे संरचित आहे आणि स्कीमाशिवाय डेटाबेसमध्ये बसतो."

हे लक्षात ठेवणे महत्त्वाचे आहे की मोंगोडीबी, आणि सर्वसाधारणपणे दस्तऐवज डेटाबेस, पारंपारिक रिलेशनल डेटाबेससह अनेक समस्यांचे निराकरण करतात:

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

सर्व धोके तुमच्यावर आहेत

मोंगोडीबीचे संभाव्य फायदे प्रचंड होते, विशेषत: विशिष्ट वर्गांच्या समस्यांसाठी. तुम्ही संदर्भ न समजता आणि अनुभवाशिवाय वरील यादी वाचल्यास, मोंगोडीबी खरोखरच क्रांतिकारी डीबीएमएस आहे असा तुमचा समज होऊ शकतो. एकमात्र समस्या अशी होती की वर सूचीबद्ध केलेले फायदे अनेक सावधांसह आले होते, त्यापैकी काही खाली सूचीबद्ध आहेत.

खरे सांगायचे तर, 10gen/MongoDB Inc वर कोणीही नाही. खालील सत्य नाही असे म्हणणार नाही, या फक्त तडजोडी आहेत.

• व्यवहार गमावले: व्यवहार हे अनेक रिलेशनल डेटाबेसचे मुख्य वैशिष्ट्य आहे (सर्वच नाही, परंतु बहुतेक). व्यवहाराचा अर्थ असा आहे की तुम्ही अनेक ऑपरेशन्स परमाणु पद्धतीने करू शकता आणि डेटा सुसंगत राहील याची खात्री करू शकता. अर्थात, NoSQL डेटाबेससह, व्यवहारक्षमता एकाच दस्तऐवजात असू शकते किंवा व्यवहारातील शब्दार्थ प्राप्त करण्यासाठी तुम्ही दोन-फेज कमिट वापरू शकता. परंतु तुम्हाला ही कार्यक्षमता स्वतःच अंमलात आणावी लागेल... जे एक कठीण आणि वेळ घेणारे काम असू शकते. डेटाबेसमधील डेटा अवैध अवस्थेत संपलेला दिसत नाही तोपर्यंत आपल्याला समस्या आहे हे बर्‍याचदा लक्षात येत नाही कारण ऑपरेशन्सच्या अणुत्वाची हमी दिली जाऊ शकत नाही. टीप: बर्‍याच लोकांनी मला सांगितले की MongoDB 4.0 ने गेल्या वर्षी व्यवहार सादर केले, परंतु काही मर्यादांसह. लेखातील टेकअवे सारखेच आहे: तंत्रज्ञान आपल्या गरजा किती चांगल्या प्रकारे पूर्ण करते याचे मूल्यांकन करा.
• रिलेशनल अखंडतेचे नुकसान (विदेशी की): तुमच्या डेटामध्ये रिलेशनशिप असल्यास, तुम्हाला ते अॅप्लिकेशनमध्ये लागू करावे लागतील. या नातेसंबंधांचा आदर करणारा डेटाबेस असल्‍याने ॲप्लिकेशनचे बरेच काम बंद पडेल आणि त्यामुळे तुमचे प्रोग्रामर.
• डेटा संरचना लागू करण्याची क्षमता नसणे: कठोर स्कीमा कधीकधी एक मोठी समस्या असू शकतात, परंतु ते सुज्ञपणे वापरल्यास चांगल्या डेटा स्ट्रक्चरिंगसाठी एक शक्तिशाली यंत्रणा देखील आहेत. MongoDB सारखे दस्तऐवज डेटाबेस अविश्वसनीय स्कीमा लवचिकता प्रदान करतात, परंतु ही लवचिकता डेटा स्वच्छ ठेवण्याची जबाबदारी काढून टाकते. तुम्ही त्यांची काळजी न घेतल्यास, तुमच्या अपेक्षेनुसार फॉर्ममध्ये संग्रहित नसलेल्या डेटाच्या खात्यासाठी तुम्ही तुमच्या ऍप्लिकेशनमध्ये बरेच कोड लिहू शकाल. जसे आम्ही आमच्या कंपनी सिंपल थ्रेडमध्ये अनेकदा म्हणतो... अनुप्रयोग एखाद्या दिवशी पुन्हा लिहिला जाईल, परंतु डेटा कायमचा जिवंत राहील. टीप: मोंगोडीबी स्कीमा तपासणीस समर्थन देते: ते उपयुक्त आहे, परंतु रिलेशनल डेटाबेस प्रमाणेच हमी प्रदान करत नाही. सर्वप्रथम, स्कीमा चेक जोडणे किंवा बदलणे संग्रहातील विद्यमान डेटावर परिणाम करत नाही. तुम्ही नवीन स्कीमानुसार डेटा अपडेट करत आहात याची खात्री करणे तुमच्यावर अवलंबून आहे. तुमच्या गरजांसाठी हे पुरेसे आहे की नाही ते तुम्हीच ठरवा.
• मूळ क्वेरी भाषा / टूल इकोसिस्टमचे नुकसान: SQL चे आगमन ही एक परिपूर्ण क्रांती होती आणि तेव्हापासून काहीही बदलले नाही. ही एक आश्चर्यकारकपणे शक्तिशाली भाषा आहे, परंतु खूप जटिल देखील आहे. जेएसओएन तुकड्यांचा समावेश असलेल्या नवीन भाषेत डेटाबेस क्वेरी तयार करण्याची आवश्यकता SQL सोबत काम करण्याचा अनुभव असलेल्या लोकांसाठी एक मोठी पायरी मानली जाते. आयडीईपासून रिपोर्टिंग टूल्सपर्यंत एसक्यूएल डेटाबेसशी संवाद साधणाऱ्या टूल्सचे संपूर्ण विश्व आहे. SQL ला सपोर्ट न करणार्‍या डेटाबेसमध्ये जाणे म्हणजे तुम्ही यापैकी बरीच साधने वापरू शकत नाही किंवा त्यांचा वापर करण्यासाठी तुम्हाला डेटा SQL मध्ये अनुवादित करावा लागेल, जे तुम्हाला वाटते त्यापेक्षा जास्त कठीण असू शकते.

मोंगोडीबीकडे वळलेल्या अनेक विकासकांना खरोखरच ट्रेड-ऑफ समजले नाही आणि ते त्यांचे प्राथमिक डेटा स्टोअर म्हणून स्थापित करण्यात बरेचदा डोके वर काढले. यानंतर परत येणे अनेकदा आश्चर्यकारकपणे कठीण होते.

वेगळे काय करता आले असते?

सगळ्यांनीच आधी उडी मारली आणि तळाशी आदळला नाही. परंतु बर्‍याच प्रकल्पांनी मोंगोडीबी अशा ठिकाणी स्थापित केले आहे जिथे ते बसत नाही - आणि त्यांना पुढील अनेक वर्षे त्यासह जगावे लागेल. जर या संस्थांनी थोडा वेळ घालवला असता आणि त्यांच्या तंत्रज्ञानाच्या निवडींवर पद्धतशीरपणे विचार केला असता, तर अनेकांनी वेगवेगळ्या निवडी केल्या असत्या.

योग्य तंत्रज्ञान कसे निवडावे? तंत्रज्ञानाच्या मूल्यांकनासाठी पद्धतशीर फ्रेमवर्क तयार करण्याचे अनेक प्रयत्न झाले आहेत, जसे की "सॉफ्टवेअर संस्थांमध्ये तंत्रज्ञानाचा परिचय करून देण्यासाठी फ्रेमवर्क" и "सॉफ्टवेअर तंत्रज्ञानाचे मूल्यांकन करण्यासाठी फ्रेमवर्क", परंतु मला असे वाटते की ही अनावश्यक गुंतागुंत आहे.

फक्त दोन मूलभूत प्रश्न विचारून अनेक तंत्रज्ञानाचे बुद्धिमानपणे मूल्यांकन केले जाऊ शकते. समस्या अशी आहे की जे लोक त्यांना जबाबदारीने उत्तर देऊ शकतील, उत्तरे शोधण्यासाठी वेळ काढतील आणि पक्षपात न करता.

जर तुम्हाला कोणतीही समस्या येत नसेल, तर तुम्हाला नवीन साधनाची गरज नाही. डॉट.

प्रश्न 1: मी कोणत्या समस्या सोडवण्याचा प्रयत्न करीत आहे?

जर तुम्हाला कोणतीही समस्या येत नसेल, तर तुम्हाला नवीन साधनाची गरज नाही. डॉट. उपाय शोधण्याची आणि नंतर समस्या शोधण्याची गरज नाही. नवीन तंत्रज्ञान तुमच्या विद्यमान तंत्रज्ञानापेक्षा लक्षणीयरीत्या चांगल्या प्रकारे सोडवणारी समस्या तुम्हाला आली नसेल तर, येथे चर्चा करण्यासारखे काहीही नाही. जर तुम्ही हे तंत्रज्ञान वापरण्याचा विचार करत असाल कारण तुम्ही इतरांना ते वापरताना पाहिले असेल, तर त्यांना कोणत्या समस्यांना तोंड द्यावे लागते याचा विचार करा आणि तुम्हाला त्या समस्या आहेत का ते विचारा. एखादे तंत्रज्ञान स्वीकारणे सोपे आहे कारण इतर ते वापरत आहेत, आव्हान आहे की तुम्हाला समान समस्यांचा सामना करावा लागतो की नाही हे समजून घेणे.

प्रश्न 2: मी काय गमावत आहे?

हा निश्चितपणे एक अधिक कठीण प्रश्न आहे कारण तुम्हाला जुन्या आणि नवीन तंत्रज्ञानाची चांगली माहिती असणे आवश्यक आहे. काहीवेळा जोपर्यंत तुम्ही त्यासोबत काहीतरी तयार करत नाही किंवा त्या अनुभवासह कोणीतरी येत नाही तोपर्यंत तुम्हाला नवीन समजू शकत नाही.

जर तुमच्याकडे दोन्ही नसेल, तर या इन्स्ट्रुमेंटचे मूल्य निश्चित करण्यासाठी किमान संभाव्य गुंतवणुकीचा विचार करणे अर्थपूर्ण आहे. आणि एकदा गुंतवणुक केल्यावर निर्णय मागे घेणे किती कठीण जाईल?

लोक नेहमीच सर्व काही नष्ट करतात

आपण शक्य तितक्या निःपक्षपातीपणे या प्रश्नांची उत्तरे देण्याचा प्रयत्न करत असताना, एक गोष्ट लक्षात ठेवा: आपल्याला मानवी स्वभावाशी लढावे लागेल. तंत्रज्ञानाचे प्रभावीपणे मूल्यांकन करण्यासाठी अनेक संज्ञानात्मक पूर्वाग्रहांवर मात करणे आवश्यक आहे. येथे फक्त काही आहेत:

• बहुमतात सामील होण्याचा परिणाम - प्रत्येकाला त्याच्याबद्दल माहिती आहे, परंतु तरीही त्याच्याशी लढणे कठीण आहे. फक्त तंत्रज्ञान तुमच्या वास्तविक गरजांशी जुळत असल्याची खात्री करा.
• नवीनता प्रभाव — अनेक डेव्हलपर दीर्घकाळ काम केलेल्या तंत्रज्ञानाला कमी लेखतात आणि नवीन तंत्रज्ञानाच्या फायद्यांचा अतिरेक करतात. हे केवळ प्रोग्रामरच नाही, प्रत्येकजण या संज्ञानात्मक पूर्वाग्रहास बळी पडतो.
• सकारात्मक वैशिष्ट्यांचा प्रभाव - तिथे काय आहे ते पाहण्याकडे आपला कल असतो आणि जे गहाळ आहे त्याकडे दुर्लक्ष होते. नॉव्हेल्टी इफेक्टसह एकत्रित केल्यावर यामुळे अराजकता निर्माण होऊ शकते, कारण तुम्ही केवळ नवीन तंत्रज्ञानाला जास्त महत्त्व देत नाही तर त्यातील कमतरतांकडेही दुर्लक्ष करता..

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

सारांश

जेव्हा जेव्हा एखादी नवीनता दिसून येते तेव्हा दोन प्रश्नांची उत्तरे अत्यंत काळजीपूर्वक दिली पाहिजेत:

• हे साधन वास्तविक समस्या सोडवते का?
• आम्हाला ट्रेड-ऑफ चांगले समजतात का?

तुम्ही या दोन प्रश्नांची आत्मविश्वासाने उत्तरे देऊ शकत नसल्यास, काही पावले मागे जा आणि विचार करा.

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

अस्वीकरण

मला हे स्पष्ट करायचे आहे की माझे मोंगोडीबीशी प्रेम किंवा द्वेषाचे संबंध नाहीत. आम्हाला अशा प्रकारच्या समस्या आल्या नाहीत ज्या सोडवण्यासाठी मोंगोडीबी सर्वात योग्य आहे. मला माहित आहे की 10gen/MongoDB Inc. असुरक्षित डीफॉल्ट सेट करणे आणि सर्वत्र (विशेषत: हॅकॅथॉनमध्ये) मोंगोडीबीचा प्रचार करणे, कोणत्याही डेटासह कार्य करण्यासाठी एक सार्वत्रिक उपाय म्हणून सुरुवातीला खूप धाडसी होते. बहुधा हा एक वाईट निर्णय होता. परंतु हे येथे वर्णन केलेल्या दृष्टिकोनाची पुष्टी करते: तंत्रज्ञानाच्या वरवरच्या मूल्यांकनासह देखील या समस्या खूप लवकर शोधल्या जाऊ शकतात.

स्त्रोत: www.habr.com