सर्वर रहित डेटाबेस की राह पर - कैसे और क्यों

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

मैं वर्तमान में मैनीचैट पर काम कर रहा हूं। संक्षेप में, यह एक स्टार्टअप है - नया, महत्वाकांक्षी और तेजी से बढ़ने वाला। और जब मैं पहली बार कंपनी में शामिल हुआ, तो एक क्लासिक सवाल उठा: "अब एक युवा स्टार्टअप को डीबीएमएस और डेटाबेस बाजार से क्या लेना चाहिए?"

इस लेख में, मेरी रिपोर्ट पर आधारित ऑनलाइन महोत्सव RIT++2020, मैं इस प्रश्न का उत्तर दूंगा। रिपोर्ट का एक वीडियो संस्करण यहां उपलब्ध है यूट्यूब.

सामान्य रूप से ज्ञात डेटाबेस 2020

यह 2020 है, मैंने चारों ओर देखा और तीन प्रकार के डेटाबेस देखे।

पहला प्रकार - क्लासिक ओएलटीपी डेटाबेस: PostgreSQL, SQL सर्वर, Oracle, MySQL। वे बहुत समय पहले लिखे गए थे, लेकिन वे अभी भी प्रासंगिक हैं क्योंकि वे डेवलपर समुदाय से बहुत परिचित हैं।

दूसरा प्रकार है "शून्य" से आधार. उन्होंने अंतर्निहित शार्डिंग और अन्य आकर्षक सुविधाओं को जोड़कर, SQL, पारंपरिक संरचनाओं और ACID को त्यागकर क्लासिक पैटर्न से दूर जाने की कोशिश की। उदाहरण के लिए, यह कैसेंड्रा, मोंगोडीबी, रेडिस या टारनटूल है। ये सभी समाधान बाज़ार को मौलिक रूप से कुछ नया पेश करना चाहते थे और उन्होंने अपना स्थान बना लिया क्योंकि वे कुछ कार्यों के लिए बेहद सुविधाजनक साबित हुए। मैं इन डेटाबेस को व्यापक शब्द NOSQL से निरूपित करूंगा।

"शून्य" खत्म हो गए हैं, हमें NOSQL डेटाबेस की आदत हो गई है, और दुनिया ने, मेरे दृष्टिकोण से, अगला कदम उठाया है - प्रबंधित डेटाबेस. इन डेटाबेस में क्लासिक OLTP डेटाबेस या नए NoSQL डेटाबेस के समान ही कोर है। लेकिन उन्हें DBA और DevOps की कोई आवश्यकता नहीं है और वे क्लाउड में प्रबंधित हार्डवेयर पर चलते हैं। एक डेवलपर के लिए, यह "सिर्फ एक आधार" है जो कहीं न कहीं काम करता है, लेकिन किसी को परवाह नहीं है कि इसे सर्वर पर कैसे स्थापित किया जाता है, सर्वर को किसने कॉन्फ़िगर किया है और इसे कौन अपडेट करता है।

ऐसे डेटाबेस के उदाहरण:

• AWS RDS PostgreSQL/MySQL के लिए एक प्रबंधित रैपर है।
• DynamoDB Redis और MongoDB के समान दस्तावेज़ आधारित डेटाबेस का AWS एनालॉग है।
• Amazon Redshift एक प्रबंधित विश्लेषणात्मक डेटाबेस है।

ये मूल रूप से पुराने डेटाबेस हैं, लेकिन हार्डवेयर के साथ काम करने की आवश्यकता के बिना, प्रबंधित वातावरण में बनाए गए हैं।

टिप्पणी। उदाहरण AWS परिवेश के लिए लिए गए हैं, लेकिन उनके एनालॉग Microsoft Azure, Google Cloud, या Yandex.Cloud में भी मौजूद हैं।

इसमें नया क्या है? 2020 में, इनमें से कुछ भी नहीं।

सर्वर रहित अवधारणा

2020 में बाज़ार में वास्तव में जो नया है वह सर्वर रहित या सर्वर रहित समाधान है।

मैं नियमित सेवा या बैकएंड एप्लिकेशन के उदाहरण का उपयोग करके यह समझाने का प्रयास करूंगा कि इसका क्या अर्थ है।
एक नियमित बैकएंड एप्लिकेशन को तैनात करने के लिए, हम एक सर्वर खरीदते हैं या किराए पर लेते हैं, उस पर कोड कॉपी करते हैं, एंडपॉइंट को बाहर प्रकाशित करते हैं और किराए, बिजली और डेटा सेंटर सेवाओं के लिए नियमित रूप से भुगतान करते हैं। यह मानक योजना है.

क्या कोई और तरीका है? सर्वर रहित सेवाओं से आप ऐसा कर सकते हैं।

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

मैं इस दृष्टिकोण को चित्रों के साथ चित्रित करने का प्रयास करूंगा।


क्लासिक परिनियोजन. हमारे पास एक निश्चित भार वाली सेवा है। हम दो उदाहरण उठाते हैं: AWS में भौतिक सर्वर या उदाहरण। बाहरी अनुरोध इन उदाहरणों पर भेजे जाते हैं और वहां संसाधित किए जाते हैं।

जैसा कि आप चित्र में देख सकते हैं, सर्वरों का निपटान समान रूप से नहीं किया गया है। एक 100% उपयोग में है, दो अनुरोध हैं, और एक केवल 50% - आंशिक रूप से निष्क्रिय है। यदि तीन नहीं, बल्कि 30 अनुरोध आते हैं, तो पूरा सिस्टम लोड का सामना नहीं कर पाएगा और धीमा होने लगेगा।

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

एक अनुरोध - एक कंटेनर उठाया गया, 1000 अनुरोध - 1000 कंटेनर। और हार्डवेयर सर्वर पर तैनाती पहले से ही क्लाउड प्रदाता का काम है। यह सर्वर रहित ढांचे द्वारा पूरी तरह छिपा हुआ है। इस अवधारणा में हम प्रत्येक कॉल के लिए भुगतान करते हैं। उदाहरण के लिए, एक दिन में एक कॉल आई - हमने एक कॉल के लिए भुगतान किया, प्रति मिनट एक मिलियन कॉल आई - हमने एक मिलियन के लिए भुगतान किया। या एक सेकंड में ये भी हो जाता है.

सर्वर रहित फ़ंक्शन को प्रकाशित करने की अवधारणा स्टेटलेस सेवा के लिए उपयुक्त है। और यदि आपको (राज्य) स्टेटफुल सेवा की आवश्यकता है, तो हम सेवा में एक डेटाबेस जोड़ते हैं। इस मामले में, जब राज्य के साथ काम करने की बात आती है, तो प्रत्येक स्टेटफुल फ़ंक्शन बस डेटाबेस से लिखता और पढ़ता है। इसके अलावा, लेख की शुरुआत में वर्णित तीन प्रकारों में से किसी एक के डेटाबेस से।

इन सभी डेटाबेस की सामान्य सीमा क्या है? ये लगातार उपयोग किए जाने वाले क्लाउड या हार्डवेयर सर्वर (या कई सर्वर) की लागत हैं। इससे कोई फर्क नहीं पड़ता कि हम क्लासिक या प्रबंधित डेटाबेस का उपयोग करते हैं, चाहे हमारे पास डेवॉप्स और एक व्यवस्थापक है या नहीं, हम अभी भी हार्डवेयर, बिजली और डेटा सेंटर किराये के लिए 24/7 भुगतान करते हैं। यदि हमारे पास क्लासिक आधार है, तो हम स्वामी और दास के लिए भुगतान करते हैं। यदि यह अत्यधिक भरा हुआ शार्ड डेटाबेस है, तो हम 10, 20 या 30 सर्वरों के लिए भुगतान करते हैं, और हम लगातार भुगतान करते हैं।

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

सर्वर रहित डेटाबेस - सिद्धांत

2020 का प्रश्न: क्या डेटाबेस को सर्वर रहित भी बनाना संभव है? सर्वर रहित बैकएंड के बारे में सभी ने सुना है... आइए डेटाबेस को सर्वर रहित बनाने का प्रयास करें?

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

दूसरी ओर, लगभग सभी आधुनिक डेटाबेस में भारी मात्रा में तर्क और घटक होते हैं: लेनदेन, अखंडता समन्वय, प्रक्रियाएं, संबंधपरक निर्भरता और बहुत सारे तर्क। बहुत सारे डेटाबेस तर्क के लिए, एक छोटा राज्य पर्याप्त है। गीगाबाइट्स और टेराबाइट्स का उपयोग सीधे तौर पर प्रश्नों को निष्पादित करने में शामिल डेटाबेस लॉजिक के केवल एक छोटे से हिस्से द्वारा किया जाता है।

तदनुसार, विचार यह है: यदि तर्क का हिस्सा स्टेटलेस निष्पादन की अनुमति देता है, तो आधार को स्टेटफुल और स्टेटलेस भागों में क्यों विभाजित नहीं किया जाए।

OLAP समाधानों के लिए सर्वर रहित

आइए देखें कि व्यावहारिक उदाहरणों का उपयोग करके किसी डेटाबेस को स्टेटफुल और स्टेटलेस भागों में काटना कैसा लग सकता है।

उदाहरण के लिए, हमारे पास एक विश्लेषणात्मक डेटाबेस है: बाहरी डेटा (बाईं ओर लाल सिलेंडर), एक ईटीएल प्रक्रिया जो डेटाबेस में डेटा लोड करती है, और एक विश्लेषक जो डेटाबेस में SQL क्वेरी भेजता है। यह एक क्लासिक डेटा वेयरहाउस ऑपरेशन योजना है।

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

आइए AWS एथेना सर्वरलेस में कार्यान्वित एक वैकल्पिक दृष्टिकोण देखें। कोई स्थायी रूप से समर्पित हार्डवेयर नहीं है जिस पर डाउनलोड किया गया डेटा संग्रहीत किया जाता है। इसके अलावा:

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

इस आर्किटेक्चर में, हम केवल अनुरोध निष्पादित करने की प्रक्रिया के लिए भुगतान करते हैं। कोई अनुरोध नहीं - कोई कीमत नहीं।

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

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

ऐसा डेटाबेस दुर्लभ विश्लेषणात्मक तदर्थ प्रश्नों के लिए लागू होता है। उदाहरण के लिए, जब हम अनायास ही किसी विशाल मात्रा में डेटा पर किसी परिकल्पना का परीक्षण करने का निर्णय लेते हैं। एथेना इन मामलों के लिए बिल्कुल उपयुक्त है। नियमित अनुरोधों के लिए, ऐसी प्रणाली महंगी है। इस स्थिति में, डेटा को किसी विशेष समाधान में कैश करें।

ओएलटीपी समाधानों के लिए सर्वर रहित

पिछले उदाहरण में OLAP (विश्लेषणात्मक) कार्यों को देखा गया था। अब आइए ओएलटीपी कार्यों को देखें।

आइए स्केलेबल PostgreSQL या MySQL की कल्पना करें। आइए न्यूनतम संसाधनों के साथ एक नियमित प्रबंधित इंस्टेंस PostgreSQL या MySQL बढ़ाएं। जब इंस्टेंस को अधिक लोड मिलता है, तो हम अतिरिक्त प्रतिकृतियां कनेक्ट करेंगे, जिससे हम रीडिंग लोड का हिस्सा वितरित करेंगे। यदि कोई अनुरोध या लोड नहीं है, तो हम प्रतिकृतियां बंद कर देते हैं। पहला उदाहरण मास्टर है, और बाकी प्रतिकृतियां हैं।

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

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

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

जब आधार को अनुरोध प्राप्त होते हैं, तो प्रॉक्सी बेड़ा ऑरोरा कैपेसिटी यूनिट्स बढ़ाता है, जिससे सिस्टम के प्रदर्शन संसाधन बढ़ते हैं। संसाधनों को बढ़ाने और घटाने की क्षमता सिस्टम को संसाधनों को "जुगाड़" करने की अनुमति देती है: स्वचालित रूप से व्यक्तिगत एसीयू प्रदर्शित करती है (उन्हें नए के साथ प्रतिस्थापित करती है) और निकाले गए संसाधनों के लिए सभी मौजूदा अपडेट को रोल आउट करती है।

ऑरोरा सर्वरलेस बेस रीडिंग लोड को माप सकता है। लेकिन दस्तावेज़ यह सीधे तौर पर नहीं कहता है। ऐसा महसूस हो सकता है कि वे एक मल्टी-मास्टर को उठा सकते हैं। कोई जादू नहीं है.

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

यह समाधान स्थिर हाईलोड के लिए उपयुक्त नहीं है क्योंकि यह लेखन भार को मापता नहीं है। संसाधनों के ये सभी कनेक्शन और वियोग तथाकथित "स्केल बिंदु" पर होते हैं - एक ऐसा समय जब डेटाबेस लेनदेन या अस्थायी तालिकाओं द्वारा समर्थित नहीं होता है। उदाहरण के लिए, एक सप्ताह के भीतर स्केल प्वाइंट नहीं हो सकता है, और आधार समान संसाधनों पर काम करता है और बस विस्तार या अनुबंध नहीं कर सकता है।

इसमें कोई जादू नहीं है - यह नियमित PostgreSQL है। लेकिन मशीनों को जोड़ने और उन्हें डिस्कनेक्ट करने की प्रक्रिया आंशिक रूप से स्वचालित है।

डिज़ाइन द्वारा सर्वर रहित

ऑरोरा सर्वरलेस एक पुराना डेटाबेस है जिसे सर्वरलेस के कुछ लाभों का लाभ उठाने के लिए क्लाउड के लिए फिर से लिखा गया है। और अब मैं आपको आधार के बारे में बताऊंगा, जो मूल रूप से क्लाउड के लिए, सर्वर रहित दृष्टिकोण के लिए लिखा गया था - सर्वर रहित-डिज़ाइन। इसे तुरंत इस धारणा के बिना विकसित किया गया कि यह भौतिक सर्वर पर चलेगा।

इस आधार को स्नोफ्लेक कहा जाता है। इसके तीन प्रमुख ब्लॉक हैं.

पहला मेटाडेटा ब्लॉक है. यह एक तेज़ इन-मेमोरी सेवा है जो सुरक्षा, मेटाडेटा, लेनदेन और क्वेरी ऑप्टिमाइज़ेशन (बाईं ओर चित्रण में दिखाया गया है) के मुद्दों को हल करती है।

दूसरा ब्लॉक गणना के लिए वर्चुअल कंप्यूटिंग क्लस्टर का एक सेट है (चित्रण में नीले वृत्तों का एक सेट है)।

तीसरा ब्लॉक S3 पर आधारित डेटा स्टोरेज सिस्टम है। S3 AWS में आयाम रहित ऑब्जेक्ट स्टोरेज है, व्यवसाय के लिए आयाम रहित ड्रॉपबॉक्स की तरह।

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

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

इसके बाद, सेवा कंप्यूटिंग क्लस्टर का लॉन्च शुरू करती है। कंप्यूटिंग क्लस्टर सर्वरों का एक क्लस्टर है जो गणना करता है। यानी यह एक क्लस्टर है जिसमें 1 सर्वर, 2 सर्वर, 4, 8, 16, 32 - जितने चाहें उतने हो सकते हैं। आप एक अनुरोध भेजते हैं और इस क्लस्टर का लॉन्च तुरंत शुरू हो जाता है। इसमें सचमुच कुछ सेकंड लगते हैं।

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

प्रत्येक SQL क्वेरी न केवल पहले से लोड किए गए डेटा से समुच्चय को पढ़ सकती है, बल्कि डेटाबेस में नए डेटा को लोड/उत्पन्न भी कर सकती है। अर्थात्, यह एक क्वेरी हो सकती है, जो, उदाहरण के लिए, किसी अन्य तालिका में नए रिकॉर्ड सम्मिलित करती है, जिससे कंप्यूटिंग क्लस्टर पर एक नया विभाजन दिखाई देता है, जो बदले में, एकल S3 स्टोरेज में स्वचालित रूप से सहेजा जाता है।

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

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

एकल-उपयोगकर्ता सेटिंग में स्नोफ्लेक का उपयोग करके वर्णित पहला परिदृश्य। अब आइए कल्पना करें कि बहुत सारे उपयोगकर्ता हैं, जो वास्तविक परिदृश्य के करीब है।

मान लीजिए कि हमारे पास बहुत सारे विश्लेषक और टेबल्यू रिपोर्ट हैं जो लगातार हमारे डेटाबेस पर बड़ी संख्या में सरल विश्लेषणात्मक एसक्यूएल प्रश्नों की बौछार करते रहते हैं।

इसके अलावा, मान लें कि हमारे पास आविष्कारशील डेटा वैज्ञानिक हैं जो डेटा के साथ भयानक चीजें करने की कोशिश कर रहे हैं, दसियों टेराबाइट्स के साथ काम करते हैं, डेटा की अरबों और खरबों पंक्तियों का विश्लेषण करते हैं।

ऊपर वर्णित दो प्रकार के कार्यभार के लिए, स्नोफ्लेक आपको विभिन्न क्षमताओं के कई स्वतंत्र कंप्यूटिंग क्लस्टर बढ़ाने की अनुमति देता है। इसके अलावा, ये कंप्यूटिंग क्लस्टर स्वतंत्र रूप से काम करते हैं, लेकिन सामान्य सुसंगत डेटा के साथ।

बड़ी संख्या में हल्के प्रश्नों के लिए, आप 2-3 छोटे क्लस्टर बना सकते हैं, प्रत्येक में लगभग 2 मशीनें। इस व्यवहार को अन्य बातों के अलावा, स्वचालित सेटिंग्स का उपयोग करके लागू किया जा सकता है। तो आप कहते हैं, “स्नोफ्लेक, एक छोटा समूह बनाओ। यदि उस पर भार एक निश्चित पैरामीटर से ऊपर बढ़ता है, तो एक समान दूसरा, तीसरा बढ़ाएँ। जब भार कम होने लगे, तो अतिरिक्त को बुझा दें।'' ताकि चाहे कितने भी विश्लेषक आएं और रिपोर्ट देखना शुरू करें, सभी के पास पर्याप्त संसाधन हों।

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

साथ ही, भारी प्रश्नों (डेटा वैज्ञानिकों से) के लिए, आप 32 मशीनों के लिए एक बहुत बड़ा क्लस्टर तैयार कर सकते हैं। इस क्लस्टर को भी केवल उन्हीं मिनटों और घंटों के लिए भुगतान किया जाएगा जब आपका विशाल अनुरोध वहां चल रहा हो।

ऊपर वर्णित अवसर आपको न केवल 2, बल्कि अधिक प्रकार के कार्यभार को समूहों में विभाजित करने की अनुमति देता है (ईटीएल, निगरानी, ​​रिपोर्ट भौतिकीकरण,...)।

आइए स्नोफ्लेक को संक्षेप में प्रस्तुत करें। आधार एक सुंदर विचार और व्यावहारिक कार्यान्वयन को जोड़ता है। मैनीचैट में, हम अपने पास मौजूद सभी डेटा का विश्लेषण करने के लिए स्नोफ्लेक का उपयोग करते हैं। हमारे पास तीन क्लस्टर नहीं हैं, जैसा कि उदाहरण में है, लेकिन 5 से 9 तक, विभिन्न आकार के। हमारे पास कुछ कार्यों के लिए पारंपरिक 16-मशीन, 2-मशीन और सुपर-छोटी 1-मशीन भी हैं। वे सफलतापूर्वक भार वितरित करते हैं और हमें काफी बचत करने की अनुमति देते हैं।

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

तदनुसार, डेटाबेस OLAP कार्यों के लिए उपयुक्त है। हालाँकि, दुर्भाग्य से, यह अभी तक OLTP वर्कलोड के लिए लागू नहीं है। सबसे पहले, यह डेटाबेस सभी आगामी परिणामों के साथ स्तंभकार है। दूसरे, स्वयं दृष्टिकोण, जब प्रत्येक अनुरोध के लिए, यदि आवश्यक हो, तो आप एक कंप्यूटिंग क्लस्टर बढ़ाते हैं और इसे डेटा से भर देते हैं, दुर्भाग्य से, ओएलटीपी लोड के लिए अभी तक पर्याप्त तेज़ नहीं है। OLAP कार्यों के लिए सेकंड प्रतीक्षा करना सामान्य है, लेकिन OLTP कार्यों के लिए यह अस्वीकार्य है; 100 एमएस बेहतर होगा, या 10 एमएस और भी बेहतर होगा।

संपूर्ण

डेटाबेस को स्टेटलेस और स्टेटफुल भागों में विभाजित करके सर्वर रहित डेटाबेस संभव है। आपने देखा होगा कि उपरोक्त सभी उदाहरणों में, स्टेटफुल भाग, अपेक्षाकृत रूप से, S3 में सूक्ष्म-विभाजन संग्रहीत करता है, और स्टेटलेस ऑप्टिमाइज़र है, मेटाडेटा के साथ काम करता है, सुरक्षा मुद्दों को संभालता है जिन्हें स्वतंत्र हल्के स्टेटलेस सेवाओं के रूप में उठाया जा सकता है।

SQL क्वेरीज़ को निष्पादित करने को लाइट-स्टेट सेवाओं के रूप में भी माना जा सकता है जो सर्वर रहित मोड में पॉप अप हो सकती हैं, जैसे स्नोफ्लेक कंप्यूटिंग क्लस्टर, केवल आवश्यक डेटा डाउनलोड करें, क्वेरी निष्पादित करें और "बाहर जाएं।"

सर्वर रहित उत्पादन स्तर के डेटाबेस पहले से ही उपयोग के लिए उपलब्ध हैं, वे काम कर रहे हैं। ये सर्वर रहित डेटाबेस OLAP कार्यों को संभालने के लिए पहले से ही तैयार हैं। दुर्भाग्य से, ओएलटीपी कार्यों के लिए उनका उपयोग किया जाता है... बारीकियों के साथ, क्योंकि सीमाएं हैं। एक ओर, यह एक माइनस है। लेकिन, दूसरी ओर, यह एक अवसर है। शायद पाठकों में से एक को ऑरोरा की सीमाओं के बिना, ओएलटीपी डेटाबेस को पूरी तरह से सर्वर रहित बनाने का एक तरीका मिल जाएगा।

मुझे आशा है कि आपको यह दिलचस्प लगा होगा। सर्वर रहित भविष्य है :)

स्रोत: www.habr.com