कम्प्यूटेशनल और/या स्टोरेज स्केल के मामले में स्थानिक पैमाने (1000+ डिवाइस) को आपको गुमराह न करने दें। प्रति सेकंड कुछ दर्जन 35-बाइट इंसर्ट किसी भी मुख्यधारा के डीबीएमएस के लिए एक मामूली काम का बोझ है, यहां तक कि लो-एंड हार्डवेयर पर भी चल रहा है। इसी तरह, प्रति माह 142 मिलियन रिकॉर्ड केवल 1~10 गीगाबाइट प्रति माह भंडारण के क्रम में है, बिना किसी संपीड़न के, जिसमें सूचकांक शामिल हैं।
अपने प्रश्न टिप्पणी में, आपने कहा:
<ब्लॉकक्वॉट>"यह सब विश्वसनीयता, मापनीयता और गति के बारे में है। यह बहुत महत्वपूर्ण है कि समाधान आसानी से (MongoDB ऑटोशर्डिंग?) अधिक नोड्स में फेंक रहा है, और गति भी बहुत महत्वपूर्ण है
विश्वसनीयता? कोई भी मुख्यधारा डीबीएमएस इसकी गारंटी दे सकता है (मान लीजिए कि आपका मतलब है कि यह आपके डेटा को दूषित नहीं करेगा, और यह क्रैश नहीं होने वाला है - इस उत्तर के नीचे सीएपी प्रमेय की मेरी चर्चा देखें)। रफ़्तार? यहां तक कि एक मशीन के साथ भी, इस कार्यभार का 10 ~ 100 गुना कोई समस्या नहीं होनी चाहिए। मापनीयता? वर्तमान दर पर, एक पूरे वर्ष का डेटा, असम्पीडित, यहां तक कि पूरी तरह से अनुक्रमित, आसानी से 100 गीगाबाइट डिस्क स्थान के भीतर फिट हो जाएगा (इसी तरह, हमने पहले ही स्थापित कर दिया है कि डालने की दर कोई समस्या नहीं है)।
जैसे, मुझे नोएसक्यूएल, या यहां तक कि एक वितरित डेटाबेस जैसे विदेशी समाधान की कोई स्पष्ट आवश्यकता नहीं दिख रही है - एक सादा, पुराना रिलेशनल डेटाबेस जैसे कि MySQL ठीक होगा। यदि आप विफलता के बारे में चिंतित हैं, तो बस एक बैकअप सर्वर को मास्टर-स्लेव कॉन्फ़िगरेशन में सेटअप करें। यदि हम वर्तमान पैमाने के 100 या 1000 गुना बार बात कर रहे हैं, तो डेटा एकत्र करने वाले उपकरण की आईडी के आधार पर कुछ उदाहरणों को क्षैतिज रूप से विभाजित करें (अर्थात {विभाजन अनुक्रमणिका} ={डिवाइस आईडी} मॉड्यूल {विभाजन की संख्या})।
ध्यान रखें कि संबंधपरक डेटाबेस की दुनिया की सुरक्षित और आरामदायक सीमाओं को छोड़ने का अर्थ है अपने प्रतिनिधित्व मॉडल दोनों को छोड़ना और इसके समृद्ध टूलसेट . यह आपकी "जटिल डेटामाइनिंग" को और अधिक कठिन बना देगा--आपको केवल डेटाबेस में डेटा डालने की आवश्यकता नहीं है, आपको इसे बाहर निकालने की भी आवश्यकता है।
यह सब कहा जा रहा है, MongoDB और CouchDB तैनात करने और साथ काम करने के लिए असामान्य रूप से सरल हैं। वे बहुत मज़ेदार भी हैं, और आपको किसी भी संख्या में लोगों के लिए अधिक आकर्षक बना देंगे (न केवल प्रोग्रामर--कार्यकारी भी!)।
सामान्य ज्ञान यह है कि, आपके द्वारा सुझाए गए तीन नोएसक्यूएल समाधानों में से, कैसेंड्रा उच्च सम्मिलित मात्रा के लिए सबसे अच्छा है (बेशक, अपेक्षाकृत बोलते हुए, मुझे नहीं लगता कि आपके पास है उच्च सम्मिलित मात्रा--इसे Facebook . द्वारा उपयोग करने के लिए डिज़ाइन किया गया था ); इसके साथ काम करना अधिक कठिन होने के कारण इसका मुकाबला किया जाता है। इसलिए जब तक आपके पास कुछ अजीब आवश्यकताएं नहीं हैं जिनका आपने उल्लेख नहीं किया है, तो मैं आपके उपयोग के मामले में इसके खिलाफ अनुशंसा करता हूं।
यदि आप सकारात्मक रूप से NoSQL परिनियोजन पर सेट हैं, तो आप CAP प्रमेय पर विचार कर सकते हैं। यह आपको MongoDB और CouchDB के बीच निर्णय लेने में मदद करेगा। यहाँ एक अच्छा लिंक है:http://blog.nahurst.com/visual-guide-to-nosql-systems। "विश्वसनीयता" से आपका क्या मतलब है, यह सब नीचे आता है:मोंगोडीबी स्थिरता के लिए उपलब्धता व्यापार करता है, जबकि कॉच डीबी उपलब्धता के लिए स्थिरता व्यापार करता है . (कैसंड्रा आपको इस ट्रेडऑफ़ को, प्रति क्वेरी, यह निर्दिष्ट करके कि कितने सर्वरों को लिखने/पढ़ने के लिए लिखने/पढ़ने के लिए सफल होने के लिए अनुमति देता है; अद्यतन:अब, BigCouch के साथ CouchDB भी कर सकते हैं! बहुत रोमांचक...)
आपके प्रोजेक्ट के लिए शुभकामनाएँ।
