मेरे पास रेडिस और मोंगोडीबी के साथ अनुभव है, लेकिन आपके उपयोग के मामले में या तो अनुशंसा नहीं करेगा। रेडिस हर मामले में कमाल है, लेकिन चूंकि यह केवल रैम है और इसमें कोई क्लस्टरिंग विशेषताएं नहीं हैं (फिर भी, वे विकास में हैं), यह बहुत अच्छी तरह से स्केल नहीं करता है। MongoDB मैं कभी भी किसी ऐसी चीज़ के लिए फिर से उपयोग नहीं करूँगा जिसके लिए एक छोटे प्रतिकृति सेट के अलावा किसी चीज़ की आवश्यकता हो।
मूल रूप से, MongoDB अपरिपक्व है और किसी भी प्रकार की उच्च मात्रा, उच्च प्रदर्शन आवश्यकताओं के लिए पूरी तरह से अनुपयुक्त है। इसमें एक वैश्विक राइट लॉक है जो डिस्क फ्लश के दौरान आयोजित किया जाता है, जिसका अर्थ है कि प्रदर्शन आपके द्वारा किए जाने के आधार पर बेतहाशा भिन्न हो सकता है। व्यवहार में यह अद्यतन बनाता है जो दस्तावेज़ों को असंभव बना देता है, और आपको हटाए जाने के साथ भी बहुत सावधान रहने की आवश्यकता है। डिलीट की बात करें तो, वे डेटाबेस को गंभीर रूप से खंडित करते हैं, इसलिए यदि आप बहुत सारे डिलीट करते हैं तो आपके प्रदर्शन को नुकसान होने वाला है।
1.8.0 से 1.8.1 में साझा करना एक आपदा थी। पूर्ण शो स्टॉपर बग थे जिन्हें इसे स्थिर रिलीज में कभी नहीं बनाना चाहिए था। कॉन्फ़िगरेशन को ठीक से फ़्लश नहीं किया गया था और आपके डेटाबेस को खराब स्थिति में लाना बहुत आसान था ताकि चंक्स प्राथमिक शार्ड से कभी न हटें। 1.8.2 उनमें से अधिकांश को हल करता है और अधिक स्थिर लगता है, लेकिन मुझे एक बिट के कार्यान्वयन पर भरोसा नहीं है। इसमें जोड़ें कि जब सब कुछ काम करता है तब भी शार्प करना कठिन होता है, प्राकृतिक शार्ड कुंजी का चयन करना हमेशा आसान नहीं होता है, और यदि आप शार्डिंग नहीं करते हैं तो आपको बहुत दुख होगा।
MongoDB के साथ काम करना वास्तव में आसान है और फीचर सेट वास्तव में अच्छा है। प्रलेखन, ड्राइवर और समुदाय सभी महान हैं। MongoDB MySQL के प्रतिस्थापन के रूप में सुपर काम करता है, लेकिन इसे किसी भी चीज़ के लिए उपयोग न करें जिसे स्केल करने की आवश्यकता है।
हम वर्तमान में कैसेंड्रा में जाने पर विचार कर रहे हैं। मुझे डायनेमो मॉडल (उदाहरण के लिए कोई मास्टर नोड्स नहीं; कहीं भी लिखना और पढ़ना; क्लस्टर को विकसित करने के लिए बस नोड्स जोड़ें) सम्मोहक लगता है और सुविधाएँ हमारे लिए कमोबेश सही हैं। डेटा मॉडल MongoDB की तरह ही कम स्कीमा है, हालांकि थोड़ा अधिक सीमित (आप मूल रूप से एक या दो स्तर के हैश के बीच चयन कर सकते हैं)। मुझे यकीन है कि एक बार जब आप इसमें शामिल हो जाते हैं तो समुदाय अच्छा होता है, लेकिन अभी तक मुझे सामान्य समस्याओं को हल करने के तरीके के बारे में अच्छी जानकारी प्राप्त करना मुश्किल लगता है, और दस्तावेज़ीकरण की कमी है। ब्लॉग पर आपको मिलने वाली अधिकांश जानकारी एक वर्ष पुरानी है, और तब से बहुत सी चीजें हुई हैं (0.7 और 0.8 दोनों वास्तव में महत्वपूर्ण अपडेट प्रतीत होते हैं, लेकिन अधिकांश चीजें जो आपको मिलती हैं वे लगभग 0.6 हैं)। ड्राइवर भी बहुत परिपक्व या अच्छी तरह से प्रलेखित नहीं हैं, जो मैंने अब तक देखा है, और हर कोई इस बारे में विवाद कर रहा है कि क्या थ्रिफ्ट, एवरो या सीक्यूएल का उपयोग किया जाना चाहिए (और यह 0.6 से 0.7 से 0.8 में बदल गया है) .
रियाक दिलचस्प है, कैसेंड्रा के समान कारणों के लिए, लेकिन हमारे लिए एक शुद्ध कुंजी-मूल्य-स्टोर पर्याप्त नहीं है, हमें पहले पढ़ने के बिना अपडेट करने में सक्षम होना चाहिए। Riak के साथ यह संभव नहीं है क्योंकि मान केवल बूँदें हैं। हालांकि ऐसा लगता है कि यह आपके लिए कोई समस्या नहीं होगी।
HBase एक और दावेदार है। यह कई अलग-अलग टुकड़ों, ज़ूकीपर, एचडीएफएस, आदि के कारण स्थापित करने और चलाने के लिए एक दर्द जैसा लगता है। लेकिन डेटा मॉडल कैसेंड्रा (स्तंभ, यानी एक स्तर हैश) के समान है, जो हमारे लिए अच्छा काम करता है, लेकिन हो सकता है आपके लिए महत्वपूर्ण। यह आजमाया हुआ और सच लगता है, लेकिन जैसा कि MongoDB के साथ होता है, आपको शार्पिंग मुद्दों पर ध्यान देना होगा, आपको अपनी चाबियों में कुछ विचार करना चाहिए या आप परेशानी में पड़ सकते हैं।
कॉच डीबी, प्रोजेक्ट वोल्डेमॉर्ट और अनगिनत अन्य संभावित विकल्प भी हैं। मुझे लगता है कि यदि आप "अत्यंत उच्च मात्रा में डेटा" के बारे में गंभीर हैं तो यह कैसेंड्रा, रियाक और एचबीएएस के बीच है। अगर शुद्ध कुंजी-मूल्य-भंडारण पर्याप्त नहीं है तो स्ट्राइक Riak। "पूरी तरह से लगातार प्रतिकृति" से आपका क्या मतलब है, इसके आधार पर कैसंड्रा और रियाक बाहर हैं, क्योंकि एक बासी मूल्य को पढ़ने की संभावना (जरूरी नहीं कि बड़ी और ट्यून करने योग्य) हो।
अंत में आपको स्पष्ट रूप से इसे अपने विशेष उपयोग के मामले में आज़माना होगा, इसलिए आपको वास्तव में इस उत्तर से घर ले जाना चाहिए:MongoDB से परेशान न हों।
