2012-12-20 18 views
55

मैं एक मेले के लिए MySQL का उपयोग कर रहे हैं, जबकि अब और मैं इसकी संरचना & एसक्यूएल प्रश्नों आदि के साथ आराम कर रहा हूँएडब्ल्यूएस MySQL आरडीएस बनाम एडब्ल्यूएस DynamoDB

वर्तमान में एडब्ल्यूएस में एक नई प्रणाली के निर्माण और मैं देख रहा है डायनेमो डीबी पर। वर्तमान में मुझे केवल इसके बारे में कुछ पता है।

क्या कोई दूसरा बेहतर है?

डायनेमो डीबी का क्या फायदा है?

MySQL क्वेरी आदि से इस फ्लैट शैली डीबी में संक्रमण क्या है?

उत्तर

32

आप here के बारे में एडब्ल्यूएस स्पष्टीकरण पढ़ सकते हैं।

संक्षेप में, यदि आपके पास मुख्य रूप से लुकअप क्वेरी (और प्रश्नों में शामिल नहीं है), डायनेमो डीबी (और अन्य नोएसक्यूएल डीबी) बेहतर है। यदि आपको को बहुत से डेटा को संभालने की आवश्यकता है, तो आप MySQL (और अन्य RDBMS) का उपयोग करते समय सीमित रहेंगे।

आप अपने MySQL क्वेरी और न ही आपके डेटा स्कीमा का पुन: उपयोग नहीं कर सकते हैं, लेकिन यदि आप NoSQL सीखने के प्रयास को खर्च करते हैं, तो आप अपने टूल बॉक्स में एक महत्वपूर्ण टूल जोड़ देंगे। ऐसे कई मामले हैं जहां डायनेमोडीबी सबसे सरल समाधान दे रहा है।

138

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

यदि, उदाहरण के लिए, आप डेटा संग्रहित कर रहे हैं जो खुद को एक रिलेशनल स्कीमा (वृक्ष संरचनाएं, स्कीमा-कम JSON प्रस्तुतियों, आदि) को अच्छी तरह से उधार नहीं देता है जिसे एक कुंजी या कुंजी/श्रेणी के विरुद्ध देखा जा सकता है संयोजन तब डायनेमो डीबी (या कुछ अन्य नोएसक्यूएल स्टोर) आपकी सबसे अच्छी शर्त होगी।

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

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

आरडीएस के पास बुनियादी ढांचे के बारे में चिंता न करने का बहुत अधिक लाभ है, हालांकि यदि आप उस बिंदु पर महत्वपूर्ण संख्या में लिखने की आवश्यकता रखते हैं जहां सबसे बड़ा उदाहरण आकार अब नहीं रहेगा, तो आप विकल्पों के बिना बाएं प्रकार (आप पढ़ने प्रतिकृतियों का उपयोग कर पढ़ने के लिए क्षैतिज पैमाने पर स्केल कर सकते हैं)।

अपडेटेड नोट: डायनेमो डीबी अब वैश्विक माध्यमिक अनुक्रमण का समर्थन करता है, इसलिए अब हैश और रेंज कुंजियों के संयोजन या हैश के अलावा डेटा फ़ील्ड पर अनुकूलित लुकअप करने की क्षमता है।

+6

यदि मैं 100 से अपना उत्तर बढ़ा सकता हूं, तो मैं चाहता हूं। – Salil

+0

आपके पास लगभग 100 अपवॉट्स की आपकी इच्छा है :) – Luke

+0

आपको यह मिला! 100. –

6

डायनेमोडीबी का उपयोग करते समय आपको यह भी पता होना चाहिए कि डायनेमोडीबी में आइटम/रिकॉर्ड 400KB तक सीमित हैं (DynamoDB Limits देखें)। कई उपयोग मामलों के लिए यह काम नहीं करेगा। तो डायनेमो डीबी कुछ चीजों के लिए अच्छा होगा लेकिन सभी नहीं। अन्य कई NoSQL डेटाबेस के लिए भी चला जाता है।

89

हमने आरडीएस माईएसक्यूएल में हमारी सभी डायनेमोडीबी टेबलों को माइग्रेट कर दिया है।

विशिष्ट कार्यों के लिए डायनेमो डीबी का उपयोग करते समय, समझदारी हो सकती है, डायनेमो डीबी के शीर्ष पर एक नई प्रणाली बनाना वास्तव में एक बुरा विचार है। सर्वोत्तम रखी योजनाएं आदि, आपको हमेशा अपने डीबी से अतिरिक्त लचीलापन की आवश्यकता होती है।

यहाँ हमारे कारणों से हम DynamoDB से चले गए हैं:

  1. अनुक्रमण - बदलने या जोड़ने कुंजी ऑन-द-मक्खी एक नई तालिका बनाने के बिना असंभव है।
  2. क्वेरीज़ - क्वेरी डेटा बहुत सीमित है। विशेष रूप से यदि आप गैर अनुक्रमित डेटा से पूछना चाहते हैं। जॉइन निश्चित रूप से असंभव हैं इसलिए आपको अपने कोड/कैश परत पर जटिल डेटा संबंधों का प्रबंधन करना होगा।
  3. बैकअप - इस तरह की एक थकाऊ बैकअप प्रक्रिया आरडीएस
  4. GUI - खराब यूएक्स, सीमित खोज, कोई मजेदार नहीं है, की धीमी बैकअप की तुलना में एक निराशाजनक आश्चर्य है।
  5. गति - प्रतिक्रिया समय आरडीएस की तुलना में समस्याग्रस्त है। आप खुद को आरडीएस के आंतरिक कैशिंग के लिए बसने वाले स्थानों में क्षतिपूर्ति के लिए विस्तृत कैशिंग तंत्र का निर्माण करते हैं।
  6. डेटा इंटीग्रटी - तरल डेटा संरचना की अवधारणा के साथ शुरू करने के लिए अच्छा लगता है, आपका कुछ डेटा "पत्थर में सेट" बेहतर है। मजबूत टाइपिंग एक आशीर्वाद है जब एक छोटी सी बग आपके डेटाबेस को नष्ट करने का प्रयास करती है। डायनेमो डीबी के साथ कुछ भी संभव है और वास्तव में कुछ भी गलत हो सकता है।

अब हम कुछ सिस्टम के लिए बैकअप के रूप में डायनेमोडीबी का उपयोग करते हैं और मुझे यकीन है कि हम इसे भविष्य में विशिष्ट, अच्छी तरह से परिभाषित कार्यों के लिए उपयोग करेंगे। यह एक खराब डीबी नहीं है, यह सिर्फ आपके मूल प्रणाली का 100% सेवा करने के लिए डीबी नहीं है।

जहां तक ​​फायदे जाते हैं, मैं स्केलेबिलिटी और स्थायित्व कहूंगा। यह अविश्वसनीय रूप से और पारदर्शी पैमाने पर है और यह हमेशा (तरह) है। ये वास्तव में महान विशेषताएं हैं, लेकिन वे नकारात्मक पक्षों के लिए किसी भी तरह से क्षतिपूर्ति नहीं करते हैं।

+0

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

+4

बहुत विशिष्ट पेशेवर/विपक्ष। महान उत्तर – stevendesu

+5

इनमें से कुछ पुराना है। उदाहरण के लिए, 1 अब सत्य नहीं है। – mbroshi

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