सर्व्हरलेस डेटाबेसच्या मार्गावर - कसे आणि का

सर्वांना नमस्कार! माझे नाव गोलोव निकोले आहे. यापूर्वी, मी अविटो येथे काम केले आणि सहा वर्षे डेटा प्लॅटफॉर्म व्यवस्थापित केले, म्हणजे, मी सर्व डेटाबेसवर काम केले: विश्लेषणात्मक (व्हर्टिका, क्लिकहाऊस), स्ट्रीमिंग आणि ओएलटीपी (रेडिस, टारंटूल, व्होल्टडीबी, मोंगोडीबी, पोस्टग्रेएसक्यूएल). या वेळी, मी मोठ्या संख्येने डेटाबेस हाताळले - खूप भिन्न आणि असामान्य आणि त्यांच्या वापराच्या गैर-मानक प्रकरणांसह.

मी सध्या ManyChat वर काम करत आहे. थोडक्यात, हा एक स्टार्टअप आहे - नवीन, महत्त्वाकांक्षी आणि वेगाने वाढणारा. आणि जेव्हा मी पहिल्यांदा कंपनीत सामील झालो तेव्हा एक उत्कृष्ट प्रश्न उद्भवला: "आता तरुण स्टार्टअपने DBMS आणि डेटाबेस मार्केटमधून काय घ्यावे?"

या लेखात, माझ्या अहवालावर आधारित ऑनलाइन उत्सव RIT++2020, मी या प्रश्नाचे उत्तर देईन. अहवालाची व्हिडिओ आवृत्ती येथे उपलब्ध आहे YouTube वर.

सामान्यतः ज्ञात डेटाबेस 2020

हे 2020 आहे, मी आजूबाजूला पाहिले आणि तीन प्रकारचे डेटाबेस पाहिले.

पहिला प्रकार - क्लासिक OLTP डेटाबेस: PostgreSQL, SQL Server, Oracle, MySQL. ते खूप पूर्वी लिहिले गेले होते, परंतु तरीही ते संबंधित आहेत कारण ते विकसक समुदायाला खूप परिचित आहेत.

दुसरा प्रकार आहे "शून्य" पासून आधार. त्यांनी एसक्यूएल, पारंपारिक संरचना आणि ACID सोडून, ​​अंगभूत शार्डिंग आणि इतर आकर्षक वैशिष्ट्ये जोडून क्लासिक पॅटर्नपासून दूर जाण्याचा प्रयत्न केला. उदाहरणार्थ, हे Cassandra, MongoDB, Redis किंवा Tarantool आहे. या सर्व सोल्यूशन्सना बाजाराला मूलभूतपणे नवीन काहीतरी ऑफर करायचे होते आणि त्यांचे स्थान व्यापले कारण ते काही विशिष्ट कार्यांसाठी अत्यंत सोयीस्कर ठरले. मी हे डाटाबेस NOSQL या छत्रीने सूचित करेन.

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

अशा डेटाबेसची उदाहरणे:

• AWS RDS हे PostgreSQL/MySQL साठी व्यवस्थापित रॅपर आहे.
• DynamoDB हे Redis आणि MongoDB प्रमाणेच दस्तऐवज आधारित डेटाबेसचे AWS अॅनालॉग आहे.
• Amazon Redshift एक व्यवस्थापित विश्लेषणात्मक डेटाबेस आहे.

हे मुळात जुने डेटाबेस आहेत, परंतु हार्डवेअरसह कार्य न करता व्यवस्थापित वातावरणात वाढवले ​​जातात.

नोंद. उदाहरणे AWS पर्यावरणासाठी घेतली आहेत, परंतु त्यांचे analogues Microsoft Azure, Google Cloud, किंवा Yandex.Cloud मध्ये देखील अस्तित्वात आहेत.

यात नवीन काय आहे? 2020 मध्ये, यापैकी काहीही नाही.

सर्व्हरलेस संकल्पना

2020 मध्ये बाजारात खरोखर नवीन काय आहे ते म्हणजे सर्व्हरलेस किंवा सर्व्हरलेस सोल्यूशन्स.

नियमित सेवेचे किंवा बॅकएंड ऍप्लिकेशनचे उदाहरण वापरून याचा अर्थ काय हे मी समजावून सांगण्याचा प्रयत्न करेन.
नियमित बॅकएंड ऍप्लिकेशन उपयोजित करण्यासाठी, आम्ही सर्व्हर खरेदी करतो किंवा भाड्याने देतो, त्यावर कोड कॉपी करतो, एंडपॉइंट बाहेर प्रकाशित करतो आणि नियमितपणे भाडे, वीज आणि डेटा सेंटर सेवांसाठी पैसे देतो. ही मानक योजना आहे.

दुसरा काही मार्ग आहे का? सर्व्हरलेस सेवांसह तुम्ही हे करू शकता.

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

मी हा दृष्टिकोन चित्रांसह स्पष्ट करण्याचा प्रयत्न करेन.


क्लासिक उपयोजन. आमच्याकडे विशिष्ट भार असलेली सेवा आहे. आम्ही दोन उदाहरणे वाढवतो: भौतिक सर्व्हर किंवा AWS मधील उदाहरणे. या उदाहरणांना बाह्य विनंत्या पाठवल्या जातात आणि तेथे प्रक्रिया केली जाते.

जसे आपण चित्रात पाहू शकता, सर्व्हरची तितकीच विल्हेवाट लावली जात नाही. एक 100% वापरला गेला आहे, दोन विनंत्या आहेत आणि एक फक्त 50% आहे - अंशतः निष्क्रिय. जर तीन विनंत्या आल्या नाहीत, परंतु 30, तर संपूर्ण सिस्टम लोडचा सामना करण्यास सक्षम होणार नाही आणि मंद होण्यास सुरवात करेल.

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

एक विनंती - एक कंटेनर उचलला, 1000 विनंत्या - 1000 कंटेनर. आणि हार्डवेअर सर्व्हरवर तैनात करणे हे आधीच क्लाउड प्रदात्याचे काम आहे. हे सर्व्हरलेस फ्रेमवर्कद्वारे पूर्णपणे लपलेले आहे. या संकल्पनेत आम्ही प्रत्येक कॉलसाठी पैसे देतो. उदाहरणार्थ, एका दिवसात एक कॉल आला - आम्ही एका कॉलसाठी पैसे दिले, प्रति मिनिट एक दशलक्ष आले - आम्ही एक दशलक्ष पैसे दिले. किंवा एका सेकंदात, हे देखील घडते.

सर्व्हरलेस फंक्शन प्रकाशित करण्याची संकल्पना स्टेटलेस सेवेसाठी योग्य आहे. आणि जर तुम्हाला (राज्य) स्टेटफुल सेवेची गरज असेल, तर आम्ही सेवेमध्ये डेटाबेस जोडतो. या प्रकरणात, जेव्हा राज्यासह कार्य करण्याचा विचार येतो, तेव्हा प्रत्येक स्टेटफुल फंक्शन डेटाबेसमधून फक्त लिहितो आणि वाचतो. शिवाय, लेखाच्या सुरुवातीला वर्णन केलेल्या तीनपैकी कोणत्याही प्रकारच्या डेटाबेसमधून.

या सर्व डेटाबेसची समान मर्यादा काय आहे? हे सतत वापरल्या जाणार्‍या क्लाउड किंवा हार्डवेअर सर्व्हरच्या (किंवा अनेक सर्व्हर) किंमती आहेत. आम्ही क्लासिक किंवा व्यवस्थापित डेटाबेस वापरतो की नाही हे महत्त्वाचे नाही, आमच्याकडे Devops आणि प्रशासक आहे की नाही, आम्ही तरीही हार्डवेअर, वीज आणि डेटा सेंटर भाड्याने 24/7 पैसे देतो. आमच्याकडे क्लासिक बेस असल्यास, आम्ही मास्टर आणि स्लेव्हसाठी पैसे देतो. हा एक अत्यंत लोड केलेला शार्डेड डेटाबेस असल्यास, आम्ही 10, 20 किंवा 30 सर्व्हरसाठी पैसे देतो आणि आम्ही सतत पैसे देतो.

खर्चाच्या संरचनेत कायमस्वरूपी आरक्षित सर्व्हरची उपस्थिती पूर्वी आवश्यक वाईट म्हणून समजली जात होती. पारंपारिक डेटाबेसमध्ये इतर अडचणी देखील असतात, जसे की कनेक्शनच्या संख्येवरील मर्यादा, स्केलिंग निर्बंध, भौगोलिक-वितरित एकमत - ते काही विशिष्ट डेटाबेसमध्ये सोडवले जाऊ शकतात, परंतु सर्व एकाच वेळी नाही आणि आदर्शपणे नाही.

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

2020 चा प्रश्न: डेटाबेस सर्व्हरलेस देखील करणे शक्य आहे का? सर्वांनी सर्व्हरलेस बॅकएंडबद्दल ऐकले आहे... डेटाबेस सर्व्हरलेस करण्याचा प्रयत्न करूया?

हे विचित्र वाटत आहे, कारण डेटाबेस ही स्टेटफुल सेवा आहे, सर्व्हरलेस इन्फ्रास्ट्रक्चरसाठी फारशी योग्य नाही. त्याच वेळी, डेटाबेसची स्थिती खूप मोठी आहे: गीगाबाइट्स, टेराबाइट्स आणि विश्लेषणात्मक डेटाबेसमध्ये अगदी पेटाबाइट्स. हलक्या वजनाच्या डॉकर कंटेनरमध्ये ते वाढवणे इतके सोपे नाही.

दुसरीकडे, जवळजवळ सर्व आधुनिक डेटाबेसमध्ये मोठ्या प्रमाणात तर्क आणि घटक असतात: व्यवहार, अखंडता समन्वय, कार्यपद्धती, रिलेशनल अवलंबित्व आणि बरेच तर्कशास्त्र. बर्‍याच डेटाबेस लॉजिकसाठी, एक लहान राज्य पुरेसे आहे. गीगाबाइट्स आणि टेराबाइट्स थेट क्वेरी कार्यान्वित करण्यात गुंतलेल्या डेटाबेस लॉजिकच्या फक्त एका छोट्या भागाद्वारे थेट वापरले जातात.

त्यानुसार, कल्पना अशी आहे: जर तर्कशास्त्राचा भाग स्टेटलेस अंमलबजावणीला परवानगी देतो, तर बेसला स्टेटफुल आणि स्टेटलेस भागांमध्ये का विभाजित करू नये.

OLAP सोल्यूशन्ससाठी सर्व्हरलेस

व्यावहारिक उदाहरणे वापरून डेटाबेसला स्टेटफुल आणि स्टेटलेस भागांमध्ये कट करणे कसे दिसते ते पाहू या.

उदाहरणार्थ, आमच्याकडे विश्लेषणात्मक डेटाबेस आहे: बाह्य डेटा (डावीकडे लाल सिलेंडर), डेटाबेसमध्ये डेटा लोड करणारी ETL प्रक्रिया आणि डेटाबेसला SQL क्वेरी पाठवणारा विश्लेषक. ही एक उत्कृष्ट डेटा वेअरहाऊस ऑपरेशन योजना आहे.

या योजनेत, ईटीएल सशर्त एकदाच केले जाते. मग तुम्हाला सतत त्या सर्व्हरसाठी पैसे द्यावे लागतील ज्यावर डेटाबेस ईटीएलने भरलेल्या डेटासह चालतो, जेणेकरुन क्वेरी पाठवण्यासाठी काहीतरी असेल.

AWS Athena Serverless मध्ये लागू केलेला पर्यायी दृष्टिकोन पाहू. कोणतेही कायमचे समर्पित हार्डवेअर नाही ज्यावर डाउनलोड केलेला डेटा संग्रहित केला जातो. या ऐवजी:

• वापरकर्ता एसक्यूएल क्वेरी अॅथेनाला सबमिट करतो. एथेना ऑप्टिमायझर SQL क्वेरीचे विश्लेषण करते आणि क्वेरी कार्यान्वित करण्यासाठी आवश्यक असलेल्या विशिष्ट डेटासाठी मेटाडेटा स्टोअर (मेटाडेटा) शोधते.
• ऑप्टिमायझर, गोळा केलेल्या डेटावर आधारित, बाह्य स्त्रोतांकडून आवश्यक डेटा तात्पुरत्या स्टोरेजमध्ये (तात्पुरता डेटाबेस) डाउनलोड करतो.
• वापरकर्त्याकडून SQL क्वेरी तात्पुरत्या स्टोरेजमध्ये कार्यान्वित केली जाते आणि परिणाम वापरकर्त्याला परत केला जातो.
• तात्पुरते स्टोरेज साफ केले जाते आणि संसाधने सोडली जातात.

या आर्किटेक्चरमध्ये, आम्ही फक्त विनंती कार्यान्वित करण्याच्या प्रक्रियेसाठी पैसे देतो. विनंत्या नाहीत - कोणतेही शुल्क नाही.

हा एक कार्यरत दृष्टीकोन आहे आणि केवळ एथेना सर्व्हरलेसमध्येच नाही तर रेडशिफ्ट स्पेक्ट्रममध्ये (AWS मध्ये) देखील लागू केला जातो.

अथेना उदाहरण दाखवते की सर्व्हरलेस डेटाबेस दहापट आणि शेकडो टेराबाइट डेटासह वास्तविक क्वेरींवर कार्य करते. शेकडो टेराबाइट्ससाठी शेकडो सर्व्हरची आवश्यकता असेल, परंतु आम्हाला त्यांच्यासाठी पैसे द्यावे लागणार नाहीत - आम्ही विनंत्यांसाठी पैसे देतो. व्हर्टिका सारख्या विशेष विश्लेषणात्मक डेटाबेसच्या तुलनेत प्रत्येक विनंतीची गती (खूप) कमी आहे, परंतु आम्ही डाउनटाइम कालावधीसाठी पैसे देत नाही.

असा डेटाबेस दुर्मिळ विश्लेषणात्मक तदर्थ प्रश्नांसाठी लागू आहे. उदाहरणार्थ, जेव्हा आपण उत्स्फूर्तपणे काही अवाढव्य डेटावर परिकल्पना तपासण्याचे ठरवतो. अथेना या प्रकरणांसाठी योग्य आहे. नियमित विनंत्यांसाठी, अशी प्रणाली महाग आहे. या प्रकरणात, काही विशिष्ट सोल्यूशनमध्ये डेटा कॅशे करा.

OLTP उपायांसाठी सर्व्हरलेस

मागील उदाहरणाने OLAP (विश्लेषणात्मक) कार्ये पाहिली. आता OLTP कार्ये पाहू.

स्केलेबल PostgreSQL किंवा MySQL ची कल्पना करूया. किमान संसाधनांसह नियमित व्यवस्थापित उदाहरण PostgreSQL किंवा MySQL वाढवू. जेव्हा उदाहरणाला अधिक भार प्राप्त होतो, तेव्हा आम्ही अतिरिक्त प्रतिकृती जोडू ज्यामध्ये आम्ही वाचन लोडचा काही भाग वितरित करू. कोणत्याही विनंत्या किंवा लोड नसल्यास, आम्ही प्रतिकृती बंद करतो. प्रथम उदाहरण मास्टर आहे, आणि उर्वरित प्रतिकृती आहेत.

ही कल्पना Aurora Serverless AWS नावाच्या डेटाबेसमध्ये लागू केली आहे. तत्त्व सोपे आहे: बाह्य अनुप्रयोगांच्या विनंत्या प्रॉक्सी फ्लीटद्वारे स्वीकारल्या जातात. लोड वाढलेले पाहून, ते पूर्व-उबदार किमान उदाहरणांमधून संगणकीय संसाधनांचे वाटप करते - कनेक्शन शक्य तितक्या लवकर केले जाते. अक्षम करण्याच्या घटना त्याच प्रकारे घडतात.

Aurora मध्ये Aurora Capacity Unit, ACU ची संकल्पना आहे. हे (सशर्त) एक उदाहरण (सर्व्हर) आहे. प्रत्येक विशिष्ट ACU एक मास्टर किंवा गुलाम असू शकतो. प्रत्येक क्षमता युनिटची स्वतःची RAM, प्रोसेसर आणि किमान डिस्क असते. त्यानुसार, एक मास्टर आहे, बाकीच्या फक्त वाचलेल्या प्रतिकृती आहेत.

चालू असलेल्या या Aurora क्षमता युनिट्सची संख्या कॉन्फिगर करण्यायोग्य पॅरामीटर आहे. किमान प्रमाण एक किंवा शून्य असू शकते (या प्रकरणात, विनंत्या नसल्यास डेटाबेस कार्य करत नाही).

जेव्हा बेसला विनंत्या प्राप्त होतात, तेव्हा प्रॉक्सी फ्लीट Aurora CapacityUnits वाढवते, ज्यामुळे सिस्टीमची कार्यक्षमता संसाधने वाढते. संसाधने वाढवण्याची आणि कमी करण्याची क्षमता सिस्टमला संसाधने "जगल" करण्यास अनुमती देते: वैयक्तिक ACU स्वयंचलितपणे प्रदर्शित करते (त्यांना नवीनसह बदलून) आणि मागे घेतलेल्या संसाधनांसाठी सर्व वर्तमान अद्यतने रोल आउट करतात.

Aurora Serverless बेस वाचन लोड मोजू शकतो. परंतु कागदपत्रे हे थेट सांगत नाहीत. ते बहु-मास्टर उचलू शकतात असे वाटू शकते. कोणतीही जादू नाही.

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

हे समाधान स्थिर हायलोडसाठी योग्य नाही कारण ते लेखन लोड मोजत नाही. हे सर्व कनेक्शन आणि संसाधनांचे डिस्कनेक्शन तथाकथित "स्केल पॉईंट" वर घडतात - जेव्हा डेटाबेसला व्यवहार किंवा तात्पुरत्या सारण्यांद्वारे समर्थित नसते. उदाहरणार्थ, एका आठवड्याच्या आत स्केल पॉइंट होऊ शकत नाही आणि बेस समान संसाधनांवर कार्य करतो आणि फक्त विस्तारित किंवा संकुचित करू शकत नाही.

कोणतीही जादू नाही - ते नियमित PostgreSQL आहे. परंतु मशीन्स जोडण्याची आणि डिस्कनेक्ट करण्याची प्रक्रिया अंशतः स्वयंचलित आहे.

डिझाइननुसार सर्व्हरलेस

अरोरा सर्व्हरलेस हा क्लाउडसाठी सर्व्हरलेसच्या काही फायद्यांचा लाभ घेण्यासाठी पुन्हा लिहिण्यात आलेला जुना डेटाबेस आहे. आणि आता मी तुम्हाला बेसबद्दल सांगेन, जे मूळतः क्लाउडसाठी लिहिलेले होते, सर्व्हरलेस पध्दतीसाठी - सर्व्हरलेस-बाय-डिझाइन. ते भौतिक सर्व्हरवर चालेल असे गृहीत न धरता त्वरित विकसित केले गेले.

या तळाला स्नोफ्लेक म्हणतात. यात तीन की ब्लॉक्स आहेत.

पहिला मेटाडेटा ब्लॉक आहे. ही एक जलद इन-मेमरी सेवा आहे जी सुरक्षा, मेटाडेटा, व्यवहार आणि क्वेरी ऑप्टिमायझेशन (डावीकडील चित्रात दर्शविलेले) समस्यांचे निराकरण करते.

दुसरा ब्लॉक गणनेसाठी व्हर्च्युअल कॉम्प्युटिंग क्लस्टर्सचा संच आहे (चित्रात निळ्या वर्तुळांचा संच आहे).

तिसरा ब्लॉक S3 वर आधारित डेटा स्टोरेज सिस्टम आहे. S3 हे AWS मध्ये डायमेंशनलेस ऑब्जेक्ट स्टोरेज आहे, व्यवसायासाठी डायमेंशनलेस ड्रॉपबॉक्स सारखे.

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

आता कल्पना करू या की एक वापरकर्ता आमच्या डेटाबेसवर आला आणि त्याने SQL क्वेरी पाठवली. SQL क्वेरी प्रक्रिया करण्यासाठी त्वरित मेटाडेटा सेवेकडे पाठविली जाते. त्यानुसार, विनंती प्राप्त झाल्यावर, ही सेवा विनंतीचे विश्लेषण करते, उपलब्ध डेटा, वापरकर्ता परवानग्या आणि सर्व काही ठीक असल्यास, विनंतीवर प्रक्रिया करण्यासाठी योजना तयार करते.

पुढे, सेवा संगणकीय क्लस्टर लाँच करण्यास प्रारंभ करते. कॉम्प्युटिंग क्लस्टर हे सर्व्हरचे क्लस्टर आहे जे गणना करतात. म्हणजेच, हा एक क्लस्टर आहे ज्यामध्ये 1 सर्व्हर, 2 सर्व्हर, 4, 8, 16, 32 - तुम्हाला पाहिजे तितके असू शकतात. तुम्ही विनंती करा आणि या क्लस्टरचे प्रक्षेपण लगेच सुरू होईल. यास खरोखर काही सेकंद लागतात.

पुढे, क्लस्टर सुरू झाल्यानंतर, तुमच्या विनंतीवर प्रक्रिया करण्यासाठी आवश्यक असलेली मायक्रोपार्टिशन्स S3 वरून क्लस्टरमध्ये कॉपी करणे सुरू होते. म्हणजेच, आपण कल्पना करूया की SQL क्वेरी कार्यान्वित करण्यासाठी आपल्याला एका टेबलमधून दोन विभाजनांची आवश्यकता आहे आणि दुसऱ्यामधून एक. या प्रकरणात, फक्त तीन आवश्यक विभाजने क्लस्टरमध्ये कॉपी केली जातील, आणि सर्व सारण्या पूर्णपणे नाहीत. हे तंतोतंत का आहे, आणि तंतोतंत कारण सर्वकाही एका डेटा सेंटरमध्ये स्थित आहे आणि अतिशय जलद चॅनेलद्वारे कनेक्ट केलेले आहे, संपूर्ण हस्तांतरण प्रक्रिया खूप लवकर होते: सेकंदात, अगदी क्वचितच मिनिटांत, जोपर्यंत आपण काही राक्षसी विनंत्यांबद्दल बोलत नाही तोपर्यंत. त्यानुसार, मायक्रोपार्टिशन्स कॉम्प्युटिंग क्लस्टरमध्ये कॉपी केल्या जातात आणि, पूर्ण झाल्यावर, या कॉम्प्युटिंग क्लस्टरवर SQL क्वेरी कार्यान्वित केली जाते. या विनंतीचा परिणाम एक ओळ, अनेक ओळी किंवा टेबल असू शकतो - ते वापरकर्त्याला बाहेरून पाठवले जातात जेणेकरून तो ते डाउनलोड करू शकेल, त्याच्या BI टूलमध्ये प्रदर्शित करू शकेल किंवा इतर मार्गाने वापरू शकेल.

प्रत्येक SQL क्वेरी केवळ पूर्वी लोड केलेल्या डेटाचे एकत्रित वाचू शकत नाही, परंतु डेटाबेसमध्ये नवीन डेटा लोड/जनरेट देखील करू शकते. म्हणजेच, ही एक क्वेरी असू शकते जी, उदाहरणार्थ, दुसर्‍या टेबलमध्ये नवीन रेकॉर्ड समाविष्ट करते, ज्यामुळे संगणकीय क्लस्टरवर नवीन विभाजन दिसून येते, जे यामधून, एकाच S3 स्टोरेजमध्ये स्वयंचलितपणे जतन केले जाते.

वर वर्णन केलेली परिस्थिती, वापरकर्त्याच्या आगमनापासून क्लस्टर वाढवण्यापर्यंत, डेटा लोड करणे, क्वेरी कार्यान्वित करणे, परिणाम प्राप्त करणे, वाढवलेले व्हर्च्युअल कॉम्प्युटिंग क्लस्टर, व्हर्च्युअल वेअरहाऊस वापरण्याच्या मिनिटांसाठी दराने पैसे दिले जातात. दर AWS झोन आणि क्लस्टर आकारानुसार बदलतो, परंतु सरासरी ते काही डॉलर प्रति तास आहे. चार मशीनचा क्लस्टर दोन मशीनच्या क्लस्टरपेक्षा दुप्पट महाग आहे आणि आठ मशीनचा क्लस्टर अजूनही दुप्पट महाग आहे. विनंत्यांच्या जटिलतेनुसार 16, 32 मशीनचे पर्याय उपलब्ध आहेत. परंतु जेव्हा क्लस्टर प्रत्यक्षात चालू असेल तेव्हा तुम्ही फक्त त्या मिनिटांसाठी पैसे द्याल, कारण जेव्हा कोणतीही विनंत्या नसतात तेव्हा तुम्ही हात काढून टाकता आणि 5-10 मिनिटांच्या प्रतीक्षेनंतर (कॉन्फिगर करण्यायोग्य पॅरामीटर) ते स्वतःच बंद होईल, संसाधने मुक्त करा आणि मुक्त व्हा.

एक संपूर्ण वास्तववादी परिस्थिती अशी आहे की जेव्हा तुम्ही विनंती पाठवता तेव्हा क्लस्टर पॉप अप होतो, तुलनेने, एका मिनिटात, तो आणखी एक मिनिट मोजतो, नंतर बंद होण्यासाठी पाच मिनिटे मोजतो, आणि तुम्हाला या क्लस्टरच्या सात मिनिटांच्या ऑपरेशनसाठी पैसे द्यावे लागतात, आणि महिने आणि वर्षांसाठी नाही.

एकल-वापरकर्ता सेटिंगमध्ये स्नोफ्लेक वापरून वर्णन केलेली पहिली परिस्थिती. आता कल्पना करूया की बरेच वापरकर्ते आहेत, जे वास्तविक परिस्थितीच्या जवळ आहेत.

समजा आमच्याकडे बरेच विश्लेषक आणि टॅब्यू अहवाल आहेत जे आमच्या डेटाबेसवर मोठ्या संख्येने सोप्या विश्लेषणात्मक SQL क्वेरींसह सतत भडिमार करतात.

याव्यतिरिक्त, असे म्हणूया की आमच्याकडे शोधक डेटा सायंटिस्ट आहेत जे डेटासह राक्षसी गोष्टी करण्याचा प्रयत्न करीत आहेत, दहापट टेराबाइट्ससह कार्य करतात, डेटाच्या अब्जावधी आणि ट्रिलियन पंक्तींचे विश्लेषण करतात.

वर वर्णन केलेल्या दोन प्रकारच्या वर्कलोडसाठी, स्नोफ्लेक तुम्हाला वेगवेगळ्या क्षमतेचे अनेक स्वतंत्र कॉम्प्युटिंग क्लस्टर्स वाढवण्याची परवानगी देतो. शिवाय, हे संगणकीय क्लस्टर स्वतंत्रपणे कार्य करतात, परंतु सामान्य सुसंगत डेटासह.

मोठ्या संख्येने लाईट क्वेरीसाठी, तुम्ही 2-3 लहान क्लस्टर्स, प्रत्येकी 2 मशीन्स वाढवू शकता. हे वर्तन इतर गोष्टींबरोबरच, स्वयंचलित सेटिंग्ज वापरून लागू केले जाऊ शकते. म्हणून तुम्ही म्हणाल, “स्नोफ्लेक, एक लहान क्लस्टर वाढवा. जर त्यावरील भार एका विशिष्ट पॅरामीटरच्या वर वाढला तर, समान दुसरा, तिसरा वाढवा. जेव्हा भार कमी होऊ लागतो, तेव्हा जास्तीचे विझवा. त्यामुळे कितीही विश्लेषक आले आणि अहवाल बघू लागले तरी प्रत्येकाकडे पुरेशी संसाधने आहेत.

त्याच वेळी, जर विश्लेषक झोपलेले असतील आणि कोणीही अहवाल पाहत नसेल, तर क्लस्टर पूर्णपणे अंधारात जाऊ शकतात आणि तुम्ही त्यांच्यासाठी पैसे देणे थांबवाल.

त्याच वेळी, भारी प्रश्नांसाठी (डेटा वैज्ञानिकांकडून), तुम्ही 32 मशीनसाठी एक खूप मोठा क्लस्टर वाढवू शकता. या क्लस्टरला फक्त त्या मिनिटांसाठी आणि तासांसाठी पैसे दिले जातील जेव्हा तुमची विशाल विनंती तिथे चालू असेल.

वर वर्णन केलेली संधी तुम्हाला केवळ 2च नाही तर अधिक प्रकारच्या वर्कलोडचे क्लस्टर्स (ईटीएल, मॉनिटरिंग, रिपोर्ट मटेरिअलायझेशन,...) मध्ये विभागण्याची परवानगी देते.

चला स्नोफ्लेकचा सारांश घेऊया. बेस एक सुंदर कल्पना आणि कार्यक्षम अंमलबजावणी एकत्र करतो. ManyChat वर, आम्ही आमच्याकडे असलेल्या सर्व डेटाचे विश्लेषण करण्यासाठी स्नोफ्लेक वापरतो. आमच्याकडे उदाहरणाप्रमाणे तीन क्लस्टर नाहीत, परंतु 5 ते 9 पर्यंत वेगवेगळ्या आकाराचे आहेत. आमच्याकडे काही कामांसाठी पारंपारिक 16-मशीन, 2-मशीन आणि अगदी लहान 1-मशीन आहेत. ते यशस्वीरित्या भार वितरीत करतात आणि आम्हाला भरपूर बचत करण्याची परवानगी देतात.

डेटाबेस वाचन आणि लेखन लोड यशस्वीरित्या स्केल करतो. फक्त वाचन भार वाहून नेणाऱ्या त्याच “अरोरा” च्या तुलनेत हा एक मोठा फरक आणि एक मोठी प्रगती आहे. स्नोफ्लेक तुम्हाला या संगणकीय क्लस्टर्ससह तुमचा लेखन कार्यभार स्केल करण्यास अनुमती देतो. म्हणजेच, मी नमूद केल्याप्रमाणे, आम्ही ManyChat मध्ये अनेक क्लस्टर्स वापरतो, लहान आणि सुपर-स्मॉल क्लस्टर्स मुख्यतः ETL साठी, डेटा लोड करण्यासाठी वापरतात. आणि विश्लेषक आधीच मध्यम क्लस्टर्सवर राहतात, जे ईटीएल लोडमुळे पूर्णपणे प्रभावित होत नाहीत, म्हणून ते खूप लवकर कार्य करतात.

त्यानुसार, डेटाबेस OLAP कार्यांसाठी योग्य आहे. तथापि, दुर्दैवाने, ते अद्याप OLTP वर्कलोडसाठी लागू नाही. प्रथम, हा डेटाबेस स्तंभीय आहे, ज्यामध्ये पुढील सर्व परिणाम आहेत. दुसरे म्हणजे, दृष्टिकोन स्वतःच, जेव्हा प्रत्येक विनंतीसाठी, आवश्यक असल्यास, आपण संगणकीय क्लस्टर वाढवतो आणि त्यात डेटा भरतो, दुर्दैवाने, OLTP लोडसाठी अद्याप पुरेसा वेगवान नाही. OLAP कार्यांसाठी सेकंद प्रतीक्षा करणे सामान्य आहे, परंतु OLTP कार्यांसाठी ते अस्वीकार्य आहे; 100 ms चांगले होईल किंवा 10 ms आणखी चांगले होईल.

परिणाम

डेटाबेसला स्टेटलेस आणि स्टेटफुल भागांमध्ये विभाजित करून सर्व्हरलेस डेटाबेस शक्य आहे. तुमच्या लक्षात आले असेल की वरील सर्व उदाहरणांमध्ये, स्टेटफुल भाग म्हणजे, S3 मध्ये मायक्रो-पार्टिशन्स संग्रहित करणे, आणि स्टेटलेस हा ऑप्टिमायझर आहे, मेटाडेटासह कार्य करणे, सुरक्षिततेच्या समस्या हाताळणे ज्या स्वतंत्र हलक्या स्टेटलेस सेवा म्हणून उपस्थित केल्या जाऊ शकतात.

SQL क्वेरी कार्यान्वित करणे ही लाइट-स्टेट सेवा म्हणून देखील समजली जाऊ शकते जी सर्व्हरलेस मोडमध्ये पॉप अप करू शकते, जसे की स्नोफ्लेक कॉम्प्युटिंग क्लस्टर्स, फक्त आवश्यक डेटा डाउनलोड करू शकतात, क्वेरी कार्यान्वित करू शकतात आणि “बाहेर जा”.

सर्व्हरलेस प्रोडक्शन लेव्हल डेटाबेस वापरण्यासाठी आधीच उपलब्ध आहेत, ते कार्यरत आहेत. हे सर्व्हरलेस डेटाबेस OLAP कार्ये हाताळण्यासाठी आधीच तयार आहेत. दुर्दैवाने, OLTP कार्यांसाठी ते वापरले जातात... बारकावे सह, कारण मर्यादा आहेत. एकीकडे, हे एक वजा आहे. पण, दुसरीकडे, ही एक संधी आहे. कदाचित वाचकांपैकी एकाला OLTP डेटाबेस पूर्णपणे सर्व्हरलेस बनवण्याचा मार्ग सापडेल, अरोराच्या मर्यादांशिवाय.

मला आशा आहे की तुम्हाला ते मनोरंजक वाटले. सर्व्हरलेस हे भविष्य आहे :)

स्त्रोत: www.habr.com