database - मुझे डेटाबेस के बजाय दस्तावेज़ आधारित डेटाबेस का उपयोग क्यों करना चाहिए?




couchdb relational (4)

कॉच डीबी (उनकी website )

  • एक दस्तावेज़ डेटाबेस सर्वर, एक विश्वसनीय JSON API के माध्यम से सुलभ। आम तौर पर, रिलेशनल डेटाबेस को आरईएसटी सेवाओं के माध्यम से आसानी से एक्सेस नहीं किया जाता है, लेकिन एक अधिक जटिल एसक्यूएल एपीआई की आवश्यकता होती है। अक्सर इन एपीआई (जेडीबीसी, ओडीबीसी, आदि) काफी जटिल हैं। आरईएसटी काफी सरल है।

  • एक फ्लैट पता स्थान के साथ विज्ञापन-प्रसार और स्कीमा-मुक्त। रिलेशनल डेटाबेस में जटिल, निश्चित स्कीमा है। आप टेबल, कॉलम, इंडेक्स, अनुक्रम, विचार और अन्य सामान को परिभाषित करते हैं। सोफे को जटिल, महंगी, नाजुक उन्नत योजना के इस स्तर की आवश्यकता नहीं है।

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

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

इसलिए। क्यों कॉच डीबी?

  • आरईएसटी जेडीबीसी या ओडीबीसी से सरल है।
  • स्कीमा की तुलना में कोई स्कीमा आसान नहीं है।
  • एक तरह से वितरित जो सरल और सस्ता दिखाई देता है।

मुझे संबंधपरक डेटाबेस का उपयोग करने के बजाय दस्तावेज़ आधारित डेटाबेस जैसे CouchDB का उपयोग क्यों करना चाहिए। क्या कोई विशिष्ट प्रकार के अनुप्रयोग या डोमेन हैं जहां दस्तावेज़ आधारित डेटाबेस संबंधपरक डेटाबेस से अधिक उपयुक्त है?


तेजी से आवेदन विकास दिमाग में आता है।

जब मैं लगातार अपनी स्कीमा विकसित कर रहा हूं, तो मैं लगातार MySQL / SQLite में स्कीमा को बनाए रखने से निराश हूं। हालांकि मैंने अभी तक कॉच डीबी के साथ बहुत कुछ नहीं किया है, मुझे लगता है कि आरएडी प्रक्रिया के दौरान स्कीमा विकसित करना कितना आसान है।

एक ऐसा मामला जहां आप गैर-रिलेशनल डेटाबेस का उपयोग नहीं करना चाहते हैं, तब आपके पास बहुत से रिश्ते हैं; मुझे अभी तक इस तरह के रिश्तों के आसपास अच्छे MapReduce कार्यों को बनाने के तरीके के बारे में मेरा सिर नहीं मिला है, खासकर अगर आपको शामिल होने वाले रिश्ते में मेटाडेटा होना चाहिए। मुझे यकीन नहीं है, लेकिन मुझे नहीं लगता कि CouchDB मानचित्र फ़ंक्शन डेटाबेस पर अपने स्वयं के प्रश्नों को कॉल कर सकते हैं, क्योंकि इससे संभावित रूप से अनंत लूप हो सकते हैं।


मूर्खतापूर्वक भंडारण और अन्य सर्वर-डेटा की सेवा के लिए।

पिछले कुछ हफ्तों में मैं एक लाइफस्ट्रीम ऐप के साथ खेल रहा हूं जो मेरी फीड (स्वादिष्ट, फ़्लिकर, जिथब, ट्विटर ...) को चुनाव करता है और उन्हें कॉचडब में स्टोर करता है। कॉचडब की सुंदरता यह है कि यह मुझे मूल डेटा को मूल संरचना में बिना किसी ओवरहेड के रखता है। मैंने प्रत्येक दस्तावेज़ में 'क्लास' फ़ील्ड जोड़ा, स्रोत सर्वर संग्रहित किया, और प्रत्येक स्रोत के लिए जावास्क्रिप्ट रेंडर क्लास लिखा।

सामान्यीकरण, जब भी आपका सर्वर किसी अन्य सर्वर से संचार करता है तो स्कीमा-कम संग्रहण सबसे अच्छा होता है क्योंकि आपके पास स्कीमा पर कोई नियंत्रण नहीं होता है। बोनस के रूप में, कॉचडब सर्वर और क्लाइंट के मूल प्रोटोकॉल का उपयोग करता है - परिवहन के लिए जेएसओएन और परिवहन के लिए HTTP आरईएसटी।


शायद आपको नहीं करना चाहिए :-)

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

मैं व्यक्तिगत रूप से इस तथ्य से भी प्यार करता हूं कि मुझे HTTP क्लाइंट को छोड़कर कोच डीबी के लिए किसी क्लाइंट लाइब्रेरी की आवश्यकता नहीं है, जो आजकल लगभग हर प्रोग्रामिंग भाषा में शामिल है।

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

अधिक विस्तृत सूची के लिए रिचर्ड जोन्स की इस पोस्टिंग की जांच करें





non-relational-database