दस्तावेज़ डेटाबेस बनाम संबंधपरक डेटाबेस: कैसे चुनें?


16

मैं एक SQL लड़का हूँ, लेकिन मुझे पता है कि केवल SQL डेटाबेस नहीं है - दस्तावेज़-डेटाबेस ज्यादातर। अधिकांश तकनीकों के साथ प्रत्येक तकनीक के लिए समर्थक और विपक्ष होते हैं।

मैंने कुछ लेख पढ़े हैं, लेकिन वे बहुत सैद्धांतिक थे। जो मैं चाहूंगा वह दो वास्तविक मामले हैं:

  1. जब रिलेशनल से डॉक्यूमेंट-डेटाबेस में एक सुधार हुआ
  2. जब दस्तावेज़ से स्विच करने के लिए संबंधपरक डेटाबेस में सुधार हुआ

किसी भी चीज में सुधार होना जो बेहतर कार्यक्रम बनाता है - कम विकास का समय, मापनीयता, प्रदर्शन, कुछ भी जो प्रोग्रामिंग से संबंधित है। 2. के लिए एक चेतावनी है: "संबंधपरक डेटाबेस में वापस गिरने जैसी कहानियां क्योंकि हर कोई जानता है कि एसक्यूएल" अच्छा नहीं है


8
गलत दृष्टिकोण। यह "प्रदर्शन" या "मापनीयता" के बारे में नहीं है। यह उस मॉडल के बारे में है जिस समस्या को आप हल करने की कोशिश कर रहे हैं। आप इस विचार के लिए अनुमति देने के लिए अपने प्रश्न को अपडेट करना चाह सकते हैं कि शायद संबंधपरक डेटाबेस कई प्रकार की समस्याओं के लिए एक अच्छा फिट नहीं है।
S.Lott

2
@ S.Lott, पसंद अक्सर प्रदर्शन का एक बहुत है। विचार करें कि किसी भी संबंधपरक डीबी का उपयोग एक साधारण दस्तावेज डीबी के रूप में किया जा सकता है - केवल प्रदर्शन एक विशिष्ट विशेषता होगी।
edA-qa mort-ora-y

मैंने अपना प्रश्न फिर से तैयार कर लिया है ताकि यह किसी भी तरह से लोड न हो।
जोहान बर्ट जूल

2
@ eda-qa mort-ora-y: "किसी भी संबंधपरक DB को एक साधारण दस्तावेज़ DB के रूप में इस्तेमाल किया जा सकता है"। यह गलत होना चाहिए या लोगों ने एक विकल्प का आविष्कार नहीं किया होगा। "केवल प्रदर्शन एक विशिष्ट विशेषता होगी"। केवल तभी सच है जब आप मान लेते हैं कि संबंधपरक मॉडल सब कुछ समान रूप से अच्छी तरह से करता है। अगर यह सब कुछ करता, तो कोई विकल्प नहीं होता। फिर भी। हमारे पास विकल्प हैं। कई समस्याएं हैं (जैसे पदानुक्रम) जो संबंधपरक मॉडल को पूरी तरह से ठीक नहीं करते हैं , और चतुर चाल की आवश्यकता होती है। या एक वैकल्पिक डेटा मॉडल।
एस.लॉट

"कुछ लेख पढ़ें"? कृपया कुछ लिंक या शीर्षक या संदर्भ या उद्धरण प्रदान करें। हम नहीं जानते कि आपके लिए "बहुत सैद्धांतिक" का क्या अर्थ है।
सल।

जवाबों:


15

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

वितरित बहु-मास्टर सेटअप में पारंपरिक संबंध डेटाबेस बहुत अच्छा नहीं है। यही कारण है कि NoSQL हाल ही में इतना लोकप्रिय रहा है। इसलिए यदि आपको उच्च उपलब्धता की आवश्यकता है, तो आप रयाक, कैसेंड्रा, HBase, S3 या BigTable जैसे NoSQL डेटाबेस का चयन कर सकते हैं।

अमेज़न के डायनामो के बारे में एक अच्छा ब्लॉग पोस्ट है जो वितरित SQL सर्वर के लिए एक अच्छा परिचय है।

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

हालाँकि, अधिकांश NoSQL डेटाबेस पारंपरिक RDBMS डेटाबेस के समान लचीले नहीं हैं, इसलिए यह पारंपरिक RDBMS डेटाबेस का उपयोग करने के लिए एक अच्छा विकल्प है जब तक कि यह आपकी समस्याओं को हल नहीं कर सकता।


+1, सहमत होने पर, यदि आपके पास नहीं है, तो भुगतान करने के लिए लचीलापन एक बड़ी कीमत है।
maple_shaft

12

मेरे पास डेटाबेस को निर्धारित करने के लिए एक सरल तरीका है जो डेटा को सबसे अच्छी तरह से फिट करता है।

मैं बस अपने आप से पूछता हूं: मान लें कि मेरे पास कोई डेटाबेस नहीं है, तो क्या मैं दस्तावेज़ के रूप में सबसे अधिक और महत्वपूर्ण डेटा को बचाऊंगा या क्या मैं उन्हें एक स्प्रेडशीट में संग्रहीत करूंगा।

जब जवाब "स्प्रेडशीट" होता है, तो यह एक स्पष्ट संकेत है कि एक संबंधपरक मॉडल और एक पारंपरिक आरडीबीएमएस सबसे अधिक बार कार्यों के लिए उपयुक्त है। यदि डेटा वास्तव में सरल हैं, जैसे केवल कुंजी मूल्य जोड़े या साधारण टेबल और संदर्भात्मक अखंडता एक विषय नहीं है, तो एक NoSQL डेटाबेस संभवतः कार्य के लिए सबसे उपयुक्त है और प्रदर्शन को काफी बढ़ा सकता है!

इसके अलावा, जब आप एक समान संरचना नहीं पा सकते हैं, तो एक NoSQL डेटाबेस कार्य के लिए सबसे उपयुक्त है।

जब डेटा अधिक दस्तावेज़-जैसे होते हैं, जैसे स्पष्ट संबंधों के बिना पदानुक्रमिक रूप से संरचित पाठ डेटा, तो तुरंत XML- डेटाबेस के बारे में सोचते हैं, जो आसानी से आपको पदानुक्रमित संरचित दस्तावेज़ों को संग्रहीत करने देता है। कभी-कभी दस्तावेज़-प्रबंधन सॉफ़्टवेयर का उपयोग करना सबसे अच्छा होता है, हालाँकि।

इसलिए, आपके दोनों प्रश्नों का ठोस और सरल उत्तर देने के लिए: यह डेटा पर निर्भर करता है।

जब रिलेशनल से डॉक्यूमेंट-डेटाबेस में एक सुधार हुआ

जब आपको पदानुक्रमिक रूप से संरचित पाठ डेटा को जारी रखने की आवश्यकता होती है, तो एक Xml- डेटाबेस में स्थिरता और शायद स्केलेबिलिटी के संदर्भ में एक बड़ा सुधार हो सकता है।

जब दस्तावेज़ से स्विच करने के लिए संबंधपरक डेटाबेस में सुधार हुआ

ठीक है, उदाहरण के लिए, जब डेटा स्पष्ट संबंधों के साथ ज्यादातर टेबल जैसा होता है और आपको अखंडता की गारंटी देने की आवश्यकता होती है।


2
स्प्रेडशीट बनाम दस्तावेज़ सादृश्य के लिए +1 - बहुत बड़ी मदद - धन्यवाद।
HDave

10

हमें रिलेशनल मॉडल को छोड़ना पड़ा क्योंकि हमें जो डेटा मिल रहा था उसमें कोई सरल, स्पष्ट, स्थिर, स्थिर स्कीमा नहीं था।

उपयोगकर्ता - और उपयोगकर्ता कहानियां - एक स्थिर, स्थिर स्कीमा नहीं थी।

हमने एक स्थिर, स्थिर, RDBMS स्कीमा लगाने की कोशिश की, लेकिन यह एक गलती थी।

प्रत्येक तृतीय पक्ष डेटा वितरण (ग्राहकों से और विक्रेताओं से) समान था, लेकिन समान नहीं था। हमने इसे एक निश्चित रिलेशनल स्कीमा में मैप करने की कोशिश की, लेकिन परिवर्तनशीलता बहुत बढ़िया थी। हमें या तो हर फ़ाइल के साथ फ़ील्ड जोड़ना होगा (प्रत्येक सप्ताह कई) या हमें स्थिर, स्थिर संबंधपरक स्कीमा से हटना होगा।

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

डेटा तत्वों का बीमार परिभाषित संग्रह वह है जो उपयोगकर्ताओं को वास्तव में उनके उपयोग के मामलों के लिए आवश्यक था।

रिलेशनल मॉडल के स्थिर, स्थिर स्कीमा हमारे उपयोग के मामलों में फिट नहीं थे।


मैंने देखा है कि अन्य परियोजनाएं आवश्यकताओं को पूरा करने में विफल रही हैं क्योंकि आपने जिन आवश्यकताओं का वर्णन किया है। यह वही है जो दस्तावेज़ डेटाबेस के लिए थे।
maple_shaft
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.