MongoDB सह प्रारंभ करण्यापूर्वी 14 गोष्टी मला माहित असत्या

लेखाचा अनुवाद अभ्यासक्रम सुरू होण्याच्या आदल्या दिवशी तयार केला होता "नॉन-रिलेशनल डेटाबेस".

हायलाइट्सः

• स्कीमा विकसित करणे अत्यंत महत्वाचे आहे जरी ते MongoDB मध्ये पर्यायी आहे.
• त्याचप्रमाणे, अनुक्रमणिका तुमच्या स्कीमा आणि प्रवेश पद्धतींशी जुळली पाहिजे.
• मोठ्या वस्तू आणि मोठ्या अॅरे वापरणे टाळा.
• मोंगोडीबी सेटिंग्जसह सावधगिरी बाळगा, विशेषत: जेव्हा सुरक्षितता आणि विश्वासार्हतेचा प्रश्न येतो.
• मोंगोडीबीकडे क्वेरी ऑप्टिमायझर नाही, त्यामुळे क्वेरी ऑपरेशन्स करताना तुम्ही सावधगिरी बाळगली पाहिजे.

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

प्रमाणीकरणाशिवाय मोंगोडीबी सर्व्हर तयार करणे

दुर्दैवाने, मोंगोडीबी डीफॉल्टनुसार प्रमाणीकरणाशिवाय स्थापित केले आहे. स्थानिक पातळीवर प्रवेश केलेल्या वर्कस्टेशनसाठी, ही पद्धत सामान्य आहे. परंतु मोंगोडीबी ही एक बहु-वापरकर्ता प्रणाली असल्याने ज्याला मोठ्या प्रमाणात मेमरी वापरणे आवडते, आपण ती फक्त विकासासाठी वापरत असलो तरीही, शक्य तितकी RAM असलेल्या सर्व्हरवर ठेवल्यास ते चांगले होईल. डीफॉल्ट पोर्टद्वारे सर्व्हरवर स्थापित करणे समस्याप्रधान असू शकते, विशेषतः जर विनंतीमध्ये कोणताही जावास्क्रिप्ट कोड कार्यान्वित केला जाऊ शकतो (उदाहरणार्थ, $where साठी एक कल्पना म्हणून इंजेक्शन).

अनेक प्रमाणीकरण पद्धती आहेत, परंतु वापरकर्ता आयडी/पासवर्ड सेट करणे सर्वात सोपी आहे. फॅन्सी ऑथेंटिकेशनवर आधारित विचार करताना ही कल्पना वापरा एलडीएपी. जेव्हा सुरक्षेचा विचार केला जातो, तेव्हा मोंगोडीबी सतत अपडेट केले जावे, आणि लॉग नेहमी अनधिकृत प्रवेशासाठी तपासले जावे. उदाहरणार्थ, मला डीफॉल्ट पोर्ट म्हणून वेगळे पोर्ट निवडणे आवडते.

अटॅक पृष्ठभाग मोंगोडीबीशी बांधण्यास विसरू नका

MongoDB सुरक्षा चेकलिस्ट नेटवर्क घुसखोरी आणि डेटा लीक होण्याचा धोका कमी करण्यासाठी चांगल्या टिपा समाविष्ट आहेत. ते बंद करणे आणि विकास सर्व्हरला उच्च स्तरीय सुरक्षिततेची आवश्यकता नाही असे म्हणणे सोपे आहे. तथापि, हे इतके सोपे नाही आणि हे सर्व मोंगोडीबी सर्व्हरवर लागू होते. विशेषतः, वापरण्यासाठी कोणतेही सक्तीचे कारण नसल्यास mapReduce, group किंवा $कुठे, तुम्हाला कॉन्फिगरेशन फाइलमध्ये लिहून JavaScript मध्ये अनियंत्रित कोडचा वापर अक्षम करणे आवश्यक आहे javascriptEnabled:false. डेटा फायली मानक मोंगोडीबीमध्ये कूटबद्ध केल्या जात नसल्यामुळे, मोंगोडीबी यासह चालवणे अर्थपूर्ण आहे समर्पित वापरकर्ता, ज्याला फायलींमध्ये पूर्ण प्रवेश आहे, केवळ त्यात मर्यादित प्रवेश आणि ऑपरेटिंग सिस्टमची स्वतःची फाइल प्रवेश नियंत्रणे वापरण्याची क्षमता.

सर्किट विकसित करताना त्रुटी

MongoDB स्कीमा वापरत नाही. पण याचा अर्थ असा नाही की योजनेची गरज नाही. तुम्हाला कोणत्याही सातत्यपूर्ण नमुन्याशिवाय दस्तऐवज संचयित करायचे असल्यास, ते संचयित करणे जलद आणि सोपे असू शकते, परंतु नंतर ते पुनर्प्राप्त करणे कठीण होऊ शकते. खूप कठीण.

क्लासिक लेख "मोंगोडीबी स्कीमा डिझाइनसाठी अंगठ्याचे 6 नियम" हे वाचण्यासारखे आहे आणि सारखी वैशिष्ट्ये स्कीमा एक्सप्लोरर थर्ड-पार्टी टूल स्टुडिओ 3T मध्ये, सर्किट्सच्या नियमित तपासणीसाठी वापरणे योग्य आहे.

क्रमवारी विसरू नका

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

मोठ्या कागदपत्रांसह संग्रह तयार करा

मोंगोडीबी 16MB पर्यंतचे मोठे दस्तऐवज संग्रहित करण्यात आनंदी आहे, आणि ग्रिडएफएस 16 MB पेक्षा मोठ्या दस्तऐवजांसाठी डिझाइन केलेले. पण फक्त मोठी कागदपत्रे तिथे ठेवता येतात म्हणून, ती तिथे साठवून ठेवणे ही चांगली कल्पना नाही. आपण काही किलोबाइट आकाराचे वैयक्तिक दस्तऐवज संग्रहित केल्यास, त्यांना विस्तृत SQL सारणीतील पंक्तींप्रमाणे हाताळल्यास MongoDB उत्तम कार्य करेल. मोठ्या कागदपत्रांमुळे समस्या उद्भवतील उत्पादकता.

मोठ्या अॅरेसह दस्तऐवज तयार करणे

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

MongoDB ला काहीतरी म्हणतात "फिल फॅक्टर", जे ही समस्या कमी करण्यासाठी दस्तऐवज वाढवण्यासाठी जागा प्रदान करते.
तुम्हाला वाटेल की तुम्ही अॅरे इंडेक्सिंगशिवाय करू शकता. दुर्दैवाने, निर्देशांकांच्या कमतरतेमुळे तुम्हाला इतर समस्या येऊ शकतात. दस्तऐवज सुरवातीपासून शेवटपर्यंत स्कॅन केले जात असल्याने, अॅरेच्या शेवटी घटक शोधण्यात जास्त वेळ लागेल आणि अशा दस्तऐवजाशी संबंधित बहुतेक ऑपरेशन्स मंद.

हे विसरू नका की एकत्रीकरणातील टप्प्यांचा क्रम महत्त्वाचा आहे

क्वेरी ऑप्टिमायझर असलेल्या डेटाबेस सिस्टममध्ये, तुम्ही ज्या क्वेरी लिहिता त्या तुम्हाला काय मिळवायचे आहे, ते कसे मिळवायचे याचे स्पष्टीकरण असते. ही यंत्रणा रेस्टॉरंटमध्ये ऑर्डर देण्याच्या सादृश्याने कार्य करते: सहसा तुम्ही डिश ऑर्डर करता आणि स्वयंपाकाला तपशीलवार सूचना देत नाही.

मोंगोडीबीमध्ये, तुम्ही स्वयंपाकाला सूचना देता. उदाहरणार्थ, आपल्याला डेटा जातो याची खात्री करणे आवश्यक आहे reduce वापरून पाइपलाइन मध्ये शक्य तितक्या लवकर $match и $project, आणि क्रमवारी नंतरच येते reduce, आणि शोध तुम्हाला पाहिजे त्या क्रमाने होतो. क्वेरी ऑप्टिमायझर असणे जे अनावश्यक काम काढून टाकते, पायऱ्या चांगल्या प्रकारे क्रमवारी लावते आणि जॉइन प्रकार निवडतात ते तुमचे नुकसान करू शकतात. MongoDB सह, तुमच्याकडे सोयीच्या किंमतीवर अधिक नियंत्रण आहे.

सारखी साधने स्टुडिओ 3T मध्ये एकत्रीकरण प्रश्नांचे बांधकाम सुलभ करेल MongoDB. एग्रीगेशन एडिटर वैशिष्ट्य तुम्हाला पाइपलाइन स्टेटमेंट्स एका वेळी एका टप्प्यावर लागू करण्याची आणि डीबगिंग सुलभ करण्यासाठी प्रत्येक टप्प्यावर इनपुट आणि आउटपुट डेटाची तपासणी करण्यास अनुमती देते.

जलद रेकॉर्डिंग वापरणे

उच्च गती परंतु कमी विश्वासार्हतेसाठी MongoDB लेखन पर्याय कधीही सेट करू नका. हा मोड "फाइल आणि विसरा" जलद दिसते कारण लिहिण्यापूर्वी कमांड परत केली जाते. डेटा डिस्कवर लिहिण्यापूर्वी सिस्टम क्रॅश झाल्यास, ते गमावले जाईल आणि विसंगत स्थितीत समाप्त होईल. सुदैवाने, 64-बिट मोंगोडीबीने लॉगिंग सक्षम केले आहे.

MMAPv1 आणि WiredTiger स्टोरेज इंजिन हे टाळण्यासाठी लॉगिंग वापरतात, जरी WiredTiger शेवटच्या सुसंगततेपर्यंत पुनर्प्राप्त करू शकते नियंत्रण बिंदू, लॉगिंग अक्षम केले असल्यास.

जर्नलिंग हे सुनिश्चित करते की डेटाबेस पुनर्प्राप्तीनंतर सुसंगत स्थितीत आहे आणि जोपर्यंत तो लॉगवर लिहिला जात नाही तोपर्यंत सर्व डेटा राखून ठेवतो. रेकॉर्डिंगची वारंवारता पॅरामीटर वापरून कॉन्फिगर केली जाते commitIntervalMs.

नोंदींची खात्री करण्यासाठी, कॉन्फिगरेशन फाइलमध्ये लॉगिंग सक्षम केले असल्याची खात्री करा (storage.journal.enabled), आणि रेकॉर्डिंगची वारंवारता आपण गमावू शकत असलेल्या माहितीच्या प्रमाणाशी संबंधित आहे.

अनुक्रमणिकाशिवाय क्रमवारी लावणे

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

योग्य निर्देशांक नसल्यास, मोंगोडीबी त्याशिवाय करेल. मधील सर्व कागदपत्रांच्या एकूण आकारावर 32 MB ची मेमरी मर्यादा आहे क्रमवारी ऑपरेशन्स, आणि जर MongoDB या मर्यादेपर्यंत पोहोचला, तर तो एकतर एरर टाकेल किंवा परत येईल रिक्त रेकॉर्डसेट.

निर्देशांक समर्थनाशिवाय शोधा

शोध क्वेरी SQL मधील JOIN ऑपरेशन प्रमाणे कार्य करतात. सर्वोत्तम कार्य करण्यासाठी, त्यांना परदेशी की म्हणून वापरल्या जाणार्‍या कीच्या मूल्याची अनुक्रमणिका आवश्यक आहे. हे स्पष्ट नाही कारण वापर प्रतिबिंबित होत नाही explain(). असे निर्देशांक लिहीलेल्या निर्देशांकाच्या व्यतिरिक्त आहेत explain(), ज्याचा वापर पाइपलाइन ऑपरेटरद्वारे केला जातो $match и $sort, जेव्हा ते पाइपलाइनच्या सुरूवातीस भेटतात. निर्देशांक आता कोणताही टप्पा कव्हर करू शकतात एकत्रीकरण पाइपलाइन.

मल्टी-अपडेट्स वापरण्याची निवड रद्द करणे

पद्धत db.collection.update() विद्यमान दस्तऐवजाचा काही भाग किंवा संपूर्ण दस्तऐवज बदलण्यासाठी वापरला जातो, संपूर्ण बदलीपर्यंत, तुम्ही निर्दिष्ट केलेल्या पॅरामीटरवर अवलंबून update. इतके स्पष्ट नाही की आपण पर्याय सेट केल्याशिवाय ते संग्रहातील सर्व दस्तऐवजांवर प्रक्रिया करणार नाही multi विनंती निकष पूर्ण करणारे सर्व दस्तऐवज अद्यतनित करण्यासाठी.

हॅश टेबलमधील कीच्या ऑर्डरचे महत्त्व विसरू नका

JSON मध्ये, ऑब्जेक्टमध्ये आकार शून्य किंवा अधिक नाव/मूल्य जोड्यांचा अक्रमित संग्रह असतो, जेथे नाव एक स्ट्रिंग असते आणि मूल्य म्हणजे स्ट्रिंग, संख्या, बुलियन, शून्य, ऑब्जेक्ट किंवा अॅरे.

दुर्दैवाने, BSON शोध करताना ऑर्डरवर खूप जोर देते. मोंगोडीबी मध्ये, अंगभूत ऑब्जेक्ट्समधील कळांचा क्रम वस्तू, म्हणजे { firstname: "Phil", surname: "factor" } - हे सारखे नाही { { surname: "factor", firstname: "Phil" }. म्हणजेच, तुम्हाला तुमच्या कागदपत्रांमध्ये नाव/मूल्य जोड्यांचा क्रम संग्रहित करणे आवश्यक आहे, जर तुम्हाला ते शोधण्याची खात्री हवी असेल.

गोंधळून जाऊ नका "निरर्थक" и "अपरिभाषित"

मूल्य "अपरिभाषित" नुसार, JSON मध्ये कधीही वैध नव्हते अधिकृत मानक JSON (ECMA-404 विभाग 5), जरी ते JavaScript मध्ये वापरले जाते. शिवाय, BSON साठी ते अप्रचलित आहे आणि मध्ये रूपांतरित केले आहे $null, जे नेहमीच चांगले समाधान नसते. वापरणे टाळा "अपरिभाषित" मोंगोडीबी मध्ये.

वापरा $limit() न $sort()

जेव्हा तुम्ही मोंगोडीबीमध्ये विकसित होत असाल तेव्हा बर्‍याचदा, क्वेरी किंवा एकत्रीकरणातून मिळालेल्या निकालाचा नमुना पाहणे उपयुक्त ठरते. या कार्यासाठी आपल्याला आवश्यक असेल $limit(), परंतु तुम्ही आधी वापरल्याशिवाय ते कधीही अंतिम कोडमध्ये नसावे $sort. हे मेकॅनिक आवश्यक आहे कारण अन्यथा आपण निकालाच्या क्रमाची हमी देऊ शकत नाही आणि आपण डेटा विश्वसनीयपणे पाहू शकणार नाही. निकालाच्या शीर्षस्थानी तुम्हाला क्रमवारीनुसार वेगवेगळ्या नोंदी मिळतील. विश्वासार्हतेने कार्य करण्यासाठी, क्वेरी आणि एकत्रीकरण हे निर्धारक असणे आवश्यक आहे, म्हणजेच प्रत्येक वेळी ते कार्यान्वित केले जातात तेव्हा समान परिणाम देतात. कोड ज्यामध्ये आहे $limit(), पण नाही $sort, निर्धारवादी असणार नाही आणि नंतर त्रुटी निर्माण करू शकतात ज्याचा मागोवा घेणे कठीण होईल.

निष्कर्ष

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

आवृत्ती 4.0 मध्ये MongoDB ची ACID व्यवहाराची ओळख हे नाविन्यपूर्ण मार्गाने महत्त्वाच्या सुधारणा सादर करण्याचे उत्तम उदाहरण आहे. बहु-दस्तऐवज आणि मल्टी-स्टेटमेंट व्यवहार आता अणू आहेत. लॉक मिळविण्यासाठी लागणारा वेळ समायोजित करणे आणि अडकलेले व्यवहार समाप्त करणे, तसेच अलगाव पातळी बदलणे देखील शक्य आहे.

पुढे वाचा:

• Google BigQuery मध्ये डेटा कसा लोड करायचा

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