क्या बड़े डेटासेट के लिए NoSQL डेटाबेस का उपयोग अव्यवहारिक है जहाँ आपको सामग्री द्वारा खोज करने की आवश्यकता है?

Question

मैं अब एक सप्ताह के लिए NoSQL डेटाबेस के बारे में सीख रहा हूं।

मैं वास्तव में NoSQL डेटाबेस के फायदे और कई उपयोग के मामलों को समझता हूं जिनके लिए वे महान हैं।

लेकिन अक्सर लोग अपने लेख लिखते हैं जैसे कि NoSQL रिलेशनल डेटाबेस को प्रतिस्थापित कर सकता है । और वह बिंदु है जो मुझे अपना सिर नहीं मिल सकता है:

NoSQL डेटाबेस (अक्सर) कुंजी-मूल्य स्टोर हैं।

बेशक यह सब कुछ एक कुंजी-मूल्य की दुकान में स्टोर करना संभव है (JSON, XML, जो भी हो) में डेटा एन्कोडिंग करके, लेकिन मुझे जो समस्या दिखाई देती है वह यह है कि आपको कुछ मात्रा में डेटा प्राप्त करने की आवश्यकता है जो एक विशिष्ट मानदंड से मेल खाती है, कई में बक्सों का इस्तेमाल करें। NoSQL डेटाबेस में आपके पास केवल एक मानदंड है जिसे आप प्रभावी रूप से खोज सकते हैं - कुंजी। रिलेशनल डेटाबेस को प्रभावी रूप से डेटा पंक्ति में किसी भी मूल्य की खोज करने के लिए अनुकूलित किया जाता है।

इसलिए NoSQL डेटाबेस वास्तव में डेटा को बनाए रखने के लिए एक विकल्प नहीं है जिसे उनकी सामग्री द्वारा खोजे जाने की आवश्यकता है। या मैंने कुछ गलत समझा है?

एक उदाहरण:

आपको एक webshop के लिए उपयोगकर्ता डेटा संग्रहीत करने की आवश्यकता है।

एक संबंधपरक डेटाबेस में आप प्रत्येक उपयोगकर्ता को usersएक आईडी, नाम, उसका देश, आदि के साथ तालिका में एक पंक्ति के रूप में संग्रहीत करते हैं ।

NoSQL डेटाबेस में आप प्रत्येक उपयोगकर्ता को कुंजी के रूप में उसकी आईडी और उसके सभी डेटा (JSON, इत्यादि में एन्कोडेड) के रूप में संग्रहीत करेंगे।

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

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

आप प्रत्येक देश के लिए एक कुंजी बना सकते हैं जो इस देश में रहने वाले प्रत्येक उपयोगकर्ता की कुंजी संग्रहीत करता है, और इस देश के लिए कुंजी में जमा की गई सभी कुंजी प्राप्त करके एक विशिष्ट देश के उपयोगकर्ता प्राप्त करता है। लेकिन मुझे लगता है कि यह तकनीक जटिल डेटासेट को और भी जटिल बना देती है - इसे लागू करना कठिन है और SQL डेटाबेस को क्वेरी करने जितना प्रभावी नहीं है। इसलिए मुझे लगता है कि यह ऐसा तरीका नहीं है जिसका आप उत्पादन में उपयोग करेंगे। या यह है?

मुझे यकीन नहीं है कि अगर मैंने कुछ गलत समझा या इस तरह के उपयोग के मामलों को संभालने के लिए कुछ अवधारणाओं या सर्वोत्तम प्रथाओं की अनदेखी की। हो सकता है कि आप मेरे बयानों को सही कर सकें और मेरे सवालों का जवाब दे सकें।

Comments

यह एक प्रश्न की तुलना में एक शेख़ी की तरह अधिक पढ़ता है। आपको लगता है कि संबंधपरक मूल्य बनाम कुंजी-मूल्य भंडारण के फायदे और नुकसान की अच्छी समझ है। तो वास्तव में सवाल क्या है?

— जैक्सबी

यह बिल्कुल भी शेख़ी नहीं है :) NoSQL डेटाबेस भयानक हैं, लेकिन मुझे लगता है कि रिलेशनल डेटाबेस कुछ लोगों के राज्य के रूप में खराब नहीं हैं। मैं सिर्फ यह पता लगाना चाहता हूं, अगर मेरी थीसिस, कि NoSQL डेटाबेस सबसे अच्छा विकल्प नहीं है, अगर यह 'डेटारो' में खोज करने की बात आती है ... या अगर मुझे विषय ठीक से समझ नहीं आया।

— लियो लिन्हॉर्स्ट

programmers.stackexchange.com/q/54373/17853

— मोनिका के साथ लपट दौड़

लेकिन MongoDB Webscale है ! [चेतावनी: कुछ NSFW भाषा शामिल है]

— जेरी कॉफ़िन

@DevWurm: आप सामान्य रूप से NoSQL के साथ कुंजी-मूल्य की दुकानों को भ्रमित नहीं करते हैं। उदाहरण के लिए googles BigTable को NoSQL डेटाबेस माना जाता है, लेकिन आप अभी भी कई क्षेत्रों पर अनुक्रमित खोज और बना सकते हैं। एक कुंजी-मूल्य स्टोर उपयुक्त है जब आप जानते हैं कि आपको केवल एक क्षेत्र (कुंजी) पर खोज करने की आवश्यकता है।

— जैक्सबी 20

Answer 1

जबकि मैं आपके आधार से सहमत हूं कि NoSQL सभी डेटाबेस संकटों के लिए रामबाण नहीं है, मुझे लगता है कि आप एक महत्वपूर्ण बिंदु को गलत समझते हैं।

NoSQL डेटाबेस में आपके पास केवल एक मानदंड है जिसे आप प्रभावी रूप से खोज सकते हैं - कुंजी।

यह स्पष्ट रूप से सच नहीं है।

उदाहरण के लिए MongoDB सूचकांकों का समर्थन करता है। ( https://docs.mongodb.org/v3.0/core/indexes-introduction/ से )

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

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

जैसा कि couchbase ( http://docs.couchbase.com/admin/admin/Views/views-intro.html से ) करता है

काउचबेस विचार डेटा के अनुक्रमण और क्वेरी को सक्षम करते हैं।

एक दृश्य परिभाषित प्रारूप और संरचना के अनुसार डेटा पर एक सूचकांक बनाता है। दृश्य में विशिष्ट क्षेत्र और Couchbase में वस्तुओं से निकाली गई जानकारी शामिल है।

वास्तव में कुछ भी जो खुद को एक महत्वपूर्ण मूल्य की दुकान के बजाय एक NoSQL डेटाबेस कहता है, को वास्तव में किसी प्रकार की अनुक्रमण योजनाओं का समर्थन करना चाहिए।

वास्तव में, यह अक्सर इन सूचकांक योजनाओं का लचीलापन होता है जो NoSQL को चमकदार बनाता है। मेरी राय में, NoSQL सूचक को परिभाषित करने के लिए इस्तेमाल की जाने वाली भाषा अक्सर SQL की तुलना में अधिक अभिव्यंजक या प्राकृतिक होती है, और चूंकि वे आमतौर पर तालिका के बाहर रहते हैं, इसलिए आपको उनका समर्थन करने के लिए अपनी तालिका स्कीमा बदलने की आवश्यकता नहीं है। (यह कहने के लिए कि आप SQL में समान चीजें नहीं कर सकते, लेकिन मुझे ऐसा लगता है कि इसमें बहुत अधिक घेरा-कूद शामिल है)।

Comments

"... चूंकि वे आमतौर पर टेबल के बाहर रहते हैं, इसलिए आपको उनका समर्थन करने के लिए अपनी तालिका स्कीमा बदलने की आवश्यकता नहीं है।" SQL डेटाबेस में गैर-क्लस्टर किए गए अनुक्रमणिका और noSQL डेटाबेस के लिए अनुक्रमणिका के बीच एक ही स्थिति है, है ना?

— जिरका हनिका

बहुत ठोस जवाब। मुझे लगता है कि NoSQL इस विचार पर कुछ हद तक अनुमानित है कि यदि आप तेजी से जाना चाहते हैं, तो आपको बिना किसी प्राथमिक कुंजी के 90% ++ अनुरोध करना चाहिए, और यदि आप कुछ और करना चाहते हैं, तो आप में हैं टेबल स्कैन और सेकंडरी इंडेक्स की दुनिया, जिसमें हमेशा प्रदर्शन और पैमाने की सीमाएं होती हैं। एक बार जब आप एक इंडेक्स खोज रहे होते हैं, या आपने एक गुच्छा बनाया है, तो आप बस उस क्षेत्र में नहीं हैं जहाँ गति प्राप्त की जा सकती है (कुछ मिलियन पंक्तियों के छोटे डेटासेट को छोड़कर)। यदि आप उस शैली में कोड करते हैं जहां वैकल्पिक लुकअप दुर्लभ हैं, तो आप एक बहुत ही ठोस परिचालन प्रणाली के साथ समाप्त होंगे।

— ब्रायन बुल्कोव्स्की

Answer 2

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

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

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

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

अंतर? SQL इंजन में निर्मित तालिका को अनुक्रमित करने की अवधारणा थी। इसका मतलब है कि आपको कम काम करना था (आपको बस इतना करना था कि तालिका में एक सूचकांक जोड़ें)। हालाँकि, इसका यह भी अर्थ है कि आपका नियंत्रण कम था। अधिकांश मामलों के लिए, नियंत्रण की हानि स्वीकार्य है, बदले में SQL इंजन आपके लिए काम कर रहा है। हालाँकि, बड़े डेटासेट में, आप विशिष्ट SQL ACID मॉडल की तुलना में एक अलग संगतता मॉडल चाहते हैं। आप BASE मॉडल का उपयोग करना चाह सकते हैं जो अंतिम स्थिरता का समर्थन करता है। यह SQL में बहुत मुश्किल हो सकता है, क्योंकि SQL इंजन आपके लिए काम कर रहा है इसलिए इसे SQL इंजन के नियमों द्वारा किया जाना चाहिए। NoSQL में, उन परतों को आम तौर पर उजागर किया जाता है, जिससे आप उन पर हैक कर सकते हैं।

Comments

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

— १ed

@ इसका सबूत देना मुश्किल है, क्योंकि NoSQL एक दृष्टिकोण है, उत्पाद नहीं (SQL के लिए समान)। हालाँकि, यह ध्यान देने योग्य है कि BigTable, एक NoSQL कार्यान्वयन, कॉलम की एक अवधारणा है, जैसे SQL टेबल करते हैं। इसके कॉलम की अवधारणा जो आपको यह जानने के लिए डेटा को छोड़ देती है कि कहां देखना है, जिसे या तो कार्यान्वयन के लिए लागू किया जा सकता है।

— Cort Ammon

Answer 3

NoSQL एक बल्कि अस्पष्ट शब्द है, क्योंकि यह मूल रूप से सभी डेटाबेस सिस्टम को कवर करता है जो कि रिलेशनल नहीं हैं।

आप जो वर्णन करते हैं वह एक कुंजी-मूल्य स्टोर है , जो एक प्रकार का डेटाबेस है जहां डेटा की एक बूँद एक कुंजी के नीचे संग्रहीत होती है, और यदि आप कुंजी जानते हैं तो जल्दी से देखा जा सकता है। यदि आप सटीक कुंजी जानते हैं, तो ये डेटाबेस तेज़ी से धधक रहे हैं, लेकिन जैसा कि आप स्वयं कहते हैं, यदि आपको डेटा पर कई गुणों को खोजने या फ़िल्टर करने की आवश्यकता है, तो यह धीमा और बोझिल हो जाएगा।

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

तो जवाब बहुत स्पष्ट है: यदि आपको केवल एक कुंजी का उपयोग करके स्टोर करना और देखना है, तो कुंजी-मूल्य स्टोर का उपयोग करें। अन्यथा एक अलग तरह के डेटाबेस का उपयोग करें। और यदि आप संदेह में हैं, तो एक रिलेशनल डेटाबेस का उपयोग करें, क्योंकि यह सबसे बहुमुखी प्रकार का डेटाबेस है, जबकि NoSQL डेटाबेस अक्सर बहुत विशेष उपयोग के मामलों के लिए अनुकूलित होते हैं।

Comments

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

— जोर्ग डब्ल्यू मित्तग

@ JörgWMittag आपकी परिभाषा के अनुसार, अगर मैं MySQL का चयन करता हूं, क्योंकि इसका सबसे अच्छा DB मेरे डेटा से मेल खाता है, तो एक वैध एसक्यूएल समाधान है।

@ JörgWMittag: Thee शब्द NoSQL की कोई आधिकारिक परिभाषा नहीं है, लेकिन आमतौर पर यह गैर-रिलेशनल डेटाबेस सिस्टम को संदर्भित करता है। "न केवल केवल Sql" -backronym वास्तव में अपरिवर्तनीय प्रचार-प्रतिवाद का प्रतिकार करने के लिए एक अधिक हालिया प्रतिधारण है। लेकिन आम उपयोग में, NoSQL का उपयोग MongoDb, Bigtable आदि जैसे सिस्टम का वर्णन करने के लिए किया जाता है, ट्यूटोरियल डी नहीं कहते हैं (जो डेटाबेस भी नहीं है)।

— जैक्सबी

@ JörgWMittag NoSQL का मूल अर्थ "नॉन एसक्यूएल" या "नॉन रिलेशनल" था। "न केवल एसक्यूएल" एनओएसक्यूएल होगा क्योंकि यह "नो" शब्द के संयोजन के बजाय एक संक्षिप्त रूप है और "एसक्यूएल" का संक्षिप्त नाम है। यह एक डेटाबेस में सब कुछ डालने के सामान्य अभ्यास के लिए एक काउंटर के रूप में लोकप्रिय हो गया (जैसा कि विकिपीडिया लेख में कहा गया है)। जैसा कि आपने टिप्पणी की, क्षेत्र अब थोड़ा अधिक जटिल है।

— 18

पूरी तरह से सहमत हूँ। ऐसा लगता है कि NoSQL के मुख्य पैटर्न की-वैल्यू (उदाहरण के लिए रेडिस) डॉक्यूमेंट स्टोर (जैसे Mongo) और ग्राफ (जैसे Neo4J) हैं। काश लोग NoSQL को खोदते और उन शब्दों में से एक का उपयोग करते।

— पज28

Answer 4

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

ये लक्ष्य अक्सर एक दूसरे के साथ संघर्ष करते हैं। ट्विटर के बहुत सारे उपयोगकर्ता दुनिया भर से लोगों का अनुसरण करते हैं। क्या ट्वीट पढ़ने या ट्वीट लिखने के लिए ट्विटर के डेटाबेस को भौगोलिक रूप से अनुकूलित किया जाना चाहिए?

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

Comments

RAM में 10TB पढ़ने में कुछ समय लगता है @Daniel ... कुछ घंटों में एक बहुत अच्छा परिणाम होगा। यह एक आपदा से उबरना अपेक्षाकृत विनाशकारी होगा।

— बेन

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

— dirkk

ये गलत है। प्रोग्रामिंग दृष्टिकोण के रूप में साझा करना वर्षों से बड़े पैमाने पर डेटाबेस में मानक रहा है और कुछ डेटाबेस पारदर्शी रूप से डेटा साझा करने के साथ क्लस्टर (ओरेकल आरएसी) का समर्थन करते हैं। आपको क्या लगता है कि सभी बैंक कैसे काम करते हैं? और एक उचित सेटअप के साथ आप RARELY बैकअप बहाल करते हैं - जो कि वास्तविक "2 डेटा सेंटर बर्न" परिदृश्य के रूप में छोड़ दिया जाता है। और हाँ, एक बार 30tb डेटाबेस पर काम कर रहा था - हमें कोई समस्या नहीं थी।

— टॉमटॉम

हां, रिलेशनल डेटाबेस पारदर्शी डेटा को तेज और क्लस्टरिंग करते हैं, लेकिन यदि आप प्रदर्शन के अनुकूलन के बारे में परवाह करते हैं तो यह बहुत ही लीक से हटकर है।

— कार्ल

Answer 5

NoSQL डेटाबेस का " No SQL" के साथ बहुत कम संबंध है ।

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

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

NoSQL डेटाबेस में प्रोग्रामर बहुत सारे इंडेक्स को बनाए रखने के लिए जिम्मेदार होता है और यह माना जाता है कि इंडेक्स हमेशा पुराने हो जाएंगे।

उदाहरण के लिए:

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

एक वास्तविक उदाहरण के रूप में, अमेज़ॅन मुझे एक पुस्तक की तारीख के विवरण से बाहर दिखाएगा, जो कि 106 कंप्यूटरों की प्रतीक्षा करके वेब पेज के प्रदर्शन में देरी से यह पुष्टि करता है कि सही लॉक निकाल लिया गया है।

इसलिए .....

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

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

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

Comments

यह अंतिम tidbit बहुत दिलचस्प है - क्या आपके पास कुछ मेटा साइट का लिंक है जो इच्छुक पाठकों के लिए NoSQL के SO (गैर) उपयोग के बारे में क्लिक करने के लिए है? धन्यवाद!

— १२:१२ पर kcrisman

@ क्राइसमैन, देखें उच्चस्तरीयता। www.stack-overflow- साँस छोड़ना के लिए

— Ian

Answer 6

रिलेशनल डेटाबेस को प्रभावी ढंग से डेटारो में किसी भी मूल्य की खोज के लिए अनुकूलित किया जाता है।

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

Comments

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

— जेएफओ

Answer 7

पहले से ही कई उत्तर हैं, लेकिन मैं सिर्फ अपना सारांश जोड़ना चाहता था।

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

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

Answer 8

मैं अब दो साल से काउचडब का उपयोग कर रहा हूं। यह ज्यादातर सामग्री प्रबंधन और विन्यास के लिए उपयोग किया जाता है।

पदानुक्रमित संबंधों के लिए प्रबंधन करना बहुत आसान है जब आप उन्हें कल्पना कर सकते हैं। पढ़ने के लिए ज्यादातर डेटा के लिए, JSON को संपादित करना आसान है, क्योंकि यह कई मामलों में एक अद्यतन विवरण लिखना है। JSON को संपादित करने के लिए वास्तव में एक प्रोग्रामर नहीं लेता है। और SQL आपको पंक्तियाँ और कॉलम देता है, जिन्हें आपको तब किसी प्रकार की ऑब्जेक्ट संरचना में मैप करना होता है।

आपको एक प्रदर्शन को बढ़ावा भी मिलता है क्योंकि आप जटिल प्रश्नों पर 10-20 तालिकाओं में शामिल नहीं हो रहे हैं। काउचडब विचार बहुत तेज हैं क्योंकि जावास्क्रिप्ट वे जिस पर आधारित हैं, क्वेरी समय पर निष्पादित नहीं किया जाता है।

अधिकांश प्रोग्रामर जावास्क्रिप्ट को समझते हैं, और अधिकांश प्रोग्रामर SQL के साथ कभी-कभी संघर्ष करते हैं।

काउचडब में, एक दृश्य को JSON दस्तावेज़ के सार के रूप में सोचा जा सकता है। डेटा को कैसे संरचित किया जाता है यह आपके ऊपर है (आप मूल पदानुक्रम द्वारा विवश नहीं हैं)।

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

हालांकि, ध्यान दें कि कोई स्पष्ट 'सामान्यीकरण' नहीं है जिसे लागू किया जा सकता है (हालांकि डेटा के दोहराव से बचना एक योग्य लक्ष्य है), और अनिवार्य रूप से और 'आशावादी' अपडेट स्ट्रेटेजी आशावादी लॉकिंग के समान है।