सर्भरलेस डाटाबेसको बाटोमा - कसरी र किन

नमस्ते सबै! मेरो नाम गोलोभ निकोले हो। पहिले, मैले Avito मा काम गरें र छ वर्षसम्म डाटा प्लेटफर्म व्यवस्थापन गरें, त्यो हो, मैले सबै डाटाबेसमा काम गरें: विश्लेषणात्मक (Vertica, ClickHouse), स्ट्रिमिङ र OLTP (Redis, Tarantool, VoltDB, MongoDB, PostgreSQL)। यस समयमा, मैले धेरै संख्यामा डेटाबेसहरू - धेरै फरक र असामान्य, र तिनीहरूको प्रयोगको गैर-मानक केसहरूसँग व्यवहार गरें।

म हाल ManyChat मा काम गर्दैछु। संक्षेपमा, यो एक स्टार्टअप हो - नयाँ, महत्वाकांक्षी र द्रुत रूपमा बढ्दै। र जब म पहिलो पटक कम्पनीमा सामेल भएँ, एक क्लासिक प्रश्न उठ्यो: "युवा स्टार्टअपले अब DBMS र डाटाबेस बजारबाट के लिनुपर्छ?"

यस लेखमा, मेरो रिपोर्टमा आधारित अनलाइन उत्सव RIT++ 2020, म यो प्रश्नको जवाफ दिनेछु। रिपोर्ट को एक भिडियो संस्करण मा उपलब्ध छ YouTube.

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

यो 2020 हो, मैले वरिपरि हेरे र तीन प्रकारका डाटाबेसहरू देखे।

पहिलो प्रकार - क्लासिक OLTP डाटाबेसहरू: PostgreSQL, SQL Server, Oracle, MySQL। तिनीहरू धेरै पहिले लेखिएका थिए, तर अझै पनि सान्दर्भिक छन् किनभने तिनीहरू विकासकर्ता समुदायलाई धेरै परिचित छन्।

दोस्रो प्रकार हो "शून्य" बाट आधारहरू। तिनीहरूले SQL, परम्परागत संरचनाहरू र ACID छोडेर, अन्तर्निहित शार्डिङ र अन्य आकर्षक सुविधाहरू थपेर क्लासिक ढाँचाबाट टाढा जान प्रयास गरे। उदाहरण को लागी, यो Cassandra, MongoDB, Redis वा Tarantool हो। यी सबै समाधानहरूले बजारलाई मौलिक रूपमा केही नयाँ प्रस्ताव गर्न चाहन्थे र तिनीहरूको स्थान ओगटेका थिए किनभने तिनीहरू निश्चित कार्यहरूको लागि अत्यन्त सुविधाजनक हुन पुगे। म यी डाटाबेसहरूलाई छाता शब्द NOSQL सँग बुझाउनेछु।

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

त्यस्ता डाटाबेसका उदाहरणहरू:

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

यी मूलतया पुराना डाटाबेसहरू हुन्, तर हार्डवेयरसँग काम नगरी व्यवस्थित वातावरणमा उठाइएका छन्।

नोट। उदाहरणहरू AWS वातावरणका लागि लिइएका छन्, तर तिनीहरूका एनालगहरू Microsoft Azure, Google Cloud, वा Yandex.Cloud मा पनि अवस्थित छन्।

यसमा नयाँ के छ? 2020 मा, यी मध्ये कुनै पनि।

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

2020 मा बजारमा वास्तवमै नयाँ के छ सर्भरलेस वा सर्भरलेस समाधानहरू।

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

अरू कुनै उपाय छ? सर्भर रहित सेवाहरु संग तपाईं सक्नुहुन्छ।

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

म तस्विरहरु संग यो दृष्टिकोण चित्रण गर्ने प्रयास गर्नेछु।


क्लासिक परिनियोजन। हामीसँग निश्चित भारको सेवा छ। हामी दुईवटा उदाहरणहरू उठाउँछौं: भौतिक सर्भरहरू वा AWS मा उदाहरणहरू। बाह्य अनुरोधहरू यी उदाहरणहरूमा पठाइन्छ र त्यहाँ प्रशोधन गरिन्छ।

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

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

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

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

यी सबै डाटाबेसहरूको साझा सीमा के हो? यी निरन्तर प्रयोग हुने क्लाउड वा हार्डवेयर सर्भर (वा धेरै सर्भर) को लागतहरू हुन्। हामीले क्लासिक वा व्यवस्थित डाटाबेस प्रयोग गर्छौं वा छैन भन्ने कुराले फरक पार्दैन, हामीसँग Devops र प्रशासक छ वा छैन, हामी अझै पनि हार्डवेयर, बिजुली र डाटा केन्द्र भाडा 24/7 को लागि भुक्तानी गर्छौं। यदि हामीसँग क्लासिक आधार छ भने, हामी मालिक र दासको लागि भुक्तान गर्छौं। यदि यो अत्यधिक लोड गरिएको शर्डेड डाटाबेस हो भने, हामी 10, 20 वा 30 सर्भरहरूको लागि भुक्तान गर्छौं, र हामी निरन्तर भुक्तान गर्छौं।

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

सर्भरलेस डाटाबेस - सिद्धान्त

२०२० को प्रश्न: के डाटाबेस सर्भरलेस पनि बनाउन सम्भव छ? सबैले सर्भरलेस ब्याकइन्डको बारेमा सुनेका छन्... डाटाबेसलाई सर्भररहित बनाउने प्रयास गरौं?

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

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

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

OLAP समाधानहरूको लागि सर्भरलेस

व्यावहारिक उदाहरणहरू प्रयोग गरेर स्टेटफुल र स्टेटलेस भागहरूमा डाटाबेस काट्दा कस्तो देखिन्छ हेरौं।

उदाहरणका लागि, हामीसँग विश्लेषणात्मक डाटाबेस छ: बाह्य डाटा (बायाँमा रातो सिलिन्डर), डाटाबेसमा डाटा लोड गर्ने ETL प्रक्रिया, र डाटाबेसमा SQL क्वेरीहरू पठाउने विश्लेषक। यो एक क्लासिक डाटा गोदाम सञ्चालन योजना हो।

यस योजनामा, ETL सशर्त रूपमा एक पटक प्रदर्शन गरिएको छ। त्यसोभए तपाईले निरन्तर सर्भरहरूको लागि भुक्तान गर्न आवश्यक छ जसमा डाटाबेस ETL भरिएको डाटासँग चल्छ, ताकि त्यहाँ प्रश्नहरू पठाउनको लागि केहि छ।

AWS Athena Serverless मा लागू गरिएको वैकल्पिक दृष्टिकोण हेरौं। त्यहाँ कुनै स्थायी रूपमा समर्पित हार्डवेयर छैन जसमा डाउनलोड गरिएको डाटा भण्डारण गरिन्छ। यसको सट्टा:

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

यस वास्तुकलामा, हामीले अनुरोध कार्यान्वयन गर्ने प्रक्रियाको लागि मात्र भुक्तानी गर्छौं। कुनै अनुरोध छैन - कुनै लागत छैन।

यो एक काम गर्ने दृष्टिकोण हो र एथेना सर्भरलेस मात्र होइन, तर रेडशिफ्ट स्पेक्ट्रम (AWS मा) मा पनि लागू हुन्छ।

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

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

OLTP समाधानहरूको लागि सर्भरलेस

अघिल्लो उदाहरणले OLAP (विश्लेषणात्मक) कार्यहरू हेर्यो। अब OLTP कार्यहरू हेरौं।

स्केलेबल PostgreSQL वा MySQL कल्पना गरौं। न्यूनतम स्रोतहरूसँग नियमित व्यवस्थित उदाहरण PostgreSQL वा MySQL उठाउनुहोस्। जब उदाहरणले अधिक लोड प्राप्त गर्दछ, हामी अतिरिक्त प्रतिकृतिहरू जडान गर्नेछौं जसमा हामी पठन लोडको अंश वितरण गर्नेछौं। यदि त्यहाँ कुनै अनुरोध वा लोड छैन भने, हामी प्रतिकृतिहरू बन्द गर्छौं। पहिलो उदाहरण मास्टर हो, र बाँकी प्रतिकृतिहरू हुन्।

यो विचार Aurora Serverless AWS भनिने डेटाबेसमा लागू गरिएको छ। सिद्धान्त सरल छ: बाह्य अनुप्रयोगहरूबाट अनुरोधहरू प्रोक्सी फ्लीट द्वारा स्वीकार गरिन्छ। लोड बढेको देखेर, यसले पूर्व-तातो न्यूनतम उदाहरणहरूबाट कम्प्युटिङ स्रोतहरू आवंटित गर्दछ - जडान सकेसम्म चाँडो बनाइन्छ। असक्षम गर्ने उदाहरणहरू उस्तै तरिकामा हुन्छ।

Aurora भित्र Aurora क्षमता एकाइ, 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 मिनेटको प्रतीक्षा पछि (एक कन्फिगर योग्य प्यारामिटर) यो आफैं बन्द हुनेछ, स्रोतहरू खाली गर्नुहोस् र स्वतन्त्र बन्नुहोस्।

एक पूर्ण यथार्थपरक परिदृश्य हो जब तपाइँ अनुरोध पठाउनुहुन्छ, क्लस्टर पप अप हुन्छ, तुलनात्मक रूपमा बोल्दै, एक मिनेटमा, यसले अर्को मिनेट गणना गर्छ, त्यसपछि बन्द गर्न पाँच मिनेट, र तपाइँले यो क्लस्टरको सञ्चालनको सात मिनेटको लागि भुक्तान गर्नुहुन्छ, र महिना र वर्षको लागि होइन।

एकल-प्रयोगकर्ता सेटिङमा स्नोफ्लेक प्रयोग गरी वर्णन गरिएको पहिलो परिदृश्य। अब कल्पना गरौं कि त्यहाँ धेरै प्रयोगकर्ताहरू छन्, जुन वास्तविक परिदृश्यको नजिक छ।

मानौं हामीसँग धेरै विश्लेषकहरू र Tableau रिपोर्टहरू छन् जसले हाम्रो डाटाबेसलाई धेरै संख्यामा साधारण विश्लेषणात्मक SQL प्रश्नहरूको साथ निरन्तर बमबारी गर्दछ।

थप रूपमा, मानौं कि हामीसँग आविष्कारशील डाटा वैज्ञानिकहरू छन् जसले डाटाको साथ राक्षसी चीजहरू गर्न कोशिस गरिरहेका छन्, दशौं टेराबाइटहरूसँग काम गर्छन्, डाटाका अरबौं र ट्रिलियन पङ्क्तिहरू विश्लेषण गर्छन्।

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

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

एकै समयमा, यदि विश्लेषकहरू सुतिरहेका छन् र रिपोर्टहरू कसैले हेर्दैनन् भने, क्लस्टरहरू पूर्णतया अँध्यारो हुन सक्छन्, र तपाईंले तिनीहरूको लागि भुक्तान गर्न छोड्नुहुन्छ।

एकै समयमा, भारी प्रश्नहरूको लागि (डेटा वैज्ञानिकहरूबाट), तपाईंले 32 मेसिनहरूको लागि एउटा धेरै ठूलो क्लस्टर उठाउन सक्नुहुन्छ। यो क्लस्टर पनि ती मिनेट र घण्टाको लागि भुक्तान गरिनेछ जब तपाईंको विशाल अनुरोध त्यहाँ चलिरहेको छ।

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

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

डाटाबेसले पढ्ने र लेख्ने लोडलाई सफलतापूर्वक मापन गर्दछ। यो एउटै "अरोरा" को तुलनामा ठूलो भिन्नता र ठूलो सफलता हो, जसले पढ्ने भार मात्र बोक्छ। स्नोफ्लेकले तपाइँलाई यी कम्प्युटिङ क्लस्टरहरूसँग तपाइँको लेखन कार्यभार मापन गर्न अनुमति दिन्छ। त्यो हो, मैले उल्लेख गरे अनुसार, हामी ManyChat मा धेरै क्लस्टरहरू प्रयोग गर्छौं, साना र सुपर-साना क्लस्टरहरू मुख्य रूपमा ETL को लागि, डाटा लोड गर्नका लागि प्रयोग गरिन्छ। र विश्लेषकहरू पहिले नै मध्यम क्लस्टरहरूमा बस्छन्, जुन ETL लोडबाट पूर्ण रूपमा प्रभावित हुँदैनन्, त्यसैले तिनीहरू धेरै छिटो काम गर्छन्।

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

परिणाम

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

SQL क्वेरीहरू कार्यान्वयन गर्ने लाई लाइट-स्टेट सेवाहरूको रूपमा पनि बुझ्न सकिन्छ जुन सर्भरलेस मोडमा पप अप गर्न सक्छ, जस्तै स्नोफ्लेक कम्प्युटिङ क्लस्टरहरू, आवश्यक डेटा मात्र डाउनलोड गर्नुहोस्, क्वेरी कार्यान्वयन गर्नुहोस् र "बाहिर जानुहोस्।"

सर्भरलेस उत्पादन स्तर डाटाबेसहरू पहिले नै प्रयोगको लागि उपलब्ध छन्, तिनीहरू काम गरिरहेका छन्। यी सर्भररहित डाटाबेसहरू OLAP कार्यहरू ह्यान्डल गर्न पहिले नै तयार छन्। दुर्भाग्यवश, OLTP कार्यहरूको लागि तिनीहरू प्रयोग गरिन्छ... बारीकताहरू सहित, किनकि त्यहाँ सीमितताहरू छन्। एकातिर, यो माइनस हो। तर, अर्कोतर्फ, यो अवसर हो। हुनसक्छ पाठकहरू मध्ये एकले अरोराको सीमाहरू बिना, OLTP डाटाबेसलाई पूर्ण रूपमा सर्भरलेस बनाउने तरिका फेला पार्नुहुनेछ।

मलाई आशा छ तपाईंले यो रोचक पाउनुभयो। सर्भरलेस भविष्य हो :)

स्रोत: www.habr.com