2009 में इसके निर्माण के बाद से, Redis OSS का एक बहुत जीवंत ओपन सोर्स समुदाय रहा है। इसके आसपास कई टूल्स और यूटिलिटीज विकसित की गई हैं और Dynomite, नॉन-डिस्ट्रीब्यूटेड डेटास्टोर्स के लिए एक पीयर-टू-पीयर जियो-डिस्ट्रीब्यूशन लेयर, उनमें से एक है।
Dynomite को Netflix में इंजीनियरों की एक टीम द्वारा विकसित किया गया था और ओपन सोर्स के रूप में जारी किया गया था। हालांकि इसने विशिष्ट जरूरतों के लिए अच्छे समाधान प्रदान किए हैं, लेकिन पिछले कुछ वर्षों में इसे प्रभावी ढंग से बनाए नहीं रखा गया है। इसके अलावा, Redis OSS के कुछ फंक्शनलिटी, कमांड, और डेटा टाइप्स (जैसे Pub/Sub या Streams) Dynomite के Redis OSS इंस्टेंसेस के वितरण मॉडल द्वारा अनुपलब्ध या सीमित कर दिए गए हैं।
इस कारण से, हम संगठनों को उनके Dynomite डेटाबेस को Redis Enterprise क्लस्टर में माइग्रेट करने में मदद कर रहे हैं।
Dynomite और Redis Enterprise आर्किटेक्चर तुलना
आइए दोनों Dynomite की और Redis Enterprise की आर्किटेक्चर के त्वरित विवरण के साथ अपनी तुलना शुरू करें।
Dynomite
एक सामान्य Dynomite क्लस्टर को इस प्रकार वर्णित किया जा सकता है:
- यह कई डेटा केंद्रों में फैला हुआ है
- एक सिंगल डेटासेंटर रैक का एक समूह है
- एक रैक नोड्स का एक समूह है: प्रत्येक रैक में पूरा डेटासेट होता है, जिसे उस रैक में कई नोड्स में विभाजित किया जाता है
Dynomite एक पीयर-टू-पीयर डिस्ट्रीब्यूशन लेयर है, इसलिए एक क्लाइंट Dynomite क्लस्टर में किसी भी नोड पर राइट ट्रैफिक भेज सकता है। यदि नोड वह है जो डेटा के लिए जिम्मेदार है, तो डेटा उसके लोकल Redis OSS सर्वर प्रोसेस पर लिखा जाता है, फिर क्लस्टर में सभी डेटा केंद्रों में अन्य रैक को असिंक्रोनस रूप से रेप्लिकेट किया जाता है। यदि नोड डेटा का मालिक नहीं है, तो यह एक कोऑर्डिनेटर के रूप में कार्य करता है और उसी रैक में डेटा के मालिक नोड को राइट भेजता है। यह अन्य रैक और DCs में संबंधित नोड्स को राइट्स भी रेप्लिकेट करता है।
Redis Enterprise
एक Redis Enterprise क्लस्टर भी डेटा को विभिन्न Redis इंस्टेंसेस, या शार्ड्स में वितरित करता है, लेकिन दो मुख्य अंतर हैं:
- एक नोड पर एक से अधिक शार्ड हो सकते हैं - लेकिन उच्च उपलब्धता उद्देश्यों के लिए एक प्राइमरी और एक रेप्लिका एक ही नोड पर नहीं रह सकते।
- प्रत्येक प्राइमरी शार्ड के लिए केवल एक रेप्लिका है। क्लाइंट्स प्राइमरी शार्ड्स पर डेटा ऑपरेशन करते हैं। उनकी संबंधित रेप्लिकास प्राइमरी शार्ड्स की विफलता के मामले में उच्च उपलब्धता के लिए मौजूद हैं।
Redis Enterprise क्लस्टर का एक और महत्वपूर्ण हिस्सा जिसे "मैनेजमेंट पथ" कहा जाता है; इसमें एक क्लस्टर मैनेजर, एक प्रॉक्सी, और एक REST API/UI शामिल है। क्लस्टर मैनेजर क्लस्टर को ऑर्केस्ट्रेट करने, डेटाबेस शार्ड्स को उच्च-उपलब्ध नोड्स में रखने, और विफलताओं का पता लगाने के लिए जिम्मेदार है। प्रॉक्सी Redis Enterprise की क्लस्टर टोपोलॉजी को एप्लिकेशन से छुपाता है, क्लस्टर के भीतर प्रत्येक डेटाबेस के लिए एक सिंगल, कभी न बदलने वाला एंडपॉइंट प्रदान करके। यह क्लाइंट कनेक्शन को स्केल करने में भी मदद करता है शार्ड्स के लिए कमांड को मल्टीप्लेक्सिंग और पाइपलाइनिंग करके।
यहां एक सामान्य Redis Enterprise क्लस्टर का चित्रण है:
Redis Enterprise की Active-Active फीचर के साथ, आप एक ग्लोबल डेटाबेस बना सकते हैं जो कई क्लस्टर्स में फैला हो। वे क्लस्टर्स आमतौर पर दुनिया भर के विभिन्न डेटा केंद्रों में रहते हैं। एक एप्लिकेशन जो Active-Active डेटाबेस पर लिखता है, एक लोकल इंस्टेंस एंडपॉइंट से कनेक्ट होता है। एप्लिकेशन द्वारा लोकल इंस्टेंस पर सभी लिखने को मजबूत अंतिम स्थिरता के साथ अन्य सभी इंस्टेंसेस में रेप्लिकेट किया जाता है।
Active-Active रेप्लिकेशन एक जियो-डिस्ट्रीब्यूटेड समाधान के रूप में कई फायदे प्रदान करता है, जिनमें से एक सरल और जटिल Redis Enterprise डेटा टाइप्स के लिए निर्बाध संघर्ष समाधान है, जिस पर हम नीचे चर्चा करेंगे।
अब जब हमें Dynomite और Redis Enterprise की टोपोलॉजी का अंदाजा है, तो आइए देखें कि वे एक संगठन के भीतर डेवलपर्स और DevOps के लिए क्या मायने रखते हैं।
Dynomite या Redis Enterprise: डेवलपर्स के लिए क्या अंतर पड़ता है?
Dynomite को सक्रिय रूप से बनाए नहीं रखे जाने के अलावा, एक संगठन के डेवलपर के दृष्टिकोण से Redis Enterprise में माइग्रेट करने के तीन मुख्य कारण हैं:
- Dynomite का उपयोग करते समय Redis की फंक्शनलिटी सीमित और अधिक जटिल होती है
- Dynomite के पास जियो-डिस्ट्रीब्यूटेड राइट संघर्षों से निपटने का कोई प्रभावी तरीका नहीं है
- Redis से आपको मिलने वाला समर्थन
आइए पहले दो को अधिक विस्तार से देखें।
सीमित और जटिल Redis OSS
जैसा कि आप शायद पहले से ही जानते हैं, Redis OSS एक सादे की-वैल्यू स्टोर के अर्थ में नहीं है, इस अर्थ में कि यह केवल आपको स्ट्रिंग कुंजियों को स्ट्रिंग मानों से जोड़ने की अनुमति नहीं देता है। Redis OSS एक डेटा संरचना सर्वर है जो सूचियों, सेट्स, हैशेज, या स्ट्रीम्स जैसे विभिन्न प्रकार के मानों का समर्थन करता है। हम उन्हें Redis OSS के "कोर डेटा टाइप्स" कहते हैं।
Redis OSS डायनामिक लाइब्रेरीज़ के माध्यम से भी विस्तार योग्य है जिन्हें "मॉड्यूल्स" कहा जाता है। मॉड्यूल्स आपको कोर के अंदर किए जा सकने वाले समान सुविधाओं के साथ नए Redis कमांड को तेजी से लागू करने की अनुमति देते हैं। सबसे लोकप्रिय मॉड्यूल्स में RediSearch शामिल है, जो क्वेरीइंग, सेकेंडरी इंडेक्सिंग, और फुल-टेक्स्ट खोज प्रदान करता है, और RedisJSON, जो Redis OSS को एक शक्तिशाली डॉक्यूमेंट स्टोर में बदल देता है।
जैसा कि परिचय में चर्चा की गई है, Redis OSS के कुछ कमांड और डेटा टाइप्स Dynomite द्वारा अनुपलब्ध या सीमित कर दिए गए हैं। यहां एक गैर-विस्तृत तुलना है:
आप Dynomite के साथ समर्थित और असमर्थित कमांड की पूरी सूची यहां पा सकते हैं।
दूसरी ओर, Redis Enterprise, जिसे Redis OSS के साथ बनाए रखा जाता है, मॉड्यूल्स का उपयोग करके मल्टी-मॉडल ऑपरेशन की अनुमति देता है और कोर Redis OSS डेटा संरचनाओं को पूरी तरह से प्रोग्रामेबल और डिस्ट्रीब्यूटेड तरीके से निष्पादित करने की अनुमति देता है।
संघर्ष समाधान की अनुपस्थिति
Dynomite एक AP सिस्टम है और आपको स्थिरता के लिए तीन विकल्प देता है। आप जो भी विकल्प चुनते हैं, यह जानना महत्वपूर्ण है कि Dynomite असिंक्रोनस राइट संघर्षों को लास्ट राइट विन्स रणनीति लागू करके हल करता है। यह अप्रासंगिक टाइमस्टैम्प के कारण खोए हुए अपडेट का कारण बन सकता है, विशेष रूप से जियो-डिस्ट्रीब्यूटेड राइट्स के संदर्भ में।
दूसरी ओर, Redis Enterprise की Active-Active आर्किटेक्चर Redis OSS कमांड और डेटा टाइप्स के एक वैकल्पिक कार्यान्वयन पर आधारित है जिसे कॉन्फ्लिक्ट-फ्री-रेप्लिकेटेड-डेटा-टाइप्स, या CRDTs कहा जाता है। CRDTs इवेंट ऑर्डरिंग के लिए वेक्टर क्लॉक्स का उपयोग करते हैं। वे सुनिश्चित करते हैं कि जब किन्हीं दो रेप्लिकास को अपडेट का एक ही सेट प्राप्त होता है, तो वे गणितीय रूप से सुसंगत नियमों को अपनाकर एक ही स्थिति तक पहुंचते हैं, जिससे स्थिति अभिसरण की गारंटी होती है। इसके अतिरिक्त, कोई कारणात्मक स्थिरता को भी सक्षम कर सकता है।
इसलिए Redis Enterprise के साथ:
- समवर्ती लिखने का परिणाम अनुमानित है और नियमों के एक सेट पर आधारित है
- एप्लिकेशन को समवर्ती लिखने और राइट संघर्षों के समाधान से परेशान होने की आवश्यकता नहीं है
- डेटासेट अंततः एकल, सुसंगत स्थिति में अभिसरण करेगा
यदि आप इसके लिए तैयार हैं, तो आप इस लिंक का अनुसरण करके लागू किए गए नियमों और संघर्ष समाधान के उदाहरण पा सकते हैं।
Dynomite या Redis Enterprise: DevOps के लिए क्या अंतर पड़ता है?
अब आइए निम्नलिखित विषयों पर चर्चा करके DevOps के दृष्टिकोण से Dynomite और Redis Enterprise की तुलना करें:
- उच्च उपलब्धता
- स्केलेबिलिटी
- तैनाती
उच्च उपलब्धता
जब एक Dynomite रैक के भीतर एक नोड विफल होता है, तो रैक पर लिखना और पढ़ना असंभव हो जाता है। इसका मतलब है कि स्थानीय रूप से लिखने वाले एप्लिकेशन को स्वयं किसी अन्य रैक पर फेलओवर को संभालने की आवश्यकता है। ध्यान दें कि, यदि आपका एप्लिकेशन Java में विकसित है, तो Netflix का Dyno क्लाइंट स्थानीय Dynomite नोड विफल होने पर रिमोट रैक पर फेलओवर को संभाल सकता है।
इसके अलावा, जब नोड वापस आता है, तो विफलता के दौरान रिमोट रैक पर लिखे गए किसी भी डेटा को विफल नोड से गायब कर दिया जाएगा। यदि आप AWS ऑटोस्केलिंग ग्रुप्स के भीतर तैनात करते हैं, तो आप Netflix के Dynomite Manager का उपयोग कर सकते हैं, जो AWS ऑटो-स्केलिंग ग्रुप के भीतर नोड रिप्लेसमेंट और नोड वार्म-अप करता है।
Redis Enterprise की उच्च उपलब्धता के बारे में क्या?
जब एक नोड विफल होता है, तो उस नोड पर रहने वाले सभी प्राइमरी शार्ड्स के लिए एक सिंगल-डिजिट-सेकंड फेलओवर होता है, और उनकी रेप्लिकास को प्राइमरी में प्रमोट किया जाता है। यह ऑटो-फेलओवर तंत्र गारंटी देता है कि डेटा न्यूनतम रुकावट के साथ परोसा जाता है।
इसके आधार पर:
- Redis Enterprise प्रॉक्सी यह सुनिश्चित करता है कि आपके डेटाबेस का सिंगल-एंडपॉइंट, जो फेलओवर के मामले में नहीं बदलेगा, इसलिए आपके एप्लिकेशन के किसी भी पुनर्कॉन्फिगरेशन की आवश्यकता नहीं है।
- एक "replica_ha" विकल्प है जो यह सुनिश्चित करता है कि जब एक रेप्लिका को प्राइमरी में प्रमोट किया जाता है, तो एक नया सिंक किया गया रेप्लिका शार्ड किसी अन्य उपलब्ध नोड पर स्वचालित रूप से बनाया जाता है।
ये तंत्र Redis Enterprise को 99.99% अपटाइम और Active-Active तैनाती के लिए 99.999% अपटाइम की गारंटी देने की अनुमति देते हैं।
स्केलेबिलिटी
Dynomite आपको Redis OSS को स्केल करने की अनुमति देता है जबकि विलंबता के संदर्भ में अच्छा प्रदर्शन बनाए रखता है। आप बेंचमार्क देख सकते हैं लेकिन, यदि आप Dynomite का उपयोग कर रहे हैं, तो आप शायद पहले से ही जानते हैं।
जब स्केलेबिलिटी की बात आती है, तो Dynomite और Redis Enterprise के बीच मुख्य अंतर हैं:
- प्रबंधनीयता
- आउट-ऑफ-द-बॉक्स कनेक्शन प्रबंधन
- संसाधन अनुकूलन
प्रबंधनीयता
यदि आप AWS ऑटोस्केलिंग ग्रुप के भीतर Dynomite Manager का उपयोग नहीं कर रहे हैं, तो एक चल रहे Dynomite रैक में होस्ट जोड़ने के लिए आमतौर पर आवश्यकता होती है:
- Java Dyno क्लाइंट का उपयोग करके "डुअल राइट्स" तकनीक का लाभ उठाना; आपका एप्लिकेशन पुराने/छोटे क्लस्टर के साथ-साथ नए/स्केल्ड क्लस्टर में भी लिखता है। कुछ दिनों के बाद, आप ट्रैफिक को केवल नए क्लस्टर पर रूट करते हैं और इसे सक्रिय बनाते हैं।
- अपने डेटाबेस को पुराने/छोटे क्लस्टर से नए/स्केल्ड क्लस्टर में माइग्रेट करना
दूसरी ओर, Redis Enterprise आपको अनुमति देता है:
- अपने क्लस्टर में नोड्स जोड़े बिना अपने डेटाबेस में शार्ड्स जोड़कर स्केल अप करें: यह परिदृश्य उपयोगी है जब क्लस्टर में पर्याप्त कम उपयोग की गई क्षमता होती है। याद रखें: एक नोड एक Redis इंस्टेंस के बराबर नहीं होता। अपने डेटाबेस को रीशार्डिंग करना Redis Enterprise UI के माध्यम से कुछ क्लिक में किया जा सकता है, या Redis Enterprise के REST API का लाभ उठाकर। यह डाउनटाइम या सेवा रुकावट के बिना किया जाता है। यह एप्लिकेशन के लिए भी पारदर्शी है क्योंकि डेटाबेस का एंडपॉइंट नहीं बदलता।
- क्लस्टर में नोड्स जोड़कर स्केल आउट करें। यह परिदृश्य उपयोगी है यदि आपके डेटाबेस में शार्ड्स जोड़ने के लिए अधिक भौतिक संसाधनों की आवश्यकता है। ध्यान दें कि Redis Enterprise Cloud के साथ, जो हमारा पूरी तरह से प्रबंधित DBaaS ऑफरिंग है, संगठनों को इस चरण के बारे में चिंता करने की आवश्यकता नहीं है। Redis उनके लिए इंफ्रास्ट्रक्चर और संसाधनों को प्रोविजन और प्रबंधित करेगा। इस लेख के तैनाती खंड में अधिक जानकारी देखें।
यहां एक बेंचमार्क है जो Redis ने कुछ साल पहले किया था, जिसमें Redis Enterprise ने 40 AWS इंस्टेंसेस पर सब-मिलीसेकंड विलंबता के साथ 200 मिलियन ऑप्स/सेकंड से अधिक डिलीवर किया था।
कनेक्शन प्रबंधन
जब हम Redis के साथ कनेक्शन प्रबंधन के बारे में बात करते हैं, तो सबसे पहले जो दिमाग में आता है वह है कि Redis क्लाइंट्स, जैसे Jedis या Lettuce, कनेक्शन पूलिंग और पाइपलाइनिंग को कैसे संभालते हैं। Netflix इसका अपवाद नहीं था और अपने Dyno क्लाइंट के लिए इन सुविधाओं को लागू किया।
Redis Enterprise ऐसी सुविधाएं आउट-ऑफ-द-बॉक्स प्रदान करता है। प्रॉक्सी स्वयं क्लस्टर में शार्ड्स के लिए स्थायी कनेक्शन स्थापित करता है, और उन कनेक्शन्स को क्लाइंट्स द्वारा साझा किया जाता है। यह Redis की तरफ मल्टीप्लेक्सिंग और पाइपलाइनिंग करके, शार्ड्स पर कई स्थायी कनेक्शन पर अनुरोधों को शेड्यूल करके प्रदर्शन अनुकूलन भी लागू करता है।
साथ ही, प्रॉक्सी मल्टी-थ्रेडेड है और क्लाइंट कनेक्शन में विस्फोट को संभालने के लिए स्वचालित रूप से स्केल करेगा।
संसाधन अनुकूलन
सबसे पहले, याद रखें कि Redis Enterprise क्लस्टर के भीतर एक मशीन एक Redis इंस्टेंस के बराबर नहीं होती और प्रत्येक प्राइमरी शार्ड में केवल एक रेप्लिका तक हो सकता है।
दूसरे, Redis Enterprise मल्टी-टेनेंट है। इसका मतलब है कि एक सिंगल Redis Enterprise क्लस्टर सैकड़ों पूरी तरह से अलग डेटाबेस की सेवा कर सकता है। Dynomite का उपयोग करके यह करना कहीं से भी आसान नहीं होगा। यह ध्यान देने योग्य है कि Redis Enterprise की मल्टी-टेनेंसी इसकी मल्टी-मॉडल क्षमताओं के साथ अच्छी तरह फिट बैठती है। माइक्रोसर्विसेज के संदर्भ में, कोई विभिन्न फिट-फॉर-पर्पस डेटाबेस को नोड्स के एक ही सेट में चलाने की कल्पना कर सकता है, प्रत्येक अपने स्वयं के रेप्लिकेशन, स्केलिंग, पर्सिस्टेंस, और मॉड्यूल कॉन्फिगरेशन के साथ।
अंत में, Redis Enterprise में Redis On Flash (RoF) नामक एक फीचर है। RoF आपके डेटाबेस को RAM और समर्पित फ्लैश मेमोरी (SSD/NVMe) दोनों का उपयोग करके बहुत बड़े डेटासेट को RAM जैसी विलंबता और प्रदर्शन के साथ संभालने में सक्षम बनाता है, लेकिन ऑल-RAM डेटाबेस की तुलना में >70% कम लागत पर।
तैनाती विकल्प
Dynomite को कंटेनर या Ubuntu, RHEL, और CentOS चलाने वाली मशीनों में तैनात किया जा सकता है। तैनाती हमेशा सेल्फ-मैनेज्ड होती है, इस अर्थ में कि आपको अपने क्लस्टर को प्रबंधित करने के लिए इंफ्रास्ट्रक्चर और संसाधन प्रदान करने की आवश्यकता होती है। इसके अलावा, जैसा कि पहले चर्चा की गई है, यदि आप Dynomite Manager की सुविधाओं का लाभ उठाना चाहते हैं, तो आपको Dynomite को AWS ऑटोस्केलिंग ग्रुप के भीतर तैनात करने की आवश्यकता है।
दूसरी ओर, Redis Enterprise के कई तैनाती विकल्प हैं, जिन्हें दो समूहों में विभाजित किया जा सकता है:
- सेल्फ-मैनेज्ड समाधान, जिसके द्वारा आप Redis Enterprise Software को स्वयं डाउनलोड, इंस्टॉल, और तैनात करते हैं। बहुत सारे विकल्प हैं जिनमें Linux इंस्टॉलर (कई वितरण), Amazon Machine Image (AMI), Docker Containers, Kubernetes, RedHat OpenShift, Google Kubernetes Engine (GKE), Azure Kubernetes Service (AKS), या Amazon Elastic Kubernetes Service (EKS) शामिल हैं।
- मैनेज्ड समाधान: Redis Enterprise Cloud को सभी तीन प्रमुख पब्लिक क्लाउड प्लेटफॉर्म (Google Cloud, AWS, और Azure) पर एक पूरी तरह से प्रबंधित क्लाउड सेवा (DBaaS) के रूप में पेश किया जाता है। Redis आपके लिए आवश्यक संसाधनों के साथ एक समर्पित वातावरण होस्ट करेगा, जिसमें आप निजी और सार्वजनिक एंडपॉइंट्स के साथ डेटाबेस बना सकते हैं ताकि आपके एप्लिकेशन उनका उपभोग कर सकें।
