मुझे संबंधपरक डेटाबेस का उपयोग करने के बजाय CouchDB जैसे दस्तावेज़ आधारित डेटाबेस का उपयोग क्यों करना चाहिए। क्या कोई विशिष्ट प्रकार के अनुप्रयोग या डोमेन हैं जहां दस्तावेज़ आधारित डेटाबेस रिलेशनल डेटाबेस से अधिक उपयुक्त है?
जवाबों:
संभवतः आपको :-)
यदि आपका डेटा संबंधपरक नहीं है, तो दूसरा सबसे स्पष्ट उत्तर आपको इसका उपयोग करना चाहिए। यह आमतौर पर कॉलम के एक सेट के रूप में आपके डेटा का वर्णन करने का कोई आसान तरीका होने में खुद को प्रकट करता है। एक अच्छा उदाहरण एक डेटाबेस है जहां आप वास्तव में कागज के दस्तावेज़ों को संग्रहीत करते हैं, उदाहरण के लिए कार्यालय मेल को स्कैन करके। डेटा स्कैन की गई पीडीएफ है और आपके पास कुछ मेटा डेटा है जो हमेशा मौजूद रहता है (स्कैन किया हुआ, स्कैन किया हुआ, दस्तावेज़ का प्रकार) और बहुत सारे संभावित मेटाडेटा फ़ील्ड जो कुछ समय में मौजूद रहते हैं (ग्राहक संख्या, आपूर्तिकर्ता संख्या, क्रम संख्या, जब तक फ़ाइल पर रहते हैं ओसीआर फुलटेक्स्ट, आदि)। आमतौर पर आपको पहले से पता नहीं होता है कि आप अगले दो वर्षों के भीतर किन मेटाडेटा क्षेत्रों को जोड़ेंगे। CouchDB जैसी चीजें रिलेशनल डेटाबेस की तुलना में उस तरह के डेटा के लिए बहुत अच्छे काम करती हैं।
मुझे व्यक्तिगत रूप से इस तथ्य से भी प्यार है कि मुझे एक HTTP क्लाइंट को छोड़कर, CouchDB के लिए किसी भी क्लाइंट लाइब्रेरी की आवश्यकता नहीं है, जो आजकल लगभग हर प्रोग्रामिंग भाषा में शामिल है।
शायद कम से कम स्पष्ट उत्तर: यदि आपको आरडीबीएमएस का उपयोग करके कोई दर्द महसूस नहीं होता है, तो उसके साथ रहें। यदि आपको अपना काम पूरा करने के लिए हमेशा अपने RDBMS के आसपास काम करना पड़ता है, तो एक दस्तावेज़ उन्मुख डेटाबेस देखने लायक हो सकता है।
एक अधिक विस्तृत सूची के लिए रिचर्ड जोन्स की इस पोस्टिंग की जाँच करें ।
CouchDB (उनकी वेबसाइट से )
एक दस्तावेज़ डेटाबेस सर्वर, एक RESTful JSON एपीआई के माध्यम से सुलभ। आमतौर पर, रिलेशनल डेटाबेस को केवल REST सेवाओं के माध्यम से एक्सेस नहीं किया जाता है, लेकिन इसके लिए बहुत अधिक जटिल SQL API की आवश्यकता होती है। अक्सर ये एपीआई (जेडीबीसी, ओडीबीसी, आदि) काफी जटिल होते हैं। REST काफी सरल है।
एक फ्लैट एड्रेस स्पेस के साथ एड-हॉक और स्कीमा-मुक्त। रिलेशनल डेटाबेस में जटिल, निश्चित स्कीमा होता है। आप टेबल, कॉलम, इंडेक्स, अनुक्रम, दृश्य और अन्य सामान को परिभाषित करते हैं। काउच को जटिल, महंगी, नाजुक उन्नत योजना के इस स्तर की आवश्यकता नहीं है।
वितरित, द्वि-दिशात्मक संघर्ष का पता लगाने और प्रबंधन के साथ मजबूत, वृद्धिशील प्रतिकृति की विशेषता। कुछ SQL वाणिज्यिक उत्पाद इसकी पेशकश करते हैं। SQL API और फिक्स्ड स्कीमा के कारण, यह जटिल, कठिन और महंगा है। काउच के लिए, यह सरल और सस्ती प्रतीत होता है।
क्वेरी-सक्षम और इंडेक्स-सक्षम, तालिका उन्मुख रिपोर्टिंग इंजन की विशेषता है जो जावास्क्रिप्ट भाषा को क्वेरी भाषा के रूप में उपयोग करता है। तो SQL और संबंधपरक डेटाबेस करता है। यहां कुछ भी नया नहीं है।
इसलिए। CouchDB क्यों?
मूर्खतापूर्ण भंडारण और अन्य सर्वर-डेटा की सेवा के लिए।
पिछले कुछ हफ्तों में मैं एक लाइफ़स्ट्रीम ऐप के साथ खेल रहा हूं, जो मेरे फीड्स (स्वादिष्ट, फ़्लिकर, जीथब, ट्विटर ...) को प्रदूषित करता है और उन्हें काउचडब में संग्रहीत करता है। काउचडब की सुंदरता यह है कि यह मुझे मूल डेटा को मूल संरचना में बिना किसी ओवरहेड के रखने देता है। मैंने स्रोत दस्तावेज़ को संग्रहीत करते हुए प्रत्येक दस्तावेज़ में एक 'क्लास' फ़ील्ड जोड़ा, और प्रत्येक स्रोत के लिए एक जावास्क्रिप्ट रेंडर क्लास लिखी।
सामान्यीकरण, जब भी आपका सर्वर किसी अन्य सर्वर के साथ एक स्कीमा-कम भंडारण के लिए संचार करता है, तो आपके पास स्कीमा पर कोई नियंत्रण नहीं होता है। एक बोनस के रूप में, couchdb सर्वर और क्लाइंट के मूल प्रोटोकॉल का उपयोग करता है - प्रतिनिधित्व के लिए JSON और परिवहन के लिए HTTP REST।
तेजी से अनुप्रयोग विकास का ख्याल आता है।
जब मैं अपने स्कीमा को लगातार विकसित कर रहा हूं, तो MySQL / SQLite में स्कीमा बनाए रखने के लिए लगातार निराश हो रहा हूं। जबकि मैंने अभी तक CouchDB के साथ बहुत अधिक नहीं किया है, मुझे यह पसंद है कि RAD प्रक्रिया के दौरान स्कीमा को विकसित करना कितना सरल है।
एक ऐसा मामला जहां आप एक गैर-संबंधपरक डेटाबेस का उपयोग नहीं करना चाहते हैं, जब आपके पास कई-से-कई रिश्ते हैं; मुझे अभी तक अपना सिर नहीं मिला है कि इस प्रकार के रिश्तों के आसपास अच्छे MapReduce फ़ंक्शन कैसे बनाएं, खासकर यदि आपको जुड़ने वाले रिश्ते में मेटाडेटा की आवश्यकता है। मुझे यकीन नहीं है, लेकिन मुझे नहीं लगता कि काउचडीबी मैप फ़ंक्शन अपने स्वयं के प्रश्नों को डेटाबेस पर कॉल कर सकता है, क्योंकि यह संभावित रूप से अनंत लूप का कारण बन सकता है।
दस्तावेज़-आधारित डेटाबेस का उपयोग करें जब आपको प्रत्येक रिकॉर्ड के लिए समान आकार के फ़ील्ड के साथ तालिकाओं में डेटा संग्रहीत करने की आवश्यकता नहीं होती है। इसके बजाय, आपको प्रत्येक रिकॉर्ड को एक दस्तावेज के रूप में संग्रहीत करने की आवश्यकता है जिसमें कुछ विशेषताएं हैं। किसी भी लंबाई के किसी भी क्षेत्र को गतिशील रूप से पहले "तालिका को संशोधित" करने की आवश्यकता के बिना किसी भी समय दस्तावेज़ में जोड़ा जा सकता है। दस्तावेज़-आधारित फ़ील्ड में डेटा के कई टुकड़े हो सकते हैं।
Smdelfin पर विस्तृत करने के लिए: लचीलापन। आप किसी भी संरचना (असंरचित और सभी में) में डेटा स्टोर कर सकते हैं और हर दस्तावेज़ पूरी तरह से अलग हो सकता है। CouchDB विशेष रूप से उपयोगी है क्योंकि उनके "व्यू" इंडेक्स के साथ, आप विशिष्ट दस्तावेज़ों को फ़िल्टर कर सकते हैं और जब आप अपने डेटाबेस के उन सबसेट को चाहते हैं तो उस दृश्य को क्वेरी कर सकते हैं।
दस्तावेज़ डेटाबेस का मेरा सबसे बड़ा विजेता बिंदु जो JSON प्रारूप में डेटा संग्रहीत करता है: यह जावास्क्रिप्ट के लिए मूल प्रारूप है। इसलिए, जावास्क्रिप्ट वेब एप्लिकेशन CouchDB के साथ अविश्वसनीय रूप से अच्छी तरह से काम करते हैं। मैंने हाल ही में एक वेब ऐप बनाया है जो काउचडीबी का उपयोग करता है और यह तेजी से रॉकेट है जबकि लगातार बदलती डेटा संरचना को संभालने में भी सक्षम है।
दस्तावेज़ आधारित डेटाबेस का संबंधपरक डेटाबेस पर एक बड़ा लाभ है क्योंकि उन्हें किसी भी डेटा को दर्ज करने में सक्षम होने से पहले एक स्कीमा को परिभाषित करने की आवश्यकता नहीं होती है।
इसके अलावा, आपको एक दस्तावेज़ डेटाबेस का उपयोग करना चाहिए यदि आप डेटा संबंधपरक नहीं हैं और किसी तालिका में संग्रहीत नहीं किए जा सकते हैं, बल्कि छवियों का एक सेट है, या उदाहरण के लिए समाचार पत्र लेख।
एक और लाभ वेब विकास में दस्तावेज़ आधारित डेटाबेस का उपयोग करने की सुगमता है। अधिक गहराई के लिए NoSQL डेटाबेस मॉडल कॉमरिसन इस स्रोत की जाँच करें: https://arxiv.org/ftp/arxiv/papers/1509/1509.08035.pdf