अगर आप इसे पढ़ रहे हैं तो आपने शायद Amazon Aurora के बारे में सुना होगा। जैसा कि आप जानते हैं, Amazon Aurora, AWS द्वारा सेवाओं के RDS सूट के हिस्से के रूप में प्रदान की गई एक Paa सेवा है। यह पूरी तरह से प्रबंधित रिलेशनल डेटाबेस मैनेजमेंट सिस्टम (RDBMS) प्रदान करता है जो दो फ्लेवर, MySQL और Postgres में आता है, जबकि दोनों के साथ वायर संगतता बनाए रखता है। लेकिन, यह आपकी उच्च उपलब्धता रणनीतियों और विकल्पों को कैसे प्रभावित करता है?
आप सोच रहे होंगे कि कैसे Amazon Aurora, Amazon RDS पर MySQL या PostgreSQL से अलग है। ये पूरी तरह से प्रबंधित RDBMS सेवाएँ भी हैं, है ना? हां, लेकिन वे अनिवार्य रूप से मानक ओपन-सोर्स कार्यान्वयन हैं जो ईसी 2 उदाहरणों के बेड़े पर चल रहे हैं और एडब्ल्यूएस द्वारा प्रबंधित किए जाते हैं। ऑरोरा के साथ मुख्य अंतर यह है कि AWS ने स्टोरेज इंजन को डेटाबेस इंजन से अलग कर दिया। AWS ने ओपन-सोर्स डेटाबेस पर सेपरेशन ऑफ़ कंसर्न सिद्धांत लागू किया।
चिंताओं का पृथक्करण
आम तौर पर, एक आरडीबीएमएस को आम तौर पर उपलब्ध हार्डवेयर पर चलाना होता है। इसका मतलब यह है कि कार्यान्वयन को उन सभी सुविधाओं को पूरा करने के लिए ओएस और हार्डवेयर द्वारा लगाई गई सीमाओं के भीतर काम करना चाहिए, जिनकी हम एक आधुनिक डेटाबेस से उम्मीद करते हैं, जैसे:डीएमएल और डीडीएल प्रसंस्करण, एसीआईडी अनुपालन लेनदेन, प्रतिकृति, उच्च उपलब्धता (एचए), और दोष सहिष्णुता। यदि, हालांकि, कार्यान्वयन को आम तौर पर उपलब्ध हार्डवेयर पर चलाने की आवश्यकता नहीं थी, लेकिन केवल एक डेटाबेस के लिए विशेष रूप से डिज़ाइन किए गए वातावरण में, विभिन्न जिम्मेदारियों को परतों में विभाजित किया जा सकता था, जिससे डेटाबेस इंजन और स्टोरेज इंजन को केंद्रित और विशिष्ट बनाया जा सकता था। परिणामस्वरूप, उच्च उपलब्धता और प्रदर्शन में उल्लेखनीय वृद्धि की जा सकती है - MySQL की तुलना में 5x अधिक प्रदर्शन और मानक PostgreSQL से 3x अधिक तक।
ठीक है, यह तेज़ है, लेकिन एक विशेष डेटाबेस और स्टोरेज इंजन हमें HA के साथ कैसे मदद करता है? ऐसे कई तरीके हैं जिनसे हमें HA हासिल करने में मदद मिलती है। इससे पहले कि हम इसमें शामिल हों, आइए एक त्वरित नज़र डालें कि ऑरोरा स्टोरेज इंजन कैसे काम करता है जिससे हमें यह समझने में मदद मिलती है कि एचए इस अलगाव से कैसे प्राप्त होता है।
जब डेटा ऑरोरा स्टोरेज इंजन को लिखा जाता है, तो इंजन यह सुनिश्चित करता है कि डेटा लगातार, सही और टिकाऊ रूप से लिखा गया है। कुल छह अलग-अलग स्थानों के लिए डेटा तीन उपलब्धता क्षेत्रों में से प्रत्येक में दो स्थानों पर लिखा गया है। स्टोरेज इंजन यह सुनिश्चित करने की जटिलताओं को संभालता है कि यह सब सही ढंग से हो। हालांकि शायद थोड़ा अधिक सरलीकरण, अनिवार्य रूप से डेटाबेस इंजन अब "आग-और-भूल" सकता है, अब इस बारे में चिंता करने की आवश्यकता नहीं है कि क्या डेटा लिखा गया था, लेनदेन लॉग, पुनर्प्राप्त करने की आवश्यकता की संभावना, आदि।
डेटाबेस इंजन से भंडारण की चिंता को दूर करते हुए, कई HA रणनीतियाँ उपलब्ध हो जाती हैं।
प्रतिकृति पढ़ें
जबकि रीड रेप्लिकस की अवधारणा अरोरा से बहुत पहले से है, ओपन-सोर्स समाधानों में कार्यान्वयन में लॉग शिपिंग या क्वेरी रिप्ले शामिल हैं। Aurora के साथ, ReadReplicas के पास मास्टर के समान संग्रहण के लिए केवल-पढ़ने के लिए पहुंच है। इसका मतलब है कि डेटा लिखे जाने से लेकर रीड रेप्लिका को दिखाई देने तक के समय से बहुत कम प्रतिकृति विलंबता (प्रतिकृति अंतराल इस परिदृश्य में एक मिथ्या नाम होगा)। जब कई रीड रेप्लिका की आवश्यकता होती है, तो सभी रीड रेप्लिकस एक ही डेटा देखते हैं, मास्टर पर लगाए गए ओवरहेड और जटिलता को हटाते हुए, मानक MySQL और PostgreSQL कार्यान्वयन पाए जाते हैं। मास्टर के विफल होने पर रीड रेप्लिका को तुरंत लेने की अनुमति देने के लिए ये सुविधाएँ एक साथ आती हैं। इसके अलावा, AWS नए इंस्टेंस के साथ, प्रावधानित क्षमता को पूरा करने के लिए विफल इंस्टेंस को बदलने का काम संभालती है और नए मास्टर को इंगित करने के लिए DNS को अपडेट करती है।
यह उन अनुप्रयोगों के लिए एक बढ़िया समाधान है जिनमें उच्च पढ़ने-लिखने का अनुपात है। हालांकि, ध्यान रखें कि आपका प्राथमिक उदाहरण संपूर्ण लेखन भार को संभालने के लिए पर्याप्त बड़ा होना चाहिए। साथ ही, HA लिखने के लिए, आप कम से कम oneRead Replication का प्रावधान करना चाहते हैं जो आपके मास्टर के समान आकार का हो। फिर, इस रीड रेप्लिका को प्राथमिक इंस्टेंस में प्रचारित करने के लिए प्राथमिकता इंस्टेंस सेट करें। असफल होने की स्थिति में, आप पढ़ने और लिखने दोनों की क्षमता के लिए उच्च उपलब्धता बनाए रखेंगे।
स्वतः स्केलिंग
ऑटोस्केलिंग आपके उपलब्ध सर्वरों के सेट से क्षैतिज रूप से स्केल आउट (इंस्टेंस जोड़ें) या स्केल इन (इंस्टेंस निकालें) करने की क्षमता है। आपने EC2 उदाहरणों के लिए ऑटो स्केलिंग के बारे में सुना होगा, लेकिन क्या आप जानते हैं कि आप अपने Aurora रीड रेप्लिकाज़ में भी लोच रख सकते हैं? आम तौर पर, आप अपने बेस लोड को संभालने के लिए रीड रेप्लिका की न्यूनतम संख्या को कॉन्फ़िगर करेंगे और मांग में बदलाव के रूप में उदाहरण जोड़ने या हटाने के लिए ऑटोस्केलिंग नीतियां होंगी। लोच का लाभ उठाने की क्षमता इस तथ्य का एक और व्युत्पन्न है कि स्टोरेज इंजन डेटाबेसइंजन से अलग है।
एक उदाहरण परिदृश्य जहां यह उपयोगी होगा एक B2B ईकॉमर्स साइट है। यह कार्यदिवस के व्यावसायिक घंटों के दौरान भारी यातायात का अनुभव करेगा लेकिन रात भर और सप्ताहांत पर बहुत कम। छवियों और सामग्री के विवरण में पढ़ने-से-लिखने का उच्च अनुपात होता है और रीड रेप्लिका और ऑटो स्केलिंग दोनों से लाभ होता है। अपने ReadReplicas को ऑटो-स्केल करने से आप व्यस्त समय के दौरान मांग को पूरा कर सकते हैं, जबकि बंद समय के दौरान लागत को कम कर सकते हैं।
क्रॉस-क्षेत्र प्रतिकृति
यदि आपको उपलब्धता को अगले स्तर पर लाने की आवश्यकता है, तो इसे दूसरे क्षेत्र में दोहराएं। डेटाबेस इंजन द्वारा डेटा को दूसरे क्षेत्र में दोहराने से, इसे स्थानीय रूप से पढ़ा जा सकता है या प्राथमिक क्षेत्र की विफलता के मामले में उपयोग किया जा सकता है। द्वितीयक क्षेत्र में इंस्टेंस को रीड रेप्लिका के रूप में माना जाता है (यह मल्टी-मास्टर नहीं है), लेकिन इसकी अपनी रीड रेप्लिका भी हो सकती है या प्राथमिक क्षेत्र विफल होने पर मास्टर बन सकता है।
कई कारण हैं कि क्रॉस-क्षेत्र प्रतिकृति की आवश्यकता क्यों होगी। कभी-कभी डेटा एक भौगोलिक क्षेत्र में संग्रहीत करने के लिए बहुत महत्वपूर्ण होता है। यह व्यवसाय निरंतरता, नियामक या वित्तीय कारणों से हो सकता है। एक अन्य कारण उपयोगकर्ताओं और डेटाबेस बैकएंड के बीच विलंबता को कम करना है। एक बार फिर से एक उदाहरण के रूप में ईकॉमर्स का उपयोग करते हुए, छवियों और विवरणों में परिवर्तन को एक ही क्षेत्र में मास्टर पर लागू किया जा सकता है लेकिन स्थानीय रूप से पढ़ने के लिए विश्व स्तर पर वितरित किया जा सकता है।
बाहरी प्रतिकृति
उन स्थितियों के बारे में जहां आपको औरोरा क्लस्टर के बाहर डेटा की आवश्यकता होती है? ऐसी स्थितियां होती हैं जहां कॉर्पोरेट नीतियां या नियामक वातावरण इसकी मांग करता है, या आपको डेटा को संसाधित करने या औरोरा के बाहर रिपोर्ट चलाने की आवश्यकता होती है। इन सभी मामलों का उपयोग करके नियंत्रित किया जा सकता है बाहरी प्रतिकृति।
यह आसान है कि Aurora डेटा को Amazon EC2 MySQL इंस्टेंस, MySQL चलाने वाले Amazon EC2 इंस्टेंस, या यहां तक कि आपके कॉर्पोरेट डेटा सेंटर में चल रहे एक MySQL इंस्टेंस में दोहराए। इस एकतरफा प्रतिकृति का उपयोग करते हुए, आपका डेटा हमेशा आपके Aurora क्लस्टर के साथ समन्वयित होता है और Aurora के बाहर उपयोग के लिए उपलब्ध होता है।
सर्वर रहित
अंतिम, लेकिन निश्चित रूप से कम से कम, सर्वर रहित है। शायद उपलब्धता और मापनीयता के लिए सबसे महत्वपूर्ण विकासों में से एक समीकरण में सर्वर रहित जोड़ना है। जाहिर है सर्वर रहित का मतलब यह नहीं है कि सर्वर नहीं हैं। इसका मतलब है कि आपको किसी सर्वर के प्रावधान, कॉन्फ़िगरेशन, स्केलिंग या रखरखाव के बारे में चिंता करने की ज़रूरत नहीं है।
Aurora Serverless को कॉन्फ़िगर करने के लिए, आप अपने एप्लिकेशन के लिए उपलब्ध क्षमता को निर्दिष्ट करते हैं और AWS यह सुनिश्चित करने के विवरण को संभालता है कि क्षमता मांग पर उपलब्ध है, जब आपके क्लाइंट को इसकी आवश्यकता होती है। सर्वर रहित के लिए, दो मौजूदा परतों, डेटाबेस इंजन और स्टोरेज इंजन में एक अतिरिक्त परत, एप्रोक्सी परत जोड़ी गई है।
AWS प्रॉक्सी सर्वर का एक बेड़ा रखता है जो आने वाले अनुरोधों को सुनता है। इसके अलावा, डीबी क्षमता का एक गर्म पूल अनुरोध को पूरा करने की प्रतीक्षा कर रहा है। जब आपकी पहली क्वेरी आती है, तो प्रॉक्सी बेड़ा इसे प्राप्त करता है, वार्म पूल से एक इंस्टेंस का अनुरोध करता है, और आपके उपयोग के लिए आवंटित किए जाने के बाद, उस इंस्टेंस को अनुरोध अग्रेषित करता है। इससे भी बेहतर, आपके उपयोग के लिए आवंटित इंस्टेंस की संख्या इलास्टिक और मांग के आधार पर अंदर और बाहर स्केल और आपके द्वारा Aurora सर्वर रहित कॉन्फ़िगरेशन में निर्दिष्ट सीमा। पहले की रणनीतियों की तरह, आपको डेटाबेस इंजन को गतिशील रूप से आवंटित करने की क्षमता डेटाबेस और स्टोरेज के पृथक्करण से संभव हुई है। आपके कॉन्फ़िगरेशन के आधार पर, डेटाबेस इंस्टेंस आपको असाइन किया जाता है और तत्काल उपयोग के लिए उपलब्ध होता है। टाइमआउट अवधि समाप्त होने के बाद, इंस्टेंस को वार्म पूल में वापस कर दिया जाता है। आपसे केवल उन संसाधनों के लिए शुल्क लिया जाता है जिनका आप उपयोग कर रहे हैं। जब आपके उपयोग के लिए एक इंस्टेंस आवंटित किया जाता है, तो आपसे इसके लिए शुल्क लिया जाता है, साथ ही किसी भी खपत किए गए भंडारण के लिए भी। जब आवंटित नहीं किया जाता है, तो आपसे केवल खपत किए गए संग्रहण के लिए शुल्क लिया जाता है।
काम के बोझ के लिए जो स्पाइकी हैं, जैसे कि विकास और परीक्षण वातावरण, या नए एप्लिकेशन जिनके पास उपयोग पैटर्न की भविष्यवाणी करने के लिए पर्याप्त इतिहास नहीं है, सर्वर रहित जाने का रास्ता है। अब आप उस संसाधन के लिए भुगतान नहीं करते हैं जिसका आप उपयोग नहीं कर रहे हैं, यह सुनिश्चित करने के बारे में चिंता करने की ज़रूरत नहीं है कि विकास दल ने सप्ताहांत के लिए जाने से पहले रोशनी को चालू कर दिया है, और आप क्षमता को समायोजित करने के लिए आधी रात को नहीं उठेंगे क्योंकि आपके उपयोगकर्ता ' समय क्षेत्र आपके स्लीपज़ोन से मेल खाता है।
रैपिंग अप
Amazon Aurora को उपलब्धता, टिकाऊपन और मापनीयता को ध्यान में रखकर बनाया गया है। यदि मानक ओपन-सोर्स कार्यान्वयन की तरह उपयोग किया जाता है, तो आपके पास एक ठोस, विश्वसनीय और प्रदर्शनकारी डेटाबेस है। Aurora की क्षमताओं और उनका लाभ उठाने के पैटर्न को थोड़ा गहराई से देखने के साथ, आप स्थानीय रीड ऑफ़लोडिंग से लेकर विश्व स्तर पर वितरित उपलब्धता तक, अपनी आवश्यकताओं को पूरा करने के लिए एक समाधान लागू कर सकते हैं।
कोई टिप्पणी करने या प्रश्न पूछने के लिए फ़ीडबैक टैब का उपयोग करें।