जवाबों:
संबंधपरक डेटाबेस ACID को लागू करता है । तो, आपके पास स्कीमा आधारित लेनदेन उन्मुख डेटा स्टोर होंगे। यह वास्तविक दुनिया के अनुप्रयोगों के 99% के लिए सिद्ध और उपयुक्त है। आप रिलेशनल डेटाबेस के साथ व्यावहारिक रूप से कुछ भी कर सकते हैं।
लेकिन, जब बड़े पैमाने पर उच्च उपलब्धता डेटा स्टोर की बात आती है तो गति और स्केलिंग की सीमाएँ होती हैं। उदाहरण के लिए, Google और Amazon के पास बड़े डेटा केंद्रों में संग्रहीत डेटा की टेराबाइट्स हैं। RDBMs के अवरुद्ध / स्कीमा / लेन-देन प्रकृति के कारण इन परिदृश्यों में क्वेरी करना और सम्मिलित करना प्रदर्शन योग्य नहीं है। यही कारण है कि बड़े पैमाने पर प्रदर्शन लाभ और मापनीयता के लिए उन्होंने अपने स्वयं के डेटाबेस (वास्तव में, कुंजी-मूल्य वाले स्टोर) को लागू किया है।
NoSQL डेटाबेस एक लंबे समय के लिए चारों ओर रहा है - बस शब्द नया है। कुछ उदाहरण ग्राफ़, ऑब्जेक्ट, कॉलम, एक्सएमएल और दस्तावेज़ डेटाबेस हैं।
आपके दूसरे प्रश्न के लिए: क्या एक ही साइट पर दोनों का उपयोग करना ठीक है?
क्यों नहीं? दोनों अलग-अलग उद्देश्यों को पूरा करते हैं?
NoSQL समाधान आमतौर पर एक समस्या को हल करने के लिए होते हैं जो रिलेशनल डेटाबेस या तो अच्छी तरह से अनुकूल नहीं होते हैं, बहुत महंगी (जैसे ओरेकल) का उपयोग करने के लिए या आपको कुछ ऐसा लागू करने की आवश्यकता होती है जो आपके db के संबंधपरक स्वरूप को वैसे भी तोड़ देता है।
लाभ आमतौर पर आपके उपयोग के लिए विशिष्ट होते हैं, लेकिन जब तक आपको किसी आरडीबीएमएस में अपना डेटा मॉडलिंग करने में किसी प्रकार की समस्या नहीं होती है, तब तक मुझे कोई कारण नहीं दिखता है कि आप NoSQL क्यों चुनेंगे।
मैं स्वयं उन विशिष्ट समस्याओं के लिए MongoDB और Riak का उपयोग करता हूं जहां RDBMS एक व्यवहार्य समाधान नहीं है, अन्य सभी चीजों के लिए जो मैं MySQL (या परीक्षण के लिए SQLite) का उपयोग करता हूं।
यदि आपको एक NoSQL db की आवश्यकता है तो आप आमतौर पर इसके बारे में जानते हैं, संभावित कारण हैं:
यदि आपको NoSQL समाधान की आवश्यकता नहीं है, तो ध्यान रखें कि ये समाधान RDBMS के लिए प्रतिस्थापन के रूप में नहीं थे, बल्कि विकल्प के रूप में जहां पूर्व विफल रहता है और अधिक महत्वपूर्ण बात यह है कि वे अपेक्षाकृत नए हैं जैसे कि उनमें अभी भी बहुत सारे कीड़े हैं और गायब सुविधाएँ।
ओह, और दूसरे प्रश्न के संबंध में किसी भी तकनीक का दूसरे के साथ उपयोग करना पूरी तरह से ठीक है, इसलिए बस मेरे अनुभव से पूरा होना है और जब तक वे एक ही मशीन पर नहीं होते हैं तब तक MySQL एक साथ ठीक काम करता है
मार्टिन फाउलर के पास एक उत्कृष्ट वीडियो है जो NoSQL डेटाबेस की अच्छी व्याख्या देता है। उनके उपयोग करने के लिए लिंक सीधे उनके कारणों पर जाता है, लेकिन पूरे वीडियो में अच्छी जानकारी होती है।
आपके पास बड़ी मात्रा में डेटा है - खासकर यदि आप यह सब एक भौतिक सर्वर पर फिट नहीं कर सकते हैं क्योंकि NoSQL को अच्छी तरह से स्केल करने के लिए डिज़ाइन किया गया था।
ऑब्जेक्ट-रिलेशनल प्रतिबाधा बेमेल - आपके डोमेन ऑब्जेक्ट एक रिलेशनल डेटाबेस स्कीमा में अच्छी तरह से फिट नहीं होते हैं। NoSQL आपको अपने डेटा को दस्तावेज़ों (या ग्राफ़) के रूप में जारी रखने की अनुमति देता है जो आपके डेटा मॉडल के बहुत अधिक निकट हो सकते हैं।
NoSQL डेटाबेस सिस्टम है जहाँ डेटा को दस्तावेज़ (MongoDB), की-वैल्यू पेयर (MemCache, Redis), ग्राफ स्ट्रक्चर फॉर्म (Neo4J) में व्यवस्थित किया जाता है।
हो सकता है कि "जब आप NoSQL के लिए जाएं" के लिए यहां संभव सवाल और जवाब हों:
लचीले स्कीमा की आवश्यकता है या डेटा जैसे पेड़ से निपटना है?
आम तौर पर, फुर्तीली विकास में हम अपफ्रंट में सभी आवश्यकता को जाने बिना डिजाइनिंग सिस्टम को शुरू करते हैं, जहां बाद में पूरे डेटाबेस में सिस्टम को लगातार डिजाइन परिवर्तन, एमवीपी (न्यूनतम व्यवहार्य उत्पाद) को दिखाने की आवश्यकता हो सकती है। या आप डेटा स्कीमा के साथ काम कर रहे हैं जो प्रकृति में गतिशील है। जैसे सिस्टम लॉग, बहुत सटीक उदाहरण है एडब्ल्यूएस क्लाउडवॉच लॉग।
डेटा सेट विशाल / बड़ा है?
हां, NoSQL डेटाबेस उन अनुप्रयोगों के लिए बेहतर उम्मीदवार हैं जहां डेटाबेस को प्रदर्शन पर समझौता किए बिना मिलियन या अरबों रिकॉर्ड का प्रबंधन करने की आवश्यकता होती है।
RDMS के विपरीत स्थिरता को बढ़ाने के बीच व्यापार बंद , NoSQL डेटाबेस यहाँ और वहाँ छोटे डेटा खो सकता है (ध्यान दें: संभावना xx% है), लेकिन प्रदर्शन के मामले में इसका पैमाना आसान है। उदाहरण: यह उन लोगों के लिए अच्छा हो सकता है जो इंस्टेंट मैसेजिंग ऐप में ऑनलाइन हैं, डीबी में टोकन, वेब साइट ट्रैफ़िक आँकड़े लॉग कर रहे हैं।
जियोलोकेशन ऑपरेशंस करना: MongoDB हैश जियोइकिंग और जियोलोकेशन ऑपरेशंस करने के लिए भरपूर सपोर्ट करता है। मैं वास्तव में MongoDB की इस विशेषता से प्यार करता था।
संक्षेप में, MongoDB उन अनुप्रयोगों के लिए बहुत उपयुक्त है जहां आप बड़े पैमाने पर गतिशील संरचित डेटा को संग्रहीत कर सकते हैं।
प्रश्न का उत्तर देने के लिए कुछ आवश्यक जानकारी गायब है: डेटाबेस का उपयोग करने के लिए कौन से मामलों का उपयोग करना चाहिए? क्या मौजूदा डेटा ( OLAP ) से जटिल विश्लेषण करना पड़ता है या क्या एप्लिकेशन को कई लेनदेन ( OLTP ) संसाधित करने में सक्षम होना पड़ता है ? डेटा संरचना क्या है? यह प्रश्नकाल के अंत से दूर है।
मेरे विचार में, बिना उनके पीछे क्या है, यह जानने के लिए कि क्या बोल्ड buzzwords के आधार पर प्रौद्योगिकी निर्णय करना गलत है। NoSQL को अक्सर इसकी मापनीयता के लिए सराहा जाता है। लेकिन आपको यह भी जानना होगा कि क्षैतिज स्केलिंग (कई नोड्स पर) की कीमत भी है और यह मुफ़्त नहीं है। फिर आपको अंतिम स्थिरता जैसे मुद्दों से निपटना होगा और परिभाषित करना होगा कि डेटा विरोधों को कैसे हल किया जाए यदि वे डेटाबेस स्तर पर हल नहीं किए जा सकते हैं। हालाँकि, यह सभी वितरित डेटाबेस सिस्टम पर लागू होता है।
NoSQL में "स्कीमा कम" शब्द के साथ डेवलपर्स की खुशी शुरुआत में बहुत बड़ी है। यह buzzword तकनीकी विश्लेषण के बाद जल्दी से अस्वीकृत हो जाता है, क्योंकि इसे लिखते समय सही ढंग से स्कीमा की आवश्यकता नहीं होती है, लेकिन पढ़ते समय खेलने में आता है। इसीलिए इसे "रीड पर स्कीमा" सही ढंग से होना चाहिए। यह अपने विवेक पर डेटा लिखने में सक्षम होने के लिए आकर्षक हो सकता है। लेकिन अगर मौजूदा डेटा है लेकिन मैं स्थिति से कैसे निपटता हूं लेकिन एप्लिकेशन का नया संस्करण एक अलग स्कीमा की उम्मीद करता है?
दस्तावेज़ मॉडल (जैसा कि MongoDB में है, उदाहरण के लिए) डेटा मॉडल के लिए उपयुक्त नहीं है जहां डेटा के बीच कई संबंध हैं। जोड़ों को आवेदन स्तर पर किया जाना है, जो अतिरिक्त प्रयास है और मुझे उन चीजों को क्यों प्रोग्राम करना चाहिए जो डेटाबेस को करना चाहिए।
यदि आप तर्क देते हैं कि Google और अमेज़ॅन ने अपने स्वयं के डेटाबेस विकसित किए हैं क्योंकि पारंपरिक RDBMS अब डेटा की बाढ़ को नहीं संभाल सकते हैं, तो आप केवल यह कह सकते हैं: आप Google और अमेज़न नहीं हैं। ये कंपनियां स्पियरहेड हैं, कुछ 0.01% परिदृश्य जहां पारंपरिक डेटाबेस अब उपयुक्त नहीं हैं, लेकिन बाकी दुनिया के लिए वे हैं।
क्या महत्वहीन नहीं है: SQL लगभग 40 वर्षों से है और लाखों घंटे का विकास Oracle या Microsoft SQL जैसे बड़े सिस्टम में चला गया है। यह कुछ नए डेटाबेस द्वारा प्राप्त किया जाना है। कभी-कभी MongoDB के लिए किसी की तुलना में SQL व्यवस्थापक ढूंढना भी आसान होता है। जो हमें रखरखाव और प्रबंधन के सवाल पर लाता है। एक विषय जो बिल्कुल सेक्सी नहीं है, लेकिन यह प्रौद्योगिकी निर्णय का एक हिस्सा है।
आरडीबीएमएस डिजाइन से विचलन के लिए ठोस आधार की तलाश करते हुए मैं इस सवाल पर आया था।
जूलियन ब्राउन द्वारा एक महान पोस्ट है जो वितरित प्रणालियों की बाधाओं पर रोशनी डालता है। अवधारणा को ब्रूअर कैप प्रमेय कहा जाता है जो सारांश में है:
वितरित प्रणालियों की तीन आवश्यकताएं हैं: संगति, उपलब्धता और विभाजन सहिष्णुता (संक्षेप में CAP)। लेकिन आप एक समय में उनमें से केवल दो हो सकते हैं।
और इस तरह मैंने इसे अपने लिए संक्षेप में प्रस्तुत किया:
यदि आप निरंतरता का त्याग कर रहे हैं तो आप बेहतर तरीके से NoSQL के लिए जाते हैं।
मैंने NoSQL डेटाबेस के साथ समाधान तैयार और कार्यान्वित किया है और यहाँ SQL या दस्तावेज़-उन्मुख SQL के साथ जाने का निर्णय लेने के लिए मेरी जांच सूची है ।
DON'Ts
SQL अप्रचलित नहीं है और कुछ मामलों में एक बेहतर टूल बना हुआ है। जब एक दस्तावेज़ उन्मुख NoSQL के उपयोग को सही ठहराना कठिन हो
करने योग्य
यदि आपके पास वे शर्तें नहीं हैं या उन्हें कम कर सकते हैं, तो यहां 2 कारण दिए गए हैं, जहां आपको NoSQL से लाभ हो सकता है:
और जानकारी
अपने ब्लॉग पोस्ट में मैं अधिक विवरण में कारणों की व्याख्या करता हूं:
ध्यान दें: ऊपर केवल दस्तावेज़-उन्मुख NoSQL पर लागू होता है। कर रहे हैं अन्य प्रकार NoSQL की है, जो अन्य बातों की आवश्यकता है।
बड़ी संख्या में पढ़ने लिखने के संचालन को संभालना
जब आपको तेजी से स्केल करने की आवश्यकता होती है तो NoSQL डेटाबेस की ओर देखें। और जब आप आम तौर पर तेजी से पैमाने पर करने की आवश्यकता होती है?
जब आपकी वेबसाइट पर बड़ी संख्या में पढ़ने-लिखने के संचालन होते हैं और बड़ी मात्रा में डेटा के साथ काम करते समय, NoSQL डेटाबेस इन परिदृश्यों में सबसे अच्छा फिट होते हैं। चूंकि उनके पास मक्खी पर नोड्स जोड़ने की क्षमता है, इसलिए वे न्यूनतम समतलता के साथ अधिक समवर्ती यातायात और बड़ी मात्रा में डेटा को संभाल सकते हैं।
डेटा मॉडलिंग के साथ लचीलापन
दूसरा क्यू विकास के प्रारंभिक चरणों के दौरान है जब आप डेटा मॉडल, डेटाबेस डिजाइन के बारे में सुनिश्चित नहीं होते हैं, तो चीजों को तेजी से बदलने की उम्मीद है। NoSQL डेटाबेस हमें अधिक लचीलापन प्रदान करते हैं।
मजबूत संगति पर अंततः संगति
NoSQL डेटाबेस को चुनना बेहतर होता है जब यह हमारे लिए मजबूत स्थिरता पर छोड़ देने के लिए ठीक है और जब हमें लेनदेन की आवश्यकता नहीं होती है।
इसका एक अच्छा उदाहरण ट्विटर जैसी सोशल नेटवर्किंग वेबसाइट है। जब किसी सेलेब्रिटी का ट्वीट उड़ता है और हर कोई इसे पसंद करता है और दुनिया भर से इसे री-ट्वीट करता है। क्या फर्क पड़ता है अगर पसंद की गिनती थोड़ी देर के लिए ऊपर या नीचे जाती है?
सेलिब्रिटी निश्चित रूप से परवाह नहीं करेगा अगर वास्तविक 5 मिलियन 500 पसंद के बजाय, सिस्टम थोड़ी देर के लिए 5 मिलियन 250 की तरह गिनती दिखाता है।
जब दुनिया भर में फैले सैकड़ों सर्वरों पर एक बड़े एप्लिकेशन को तैनात किया जाता है, तो भौगोलिक रूप से वितरित नोड्स को वैश्विक सहमति तक पहुंचने में कुछ समय लगता है।
जब तक वे एक आम सहमति तक नहीं पहुंचते, तब तक इकाई का मूल्य असंगत है। इकाई का मूल्य अंततः थोड़ी देर के बाद सुसंगत हो जाता है। यह वही है जो अंततः संगति है।
हालांकि असंगतता का मतलब यह नहीं है कि किसी भी तरह का डेटा नुकसान है। इसका सीधा मतलब है कि वैश्विक सहमति पर पहुंचने और सुसंगत बनने के लिए महासागर के नीचे इंटरनेट केबल के माध्यम से दुनिया भर में यात्रा करने के लिए डेटा को कम समय लगता है।
हम हर समय इस व्यवहार का अनुभव करते हैं। खासकर यूट्यूब पर। अक्सर आपको एक वीडियो दिखाई देगा जिसमें 10 दृश्य और 15 पसंद होंगे। यह संभव ही कैसे है?
यह। वास्तविक विचार पहले से ही पसंद से अधिक हैं। यह सिर्फ विचारों की गिनती असंगत है और अपडेट होने में थोड़ी देर लगती है।
रनिंग डेटा एनालिटिक्स
NoSQL डेटाबेस डेटा एनालिटिक्स उपयोग के मामलों के लिए भी सबसे उपयुक्त होते हैं, जहाँ हमें भारी मात्रा में डेटा की आमद से निपटना पड़ता है।