मैं वर्तमान में बहुत अलग परतों पर कुछ अलग-अलग डेटा दृढ़ता आवश्यकताओं के साथ एक ऐप लिख रहा हूं और मैं सोच रहा हूं ... यह कब उचित है और जब मेरी दृढ़ता आवश्यकताओं को पूरा करने के लिए सोफे डीबी का उपयोग करना उचित नहीं है?सोफेडीबी का उपयोग करना उचित कब है?
क्या आपके पास एक रिलेशनशिप आवश्यकता है? कॉच डीबी (जैसा कि आप जानते हैं) में सामान्य डेटाबेस की रिलेशनल संरचना नहीं है।
क्या आप कर रहे हैं के लिए CouchDb की रीस्टफुल प्रकृति महत्वपूर्ण है?
शायद सबसे महत्वपूर्ण बात यह है कि यह आगे बढ़ने का समर्थन करने जा रहा है, और क्या वे कॉच डीबी को संभालने में सक्षम होंगे? यह एक काफी विशिष्ट उपकरण है, और इसके साथ अनुभव करने वाले लोगों को ढूंढना आसान नहीं होगा।
यह वास्तव में एक मामला-दर-मामला बात है, मैं कहता हूँ चाहते हैं। कॉच डीबी बस आपके प्रोजेक्ट के आधार पर डेटाबेस का एक प्रकार है, यह एकदम सही फिट हो सकता है या यह दर्दनाक रूप से सीमित हो सकता है - जैसे कि आरडीबीएमएस एकदम सही फिट या दुःस्वप्न हो सकता है।
अधिक जानकारी?
गैर-प्रतिनिधि डीबी के शीर्ष पर दो उत्पादन प्रणालियों को लागू करने के बाद, मैं निष्कर्ष निकाला कि गैर-रिश्तेदार डीबीएस को एसक्यूएल के करीब थोड़ा सा कदम उठाने की ज़रूरत है ताकि वह वास्तव में "वैकल्पिक" हो सके। मैं वैकल्पिक रूप से समझता हूं "गुणवत्ता, प्रयास या लागत में भारी अंतर के बिना आपको समान कार्यक्षमता मिलती है।"
संक्षिप्त उत्तर: अक्सर
लंबा उत्तर। गैर रिलेशनल डेटाबेस के लिए मुख्य लाभ उच्च उपलब्धता, स्कीमेलेस और स्केलेबिलिटी है। यह सब महत्वपूर्ण मूल्य के साथ आता है। आपके आवेदन क्वेरी लचीलापन (और/या, सॉर्ट क्रम, ..) की जरूरत है और doest बड़े डेटा या प्रदर्शन की आवश्यकताओं को आप mysql या बेहतर postgres जैसे परंपरागत डीबी साथ बेहतर कर रहे हैं है। गैर संबंधपरक डेटाबेस के साथ मुख्य चुनौती यह है कि यदि आप डेटा गठबंधन करने के लिए नया तरीका की जरूरत है (सभी पोस्ट समय क्रम में उपयोगकर्ता द्वारा पसंद की तरह) आप सम्मिलित करना और देखने नया दस्तावेज़ क्वेरी को लागू करने की आवश्यकता होगी है। कॉचडब दस्तावेज़ आधारित है जो लचीलापन के लिए अच्छा है, क्योंकि आपको डेटाबेस में स्कीमा को बनाए रखने की आवश्यकता नहीं है और नए फ़ील्ड को खोने वाले पुराने डेटा को "भूल" सकता है। दस्तावेज़ डेटाबेस स्थिर रूप से टाइप की गई भाषाओं के साथ पूर्ण क्षमता तक नहीं रहते हैं, हालांकि आपको अपने कोड में डेटा संरचना को कम या कम करना है।
गैर रिलेशनल डाटाबेस धक्का वास्तुकला की आवश्यकता है। जब आप डेटा डालें या अपडेट करते हैं तो सभी संभावित प्रश्नों (यहां तक कि दुर्लभ व्यवस्थापक वाले) के लिए सभी डेटा धक्का देने की आवश्यकता होती है। यह सीपीयू और डिस्क के रूप में लागत है लेकिन आपको तेजी से प्रश्न मिलते हैं। एसक्यूएल आधारित डीबी में आप केवल पंक्ति डाल सकते हैं और धीमी क्वेरी के रूप में कीमत का भुगतान कर सकते हैं। कॉच डीबी पहली क्वेरी पर इंडेक्स बनाता है, डालने पर कुछ अन्य डेटाबेस (मोंगोडीबी, Google ऐप इंजन)
कॉचडब क्वेरी को जावास्क्रिप्ट विचारों के रूप में परिभाषित किया गया है जो शक्तिशाली हैं लेकिन लिखना, बनाए रखना और डीबग करना बहुत मुश्किल है। देखें परिवर्तन का मतलब है कि CouchDB सभी दस्तावेजों वास्तव में धीमी है अगर आप दस लाख या उससे अधिक दस्तावेजों पुन: अनुक्रमणिका की जरूरत है। Couchdb से त्रुटि संदेश सामान्य व्यवस्थापक द्वारा समझ नहीं किया जा सकता है।
CouchDB देखभाल कॉम्पैक्ट डाटाफाइलों और अनुक्रमित करने के लिए कुछ मैनुअल प्रयास की जरूरत है, नए संस्करण से स्वचालित संघनन हालांकि है, लेकिन इसे का उपयोग कुछ देखभाल की आवश्यकता है।कॉम्पैक्शन को ऑफ-पीक आदि निर्धारित करने की आवश्यकता है .. हालांकि यह काफी आसानी से लिपि जा सकता है। डीबी डंप, बैकअप और ऐसे उपकरण अभी भी बहुत शिशु हैं।
संक्षेप में, यदि आप कोचडब के प्रदर्शन या स्केलेबिलिटी की आवश्यकता नहीं है तो यह प्रयास के लायक नहीं है। व्यक्तिगत रूप से मुझे लगता है कि एसक्यूएल डीबी, रेडिस और मेमकैच स्टैक के साथ अधिकांश गैर रिलेशनल डीबी प्रदर्शन लाभों को "अनुकरण" करना संभव है। कम से कम जब तक बहुत अधिक डेटा नहीं है।