2011-10-22 18 views
13

के नुकसान मैं हाल ही में कॉच डीबी के साथ प्यार में गिर गया है। मैं इसके विशाल लाभ और इसकी सुंदरता से बहुत उत्साहित हूं। अब मैं यह सुनिश्चित करना चाहता हूं कि मैंने किसी शो-स्टॉपिंग नुकसान को याद नहीं किया है।कॉच डीबी

आपके दिमाग में क्या आता है? संलग्न उन बिंदुओं की एक सूची है जिन्हें मैंने एकत्र किया है। क्या जोड़ने के लिए कुछ भी है?

  • 2010 के उत्तरार्ध से ब्लॉग पोस्ट "पर्याप्त परिपक्व नहीं" दावा करते हैं (जो कुछ भी लायक है)।
  • इन-मेमोरी डीबीएमएस की तुलना में धीमी है।
  • इन-प्लेस अपडेटों के लिए सर्वर-साइड लॉजिक (update handlers) की आवश्यकता होती है।
  • व्यापार डिस्क बनाम गति: अन्य डीबीएमएस की तुलना में डेटाबेस बड़े हो सकते हैं (हालांकि कार्यक्षमता कार्यक्षमता मौजूद है)।
  • "केवल" अंतिम स्थिरता।
  • बड़े डेटासेट पर अस्थायी विचार बहुत धीमी हैं।
  • बड़े डेटाबेस का प्रतिकृति may fail
  • मानचित्र/प्रतिमान को कम करने के लिए पुनर्विचार की आवश्यकता है (केवल पूर्णता के लिए)।

केवल मुद्दा यह है कि चिंता मुझे, # 3 (यथा-स्थान अपडेट) है, क्योंकि यह काफी असुविधाजनक है।

+0

HTTP संचार ओवरहेड के बारे में क्या? सोफे में मूल्यों को बाधित करने में कठिनाई के बारे में क्या (यूनिक्स करना मुश्किल है) – Raynos

उत्तर

10
  • डेटा JSON में है

जिसका अर्थ है कि दस्तावेज़ काफी बड़े हैं (बिगडाटा, नेटवर्क बैंडविड्थ, गति), और वर्णनात्मक कुंजी नाम वास्तव में दर्द होता है, क्योंकि वे दस्तावेज़ आकार में शामिल होते हैं।

  • कोई पूर्ण पाठ खोज में बनाया

    यद्यपि तरीके हैं: couchdb-lucene, elasticsearch

प्लस some more:

  • यह लेन-देन

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

  • संबंधपरक डेटा

डेटा भावना का एक बहुत 3 सामान्य रूप में किया जा के लिए बनाता है, और हम CouchDB में उस रूप पालन करने की कोशिश करते हैं, तो हम का एक बहुत में चलाने के लिए जा रहे मुसीबत। इस समस्या को हल करने का एक संभावित तरीका दृश्य संयोजनों के साथ है, लेकिन हम लगातार सिस्टम के साथ लड़ने जा रहे हैं। यदि डेटा को और अधिक denormalized होने के लिए reformatted किया जा सकता है, तो CouchDB ठीक काम करेगा।

  • डाटा गोदाम

इस के साथ समस्या यह है कि बड़े डेटासेट पर CouchDB में अस्थायी विचारों वास्तव में धीमी गति से हो रहा है। कॉच डीबी और स्थायी विचारों का उपयोग करना काफी अच्छा काम कर सकता है। हालांकि, ज्यादातर मामलों में, कुछ प्रकार के कॉलम-ओरिएंटेड डेटाबेस डेटा वेयरहाउसिंग नौकरी के लिए एक बेहतर उपकरण है।

लेकिन कॉच डीबी रॉक्स!

लेकिन इसे आपको हटाने की अनुमति न दें: Erlang (CouchDB, Riak) में लिखे गए NoSQL डीबी सबसे अच्छे हैं, क्योंकि Erlang वितरित सिस्टम के लिए है। सोफे के साथ मजा करो!

5

2 और बातें, जो जब CouchDB का उपयोग कर मुझे रोने (हालांकि यह कमाल का है) बनाने:

  • यह अक्सर अद्यतन डेटा
  • के लिए नहीं बनाया गया है इसमें अंतर्निहित है नहीं करता है की प्रतिलिपि प्राप्त खोज
1
    वर्तमान में
  • एड-हॉक क्वेरी के लिए कोई समर्थन तेजी से संचार
+0

UnQL ईमानदार होने के लिए व्यर्थ है। यदि सभी NoSQL डेटाबेस UnQL का समर्थन करने के लिए थे तो हम जल्द ही NoUnQL डेटाबेस देखेंगे। NoSQL डेटाबेस इस तरह से दिलचस्प हैं कि वे एक क्वेरी भाषा के शीर्ष पर नहीं बल्कि डेटा स्टोर करने के तरीके पर डिज़ाइन किए गए हैं। यह चीजों को पागल के रूप में बनाता है जैसे कि सीएचडीडीबी जैसे बाकी डेटाबेस। बाइनरी प्रोटोकॉल के लिए, यह उपयोगी हो सकता है लेकिन जहां तक ​​मैं कह सकता हूं, http प्रोटोकॉल की गति वास्तव में couchdb के साथ बड़ी समस्या नहीं है। –

0

के लिए द्विआधारी प्रोटोकॉल समर्थन की

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

  • 3
    • पाठक एसीएल की कमी (लेखकों के लिए मौजूद है हालांकि,)

    के रूप में एक पुराने लोटस डोमिनो समर्थक मैं एक नई परियोजना मैं बंद लात हूँ के लिए एक विकल्प के रूप CouchDB करने के लिए देख रहा था और पाया कोच बनाम डोमिनोज़ में पाठकों पर बहुत कमजोर होने की सीमाएं। मेरी ऐप सुरक्षा में एक महत्वपूर्ण विचार है और कोच को रीडर सुरक्षा को संभालने के लिए मिडलवेयर परत की आवश्यकता होगी।

    यदि आपके पास डेटाबेस है जिसमें यह ठीक है कि सभी परिभाषित उपयोगकर्ता सभी दस्तावेज देख सकते हैं, तो सोफे एक दिलचस्प मंच की तरह दिखता है।

    यदि पढ़ना प्रतिबंधित करना आवश्यक है तो आपको एक मिडलवेयर समाधान देखने या किसी अन्य विकल्प पर विचार करने की आवश्यकता होगी।

    कॉच डीबी डेवलपर्स को नोट करें: प्लेटफॉर्म सुरक्षा विकल्पों में सुधार करें। मुझे एहसास है कि जब इस्तेमाल होता है तो वे प्रदर्शन को कम कर देंगे लेकिन ध्यान दें कि विकल्प उपलब्ध कराएं।

    अब यह निर्धारित करने के लिए कि कौन सा डेटाबेस उपयोग करना है ...

    +0

    हां। यह मुझे सोफे-केवल एप्लिकेशन चलाने से रोकता है। – nisc

    +0

    यदि कोई दिलचस्पी लेता है, तो डोमिनोज़ 8.5.3 में डोमिनोज़ डेटा सेवा सुविधाओं के माध्यम से JSONRest समर्थन शामिल है। आपको आरईएसटी समर्थन के साथ पूर्ण डोमिनोज़ सुरक्षा मॉडल मिल गया है। बहुत अच्छा। http://www-10.lotus.com/ldd/ddwiki.nsf/xpViewCategories.xsp?lookupName=Domino%20Data%20 सेवा –

    संबंधित मुद्दे