हमें MongoDB का उपयोग कब करना चाहिए?

Question

MongoDB एक NoSQL डेटाबेस है जिसे मैंने उपयोग करना काफी आसान पाया है। हाल ही में मुझे एक सरल एप्लिकेशन विकसित करना पड़ा, जिसमें HTTP अनुरोधों का उपयोग करके कुछ डेटा एकत्र करने और डेटा को संसाधित करने के बाद कुछ परिणाम संग्रहीत करने की आवश्यकता थी, और मैंने MongbDB का उपयोग करने का प्रयास किया।

इस अनुभव से मुझे पारंपरिक संबंधपरक डेटाबेस की तुलना में इसका उपयोग करने में बहुत अच्छा लगा और जब से मैं एक डेवलपर हूं, और डीबीए नहीं, मेरा काम बहुत सरल हो गया।

फिर भी, कभी-कभी मुझे यह महसूस होता है कि जब मैं SQL सर्वर या MySQL जैसे पारंपरिक रिलेशनल डेटाबेस के बजाय MongoDB का उपयोग करना चाहिए।

उस स्थिति में, जब हम संबंधपरक डेटाबेस के बजाय MongoDB का उपयोग कर सकते हैं? वहाँ कुछ trully है बड़ा MongoDB के बारे में चेतावनी है कि यह कुछ स्थितियों के लिए अनुचित है?

Comments

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

— मेसन व्हीलर

संभावित डुप्लिकेट डुप्लीकेट डुप्लीकेट का उपयोग किसी संबंधपरक DBMS पर कब होगा?

— gnat

@ मेसनव्हीलर सहमत। इस संदर्भ में, "सरल और अच्छा उपयोग करना" का अर्थ है "बग को लिखने और डेटा को भ्रष्ट करने के लिए उपयोग करना आसान";)

— एंड्रेस एफ।

Answer 1

मूल रूप से:

• यदि आप दस्तावेजों के एक समूह के रूप में अपने डेटा का प्रतिनिधित्व कर सकते हैं, तो MongoDB एक अच्छा विकल्प हो सकता है।

• यदि आप अपने डेटा को परस्पर तालिकाओं के एक समूह के रूप में कल्पना करेंगे, तो MongoDB एक अच्छा विकल्प नहीं हो सकता है।

यहां दो उदाहरण दिए गए हैं, जो मुझे स्पष्ट प्रतीत होते हैं:

• कुछ साल पहले, मैंने एक ब्लॉग इंजन बनाया। इसका उद्देश्य ब्लॉग लेखों की मेजबानी करना है, और हर लेख के लिए, विभिन्न संस्करणों, कुछ मेटाडेटा, विज़िट के आँकड़ों आदि को संग्रहीत करना है।

  यह तालिकाओं के एक समूह के रूप में संग्रहीत किया जा सकता है, लेकिन जब एक मॉडल बनाने की कोशिश की जाती है, तो यह बहुत तेजी से एक दर्जन तालिकाओं तक बढ़ता है, यदि अधिक नहीं। कुछ एसक्यूएल क्वेरी बहुत से joinएस के साथ बदसूरत हो सकती हैं , और ... ठीक है, आपको तस्वीर मिलती है।

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

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

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

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

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

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

  यदि आप एक रिलेशनल डेटाबेस का उपयोग कर रहे थे, तो अब आपको कितनी तालिकाओं की आवश्यकता होगी? सही, तीन। यह मॉडल के लिए सीधा होगा, और उपयोग करने के लिए भी सीधा होगा।

Comments

इस जवाब को अब अपडेट करने की आवश्यकता है क्योंकि ACID को लागू करने के लिए 4.0 संस्करण के दावे के बाद से MongoDB, हालांकि मल्टीट्रांसपोर्ट्स के लिए पायथन और जावा एपीआई mongodb.com/blog/post/…

— कारमाइन

@Carmine: अद्यतन उत्तर देने के लिए मेरे पास पर्याप्त ज्ञान नहीं है। क्या आप कृपया (1) नीचे दिए गए उत्तर के रूप में अपना पोस्ट कर सकते हैं और (2) आप एक बार यहाँ एक टिप्पणी जोड़ दें, इसलिए मैं अपने उत्तर को आपके लिंक के साथ एक अस्वीकरण जोड़ता हूँ, यह कहते हुए कि यह अब MongoDB 4 से शुरू होने वाला वैध नहीं है?

— आर्सेनी मूरज़ेंको

Answer 2

प्रत्येक तकनीक के अपने फायदे हैं।

संबंधपरक डेटाबेस के लाभ यह है कि RDBMS आपके लिए कुछ चीजें करता है, जैसे:

• संदर्भात्मक अखंडता को लागू करना (यदि चालान का अस्तित्व नहीं है तो चालान विवरण की प्रविष्टि की अनुमति नहीं है)
• अतिरेक से बचें: चीजें केवल एक बार जमा होती हैं।
• जटिल प्रश्नों को एक घोषणात्मक भाषा (एसक्यूएल) के साथ किया जा सकता है जो परिपक्व, समय-सिद्ध और व्यापक रूप से फैला हुआ है।

यह सब इस तथ्य से उबलता है कि आपको कम कोड लिखना होगा क्योंकि RDBMS आपके लिए चीजों को लागू करता है।

इसके अतिरिक्त, डेटा इंडिपेंडेंस: अक्सर यदि आप मानक SQL संरचनाओं का उपयोग करते हैं और कोई विक्रेता-विशिष्ट नहीं हैं, तो आप अपने डेटा को एक RDBMS से दूसरे में न्यूनतम परेशानी के साथ माइग्रेट कर सकते हैं, जबकि NOSQL डेटाबेस बिल्कुल भी मानकीकृत नहीं हैं।

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

Comments

MongoDB में लेनदेन का अभाव एक बहुत बड़ा नुकसान है। हर समय नस्ल-स्थितियों के बारे में चिंता करने से गधे में ऐसा दर्द होता है।

— कोडइंचौस जूल

नोट: MongoDB अब ACID लेनदेन का समर्थन करता है।

— मिलन वेलेबिट

Answer 3

आपके विशेष मामले के लिए, MongoDB एक अच्छा विकल्प लगता है, लेकिन इसमें बहुत सारे परिदृश्य (शायद उनमें से अधिकांश) हैं जहां यह सबसे अच्छा विकल्प नहीं होगा।

MongoDB उन परिदृश्यों में अधिक अनुकूल है जो बहुत सारे डेटा को पढ़ने / लिखने के लिए कहते हैं , बिना लेन-देन सुरक्षा पर अधिक जोर दिए (यदि कुछ डेटा कभी-कभी सर्वर क्रैश में खो जाता है, तो यह कोई बड़ी बात नहीं है), बड़े पैमाने पर उम्मीद करें, और डॉन ' टी वास्तव में एक स्थिर स्कीमा है।

MongoDB उन परिदृश्यों के लिए अनुकूल नहीं है जिनकी आवश्यकता है:

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

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

यह सब आपके द्वारा बनाए जा रहे एप्लिकेशन की जरूरतों पर निर्भर करता है। क्या यह गति और उपलब्धता, या सुरक्षा, विश्वसनीयता और लचीलापन है। आपको यह जानना होगा कि आपके डेटा में (और आपके डेटा के कनेक्शन में) अधिक मूल्य कहां है। यदि आप अभी तक नहीं जानते हैं, तो संभवतः यह सबसे अच्छा है यदि आप ऐसा कुछ चुनते हैं जो आपको भविष्य में एक कोने में पेंट नहीं करेगा, और आपको सुविधाओं को जोड़ने और उन कार्यों को निष्पादित करने की अनुमति देगा जो आपके एप्लिकेशन की ज़रूरत हैं।

Answer 4

MongoDB महान है जब आप अपने डेटा को सूचना के स्वतंत्र "पैकेज" के रूप में दर्शा सकते हैं। आपके पास Google मैप्स ज़िप कोड हैं, ज़िप कोड में एम्बेडेड कंपनियां हैं और कंपनियों के अंदर कर्मचारी हैं। सभी ज़िप कोड एक दूसरे से स्वतंत्र हैं और आप पूरी जानकारी सरल, सुंदर और तेज़ तरीके से प्राप्त कर सकते हैं। यह एक nonSQL समाधान के लिए एक अच्छा परिदृश्य है।

एक बार कहा गया था कि, मैं वर्तमान प्रवृत्ति से पूरी तरह असहमत हूं, जिसका अर्थ है कि मैं मानता हूं कि MongoDB एक प्रकार का पोस्ट और RDBMS से बेहतर समाधान है और डिफ़ॉल्ट रूप से noSQL आपका समाधान होना चाहिए। वह सब बेतुका है। MongoDB एक आला डेटाबेस है और 90% परियोजनाएं संबंधपरक हैं और RDBMS विकल्प की आवश्यकता है क्योंकि आप अपनी रिपोर्ट उत्पन्न करने के लिए SQL जैसे शक्तिशाली क्वेरी समाधान चाहते हैं और डेटा को फैलाने के लिए देखते हैं: "जॉइन" एक समर्थक हैं, एक con नहीं। इसके अलावा, आधुनिक आरडीबीएमएस बीएसओएन संग्रह और भू-स्थानिक एकीकरण का समर्थन करते हैं, इसलिए शायद noSQL के लिए आला अब और भी संकीर्ण है।

Answer 5

MongoDB वेब पेज के दिए गए उदाहरण को बनाने के लिए आवश्यक संपूर्ण संरचित डेटा को संग्रहीत करने के लिए उपयोगी है। आप किसी दिए गए पृष्ठ के लिए डेटा पुनः प्राप्त कर सकते हैं, इसे अपने क्लाइंट एप्लिकेशन को पास कर सकते हैं जो फिर इसे प्रस्तुत कर सकता है।

ऐसे संदर्भ में, MongoDB बहुत तेज और विश्वसनीय है। लेकिन कभी नहीं भूलना चाहिए कि आपके डेटाबेस में संबंधपरक जानकारी नहीं है। जिसका अर्थ है कि यदि आप अपने वेबपेज की संरचना में कुछ परिवर्तन करते हैं, तो आप अपने पहले से संग्रहीत पृष्ठों में छेद भरने में असमर्थ हो सकते हैं क्योंकि आपके पास ऐसा करने के लिए आवश्यक डेटा नहीं है। इस पर अधिक यहाँ: http://www.sarahmei.com/blog/2013/11/11/why-you-should-never-use-mongodb/