जुकीपर/चब्बी-वीएस- माईएसक्ल एनडीबी

Question

मैं हाल ही में पक्सोस पेपर, एफएलपी प्रमेय इत्यादि पढ़ रहा हूं और एक परियोजना के लिए अपाचे जुकीपर का मूल्यांकन कर रहा हूं। मैं भी चुबबी (Google की वितरित लॉकिंग सेवा) और ऑनलाइन पर उपलब्ध विभिन्न साहित्य के माध्यम से जा रहा हूं। जुकीपर के लिए मेरा मौलिक उपयोगकेस एक वितरित प्रणाली के लिए प्रतिकृति और सामान्य समन्वय को लागू करना है।

मैं बस सोच रहा था कि, विशिष्ट लाभ क्या है कि ज़ुकीपर या चुबबी वितरित लॉकिंग सिस्टम की तरह तालिका में लाता है। असल में मैं बस सोच रहा हूं कि मैं सिर्फ एक MySQL एनडीबी क्लस्टर का उपयोग क्यों नहीं कर सकता। मैं सुनता रहता हूं कि MySQL में बहुत सारे प्रतिकृति मुद्दे हैं। मैं उम्मीद कर रहा था कि इस विषय पर कुछ और अनुभव के साथ कुछ प्रकाश डाला जा सकता है।

अग्रिम धन्यवाद ..

मेरी आवश्यकताओं के एक साधारण सूची:

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

Answer 1

यह आपके द्वारा प्रबंधित किए जा रहे डेटा के प्रकार और स्केल और गलती सहनशीलता के आधार पर निर्भर करता है।

मैं चिड़ियाघर के दृष्टिकोण से उत्तर दे सकता हूं। शुरू करने से पहले मुझे जिक्र करना चाहिए कि चिड़ियाघर एक गोल-मटोल क्लोन नहीं है। विशेष रूप से यह ताले सीधे नहीं करता है। यह दिमाग में विभिन्न क्रम और प्रदर्शन आवश्यकताओं के साथ भी डिजाइन किया गया है।

चिड़ियाघर में सिस्टम राज्य की पूरी प्रति स्मृति स्मृति निवासी है। परिवर्तनों को संसाधित होने से पहले ज़ूकीपर सर्वर के अधिकांश द्वारा एक परमाणु प्रसारण प्रोटोकॉल का उपयोग करके दोहराया जाता है और डिस्क (एक परिवर्तन पत्रिका का उपयोग करके) में समन्वयित किया जाता है। इस चिड़ियाघर के कारण निर्धारक प्रदर्शन है जो विफलताओं को सहन कर सकता है जब तक कि अधिकांश सर्वर ऊपर नहीं होते हैं। यहां तक ​​कि एक बड़ी आबादी के साथ, जैसे बिजली की विफलता, जब तक कि अधिकांश सर्वर लाइन पर वापस आते हैं, सिस्टम स्थिति संरक्षित की जाएगी। संग्रहीत जानकारी ज़ूकीपर को आमतौर पर सिस्टम की ग्राउंड सच्चाई माना जाता है, इसलिए ऐसी स्थिरता और स्थायित्व गारंटी बहुत महत्वपूर्ण होती है।

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

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

Answer 2

MySQL एक अच्छा सामान्य उद्देश्य समाधान, और संभवत: बहुत महंगा हार्डवेयर पर आपकी प्रदर्शन आवश्यकताओं को आसानी से बनाए रखेगा। यह सभ्य डिस्क के साथ दोहरी क्वाड-कोर बॉक्स पर प्रति सेकंड कई हजार अपडेट आसानी से संभाल सकता है। अंतर्निहित एसिंक्रोनस प्रतिकृति आपको आपकी उपलब्धता आवश्यकताओं के लिए सबसे अधिक रास्ता मिल जाएगी - लेकिन यदि प्राथमिक विफल रहता है तो आप कुछ सेकंड के डेटा खो सकते हैं। इस खोए गए डेटा में से कुछ को पुनर्प्राप्त करने योग्य हो सकता है जब प्राथमिक मरम्मत की जाती है, या आपके एप्लिकेशन लॉग से पुनर्प्राप्त करने योग्य हो सकता है: चाहे आप सहन कर सकें, यह इस बात पर निर्भर है कि आपका सिस्टम कैसे काम करता है। कम हानिकारक - लेकिन धीमी - विकल्प प्राथमिक और विफलता इकाइयों के बीच साझा डिस्क के साथ MySQL Innodb का उपयोग करना है: इस मामले में, विफलता डेटा डिस्क पर ले जाएगा जब प्राथमिक डेटा के नुकसान के साथ विफल रहता है - जब तक प्राथमिक कुछ प्रकार की डिस्क आपदा नहीं थी। यदि साझा डिस्क उपलब्ध नहीं है, तो डीआरबीडी का उपयोग डिस्क ब्लॉक को फ़ेलओवर इकाई में सिंक्रनाइज़ रूप से कॉपी करके अनुकरण करने के लिए किया जा सकता है जैसा कि लिखा गया है: इसका प्रदर्शन पर असर पड़ सकता है।

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

आगे बढ़ना, MySQL एनडीबी का उद्देश्य वसूली के समय को कम करने का इरादा है, और कुछ हद तक बेहतर प्रदर्शन के लिए अपने डेटाबेस को स्केल करने में मदद करता है। हालांकि, माईएसQL एनडीबी की प्रयोज्यता की काफी संकीर्ण सीमा है।सिस्टम एक वितरित डेटाबेस को एक वितरित हैश तालिका पर मैप करता है, और इसलिए जटिल क्वेरी के लिए टेबल में एकाधिक जुड़ने वाले जटिल प्रश्नों के लिए, MySQL घटक और स्टोरेज घटकों (एनडीबी नोड्स) के बीच बहुत अधिक ट्रैफिक होता है जो जटिल प्रश्नों को धीमा कर देते हैं। हालांकि, वास्तव में अच्छी तरह से फिट होने वाले प्रश्न वास्तव में बहुत तेजी से चलते हैं। मैंने इस उत्पाद को कुछ बार देखा है, लेकिन मेरे मौजूदा डेटाबेस अच्छी तरह फिट होने के लिए बहुत जटिल हैं और अच्छे प्रदर्शन के लिए बहुत से डिज़ाइन की आवश्यकता होगी। हालांकि, अगर आप एक नई प्रणाली के डिजाइन चरण में हैं, तो एनडीबी अच्छी तरह से काम करेगा यदि आप अपनी बाधाओं को ध्यान में रखते हुए ध्यान में रख सकते हैं। साथ ही, आपको लगता है कि आपको एक अच्छा एनडीबी समाधान प्रदान करने के लिए कुछ मशीनों की आवश्यकता है: कुछ MySQL नोड्स प्लस 3 या अधिक एनडीबी नोड्स - हालांकि यदि आपकी प्रदर्शन आवश्यकताओं को बहुत चरम नहीं है तो MySQL और NDB नोड्स सह-अस्तित्व में हो सकते हैं।

यहां तक ​​कि MySQL एनडीबी डेटा साइट, व्यवस्थापक त्रुटि इत्यादि पर कुल साइट हानि - आग से निपट नहीं सकता है। इस मामले में, आपको आमतौर पर एक डीआर साइट पर चलने वाली एक और प्रतिकृति धारा की आवश्यकता होती है। यह आमतौर पर असीमित रूप से किया जाएगा ताकि अंतर-साइट लिंक पर कनेक्टिविटी ब्लिप आपके पूरे डेटाबेस को रोक न सके। यह एनडीबी के भौगोलिक प्रतिकृति विकल्प (भुगतान के लिए दूरसंचार संस्करण में) के साथ प्रदान किया जाता है, लेकिन मुझे लगता है कि MySQL 5.1 और ऊपर यह मूल रूप से प्रदान कर सकते हैं।

दुर्भाग्य से, मुझे जुकीपर और चुबबी के बारे में कुछ पता नहीं है। उम्मीद है कि कोई और इन पहलुओं को उठा सकता है।