2010-08-02 13 views
49

कौन सा परिदृश्य अधिक समझ में आता है - मोंगोडीबी के साथ कई ईसी 2 उदाहरणों को होस्ट करें, या अमेज़ॅन सरल डीबी webservice का उपयोग करें?ईसी 2 सर्वर या एडब्ल्यूएस SimpleDB पर MongoDB?

जब मोंगोडीबी के साथ कई ईसी 2 उदाहरण हैं तो मुझे अपने आप को इंस्टेंस सेट करने की समस्या है।

सरल डीबी का उपयोग करते समय मुझे मुझे अमेज़ॅन डेटा संरचना में लॉक करने की समस्या है?

विकास के अनुसार क्या अंतर हैं? क्या मुझे मोंगोडीबी या एडब्ल्यूएस सिंपल डीबी को लिखने के लिए, मेरी सेवा परतों के डीएओ को स्विच करने में सक्षम नहीं होना चाहिए?

उत्तर

58

सरल डीबी में कुछ स्केलेबिलिटी सीमाएं हैं। आप केवल शेर्डिंग द्वारा स्केल कर सकते हैं और इसमें मोंगोडब या कैसंड्रा की तुलना में अधिक विलंबता है, इसकी एक थ्रूपुट सीमा है और इसकी कीमत अन्य विकल्पों की तुलना में अधिक है। स्केलेबिलिटी मैनुअल है (आपको शेड करना होगा)।

यदि आपको व्यापक क्वेरी विकल्प की आवश्यकता है और आपके पास उच्च पढ़ने की दर है और आपके पास इतना डेटा नहीं है तो mongodb बेहतर है। लेकिन स्थायित्व के लिए, आपको मास्टर/गुलाम के रूप में कम से कम 2 mongodb सर्वर उदाहरणों का उपयोग करने की आवश्यकता है। अन्यथा आप अपने डेटा के अंतिम मिनट को खो सकते हैं। स्केलेबिलिटी मैनुअल है। यह सरलीब से बहुत तेज है। Autosharding 1.6 संस्करण में लागू किया गया है।

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

एक और विकल्प बड़े डेटा के लिए हैडऑप है, लेकिन यह अन्य लोगों के रूप में रीयलटाइम नहीं है, आप डेटावेयरिंग के लिए हैडोप का उपयोग कर सकते हैं। न तो कैसंड्रा या मोंगो के पास लेन-देन होते हैं, इसलिए यदि आपको लेन-देन की आवश्यकता है तो पोस्टग्रेस्क्ल एक बेहतर फिट है। एक और विकल्प अमेज़ॅन आरडीएस है, लेकिन इसका प्रदर्शन खराब है और कीमत अधिक है। यदि आप डेटाबेस या सरलीब का उपयोग करना चाहते हैं तो आपको डेटा कैशिंग की आवश्यकता भी हो सकती है (उदाहरण: memcached)।

वेब ऐप्स के लिए, यदि आपका डेटा छोटा है तो मैं मोन्गो की सलाह देता हूं, अगर यह बड़ा कैसंड्रा बेहतर है। आपको मोंगो या कैसंद्रा के साथ कैशिंग परत की आवश्यकता नहीं है, वे पहले से ही तेज हैं। मैं सरलीब की अनुशंसा नहीं करता, यह आपको अमेज़ॅन के लिए भी ताला लगा देता है जैसा आपने कहा था।

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

+2

"लेकिन स्थायित्व के लिए, आपको कम से कम 2 mongodb सर्वर उदाहरणों को मास्टर/गुलाम के रूप में उपयोग करने की आवश्यकता है। अन्यथा आप अपने डेटा का अंतिम मिनट खो सकते हैं।" MongoDB 1.8 के बाद एकल सर्वर स्थायित्व का समर्थन करता है – dan

21

मुझे लगता है कि आपके पास समय और गति दोनों का सवाल है।

मोंगोडीबी/कैसंद्रा बहुत तेजी से होने जा रहे हैं, लेकिन आपको उन्हें जाने के लिए $$$ निवेश करना होगा।इसका मतलब है कि आपको उन सभी के लिए सर्वर इंस्टेंस चलाने/सेटअप करने की आवश्यकता होगी और पता लगाएं कि वे कैसे काम करते हैं।

दूसरी ओर, आपको सीधे "प्रति लेनदेन" लागत प्रति व्यक्ति नहीं है, आप केवल हार्डवेयर के लिए भुगतान करते हैं जो अधिकतर सेवाओं के लिए अधिक कुशल है।

कैसंड्रा/मोंगोडीबी लड़ाई में आपको जो मिल जाएगा वह मिलेगा (परीक्षण के आधार पर मैं पिछले कुछ दिनों में व्यक्तिगत रूप से शामिल हूं)।

कैसेंड्रा:

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

MongoDB:

  • विन्यास अपेक्षाकृत आसान है (यहां तक ​​कि नई sharding के लिए, इस सप्ताह)
  • अतिरिक्तता अभी भी "वहाँ हो रही है"
  • मानचित्र-कम करने में निर्मित है और यह है डेटा प्राप्त करना आसान है।

ईमानदारी से, हमारे 10 जीबी डेटा के लिए कॉन्फ़िगरेशन समय आवश्यक है, हम अपने अंत में मोंगोडीबी के साथ गए। मैं "इन चलने वाले" मामलों के लिए SimpleDB का उपयोग करके कल्पना कर सकता हूं। लेकिन मोंगोडीबी चलाने के लिए नोड को कॉन्फ़िगर करना इतना हास्यास्पद रूप से सरल है कि "सरल डीबी" मार्ग को छोड़ने के लायक हो सकते हैं।

डीएओ के संदर्भ में, मोंगो के लिए पहले से ही कई पुस्तकालय हैं। कैसंद्रा के लिए बहाव ढांचा अच्छी तरह से समर्थित है। आप शायद दूर दूर कनेक्शन के लिए कुछ सरल तर्क लिख सकते हैं। लेकिन सरल सीआरयूडी की तुलना में चीजों को अधिक जटिल बनाना मुश्किल होगा।

1

अब 5 साल बाद किसी भी ओएस पर मोंगो सेट करना मुश्किल नहीं है। Documentation का पालन करना आसान है, इसलिए मुझे एक समस्या के रूप में मोंगो सेट अप नहीं दिख रहा है। अन्य उत्तरों ने स्केलेबिलिटी के सवालों को संबोधित किया, इसलिए मैं डेवलपर के दृष्टिकोण से प्रत्येक प्रश्न को संबोधित करने की कोशिश करूंगा (प्रत्येक सिस्टम में कौन सी सीमाएं हैं):

मैं एसडी के लिए सरल डीबी और एम के लिए एम का उपयोग करूंगा।

  • एम सी ++ में लिखा है, एस Erlang (नहीं सबसे तेजी से भाषा)
  • एम खुला स्रोत, हर जगह स्थापित है में लिखा है, एस स्वामित्व है, केवल अमेज़न एडब्ल्यूएस पर चला सकते हैं। आपको pay for a whole bunch of staff एस
  • एस के लिए strange limitations का पूरा समूह होना चाहिए। एम limitations रास्ता अधिक उचित हैं।सबसे अजीब सीमाएँ हैं:
    • डोमेन (टेबल) का अधिकतम आकार 10 जीबी
    • विशेषता मान लंबाई (मैदान के आकार) 1024 बाइट
    • प्रतिक्रिया का चयन में अधिकतम मद है - 2500
    • अधिकतम प्रतिक्रिया चयन के लिए आकार (डेटा एस की अधिकतम राशि जो आप लौट सकते हैं) - 1 एमबी
  • एस supports only a few languages (जावा, php, अजगर, रूबी, .net) एम supports way more
  • दोनों समर्थन REST
  • एस में एक क्वेरी वाक्यविन्यास है जो SQL (लेकिन कम शक्तिशाली) के समान है। एम के साथ आपको एक नया वाक्यविन्यास सीखना होगा जो जेसन की तरह दिखता है (यह मूल बातें सीखने के लिए सीधे आगे है)
  • एम के साथ आपको सीखना होगा कि आप अपने डेटाबेस को कैसे आर्किटेक्ट करते हैं। क्योंकि बहुत से लोग सोचते हैं कि स्कीमलेस का मतलब है कि आप डेटाबेस में किसी भी जंक फेंक सकते हैं और इसे आसानी से निकाल सकते हैं, वे आश्चर्यचकित हो सकते हैं कि जंक इन, जंक इन अधिकतम काम करता है। मुझे लगता है कि वही एस में है, लेकिन निश्चित रूप से इसका दावा नहीं कर सकता।
  • दोनों मामले असंवेदनशील खोज की अनुमति नहीं देते हैं। एम में आप रेगेक्स का उपयोग किसी भी तरह (बदसूरत/कोई इंडेक्स) के लिए अतिरिक्त लोअरकेस फ़ील्ड/एप्लिकेशन लॉजिक को पेश किए बिना इस सीमा को पार कर सकते हैं।
  • एस सॉर्टिंग में केवल on one field
  • 5s timelimit count in S can behave strange की वजह से किया जा सकता है। यदि 5 सेकंड बीत चुके हैं और क्वेरी समाप्त नहीं हुई है, तो आप आंशिक संख्या और एक टोकन के साथ समाप्त होते हैं जो आपको क्वेरी जारी रखने की अनुमति देता है। इस तर्क को एकत्रित करने के लिए एप्लिकेशन तर्क ज़िम्मेदार है।
  • everything is a UTF-8 string, जो एस एम प्रकार समर्थन में गैर स्ट्रिंग मानों (जैसे संख्याओं, तिथियों) के साथ काम करने के लिए गधे में दर्द बनाता है way richer है।
  • दोनों में लेनदेन नहीं है और
  • एम compression का समर्थन करता है जो वास्तव में नोस्कल स्टोर्स के लिए सहायक है, जहां एक ही फ़ील्ड नाम फिर से संग्रहीत किया जाता है।
  • एस केवल एक ही इंडेक्स का समर्थन करता है, एम has single, compound, multi-key, geospatial etc
  • दोनों समर्थन प्रतिकृति और sharding

सबसे महत्वपूर्ण चीजें आप पर विचार करना चाहिए यह है कि SimpleDB एक बहुत ही मौलिक क्वेरी भाषा है। group by, sumaverage, distinct के साथ-साथ डेटा मैनिपुलेशन भी समर्थित नहीं है, इसलिए कार्यक्षमता रेडिस/मेमकैड की तुलना में वास्तव में समृद्ध नहीं है। दूसरी ओर मोंगो एक समृद्ध क्वेरी भाषा का समर्थन करता है।

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