21वीं सदी में SQL डेटाबेस से कैसे बचे रहें: क्लाउड, कुबेरनेट्स और पोस्टग्रेएसक्यूएल मल्टीमास्टर

नमस्कार, खाबरोवस्क निवासियों। पाठ्यक्रम के पहले समूह की कक्षाएं आज से शुरू हो रही हैं "पोस्टग्रेएसक्यूएल". इस संबंध में हम आपको बताना चाहेंगे कि इस कोर्स पर ओपन वेबिनार कैसे हुआ।

В अगला खुला पाठ हमने क्लाउड और कुबेरनेट्स के युग में SQL डेटाबेस के सामने आने वाली चुनौतियों के बारे में बात की। साथ ही, हमने देखा कि SQL डेटाबेस इन चुनौतियों के प्रभाव में कैसे अनुकूलित और परिवर्तित होते हैं।

वेबिनार आयोजित किया गया वालेरी बेज्रुकोव, EPAM सिस्टम्स में Google क्लाउड प्रैक्टिस डिलीवरी मैनेजर।

जब पेड़ छोटे थे...

सबसे पहले, आइए याद करें कि पिछली शताब्दी के अंत में DBMS का चयन कैसे शुरू हुआ। हालाँकि, यह मुश्किल नहीं होगा, क्योंकि उन दिनों DBMS का चुनाव शुरू और ख़त्म हो गया था ओरेकल.

90 के दशक के अंत और 2 के दशक की शुरुआत में, जब औद्योगिक स्केलेबल डेटाबेस की बात आती है तो अनिवार्य रूप से कोई विकल्प नहीं था। हां, IBM DBXNUMX, Sybase और कुछ अन्य डेटाबेस थे जो आए और गए, लेकिन सामान्य तौर पर वे Oracle की पृष्ठभूमि के मुकाबले इतने ध्यान देने योग्य नहीं थे। तदनुसार, उस समय के इंजीनियरों का कौशल किसी तरह अस्तित्व में मौजूद एकमात्र विकल्प से जुड़ा हुआ था।

Oracle DBA को यह करने में सक्षम होना था:

• वितरण किट से Oracle सर्वर स्थापित करें;
• Oracle सर्वर कॉन्फ़िगर करें:

• init.ora;
• श्रोता.ओरा;

- बनाएं:

• मेज़स्थान;
• योजना;
• उपयोगकर्ता;

- बैकअप करें और पुनर्स्थापित करें;
- निगरानी करना;
- उप-इष्टतम अनुरोधों से निपटें।

उसी समय, Oracle DBA से कोई विशेष आवश्यकता नहीं थी:

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

सामान्य तौर पर, अगर हम उन दिनों की पसंद के बारे में बात करते हैं, तो यह 80 के दशक के अंत में एक सोवियत स्टोर की पसंद जैसा दिखता है:

हमारा समय

तब से, निस्संदेह, पेड़ बड़े हो गए हैं, दुनिया बदल गई है, और यह कुछ इस तरह बन गई है:

डीबीएमएस बाजार भी बदल गया है, जैसा कि गार्टनर की नवीनतम रिपोर्ट से स्पष्ट रूप से देखा जा सकता है:

और यहां यह ध्यान दिया जाना चाहिए कि बादलों, जिनकी लोकप्रियता बढ़ रही है, ने अपना स्थान ले लिया है। यदि हम उसी गार्टनर रिपोर्ट को पढ़ें, तो हम निम्नलिखित निष्कर्ष देखेंगे:

1. कई ग्राहक एप्लिकेशन को क्लाउड पर ले जाने की राह पर हैं।
2. नई प्रौद्योगिकियां सबसे पहले क्लाउड में दिखाई देती हैं और यह सच नहीं है कि वे कभी भी गैर-क्लाउड बुनियादी ढांचे में चले जाएंगे।
3. भुगतान करते ही मूल्य निर्धारण मॉडल आम हो गया है। हर कोई केवल उसी चीज़ के लिए भुगतान करना चाहता है जिसका वे उपयोग करते हैं, और यह कोई प्रवृत्ति भी नहीं है, बल्कि केवल तथ्य का एक बयान है।

अब क्या

आज हम सब सातवें आसमान पर हैं. और जो प्रश्न हमारे सामने उठते हैं वे पसंद के प्रश्न हैं। और यह बहुत बड़ा है, भले ही हम केवल ऑन-प्रिमाइसेस प्रारूप में डीबीएमएस प्रौद्योगिकियों की पसंद के बारे में बात करें। हमारे पास प्रबंधित सेवाएँ और SaaS भी हैं। इस प्रकार, चुनाव हर साल और अधिक कठिन होता जाता है।

साथ ही पसंद के सवाल भी हैं सीमित करने वाले कारक:

• कीमत. कई प्रौद्योगिकियों में अभी भी पैसे खर्च होते हैं;
• कौशल. यदि हम मुफ़्त सॉफ़्टवेयर के बारे में बात कर रहे हैं, तो कौशल का प्रश्न उठता है, क्योंकि मुफ़्त सॉफ़्टवेयर के लिए इसे तैनात और संचालित करने वाले लोगों से पर्याप्त योग्यता की आवश्यकता होती है;
• कार्यात्मक. सभी सेवाएं जो क्लाउड में उपलब्ध हैं और निर्मित हैं, यहां तक ​​कि एक ही पोस्टग्रेज पर भी, पोस्टग्रेज ऑन-प्रिमाइसेस जैसी ही सुविधाएं नहीं हैं। यह एक आवश्यक कारक है जिसे जानने और समझने की आवश्यकता है। इसके अलावा, यह कारक किसी एकल DBMS की कुछ छिपी हुई क्षमताओं के ज्ञान से भी अधिक महत्वपूर्ण हो जाता है।

अब DA/DE से क्या अपेक्षा है:

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

नीचे उदाहरण जीसीपी पर आधारित दर्शाता है कि डेटा के साथ काम करने के लिए एक या दूसरी तकनीक का चुनाव उसकी संरचना के आधार पर कैसे काम करता है:

कृपया ध्यान दें कि PostgreSQL स्कीमा में शामिल नहीं है, और ऐसा इसलिए है क्योंकि यह शब्दावली के अंतर्गत छिपा हुआ है क्लाउड एसक्यूएल. और जब हम क्लाउड एसक्यूएल पर पहुंचते हैं, तो हमें फिर से एक विकल्प चुनना होगा:

यह ध्यान दिया जाना चाहिए कि यह विकल्प हमेशा स्पष्ट नहीं होता है, इसलिए एप्लिकेशन डेवलपर्स को अक्सर अंतर्ज्ञान द्वारा निर्देशित किया जाता है।

कुल:

1. आप जितना आगे बढ़ेंगे, चयन का प्रश्न उतना ही अधिक महत्वपूर्ण होता जाएगा। और यहां तक ​​कि अगर आप केवल जीसीपी, प्रबंधित सेवाओं और सास को देखते हैं, तो आरडीबीएमएस का कुछ उल्लेख केवल चौथे चरण पर दिखाई देता है (और वहां स्पैनर पास में है)। साथ ही, 4वें चरण में PostgreSQL का विकल्प दिखाई देता है, और इसके आगे MySQL और SQL सर्वर भी होते हैं, यानी हर चीज़ में बहुत कुछ है, लेकिन आपको चुनना होगा.
2. हमें प्रलोभनों की पृष्ठभूमि में प्रतिबंधों के बारे में नहीं भूलना चाहिए। मूलतः हर कोई स्पैनर चाहता है, लेकिन यह महंगा है। परिणामस्वरूप, एक सामान्य अनुरोध कुछ इस तरह दिखता है: "कृपया हमें एक स्पैनर बनाएं, लेकिन क्लाउड एसक्यूएल की कीमत के लिए, आप पेशेवर हैं!"

मुझे क्या करना चाहिए?

अंतिम सत्य होने का दावा किए बिना, आइए निम्नलिखित कहें:

हमें सीखने के प्रति अपना दृष्टिकोण बदलने की जरूरत है:

• जिस तरह से डीबीए पहले पढ़ाए जाते थे, उसे पढ़ाने का कोई मतलब नहीं है;
• एक उत्पाद का ज्ञान अब पर्याप्त नहीं है;
• लेकिन एक के स्तर पर दर्जनों को जानना असंभव है।

आपको न केवल यह जानना होगा कि उत्पाद कितना है, बल्कि:

• इसके अनुप्रयोग का उपयोग मामला;
• विभिन्न परिनियोजन विधियाँ;
• प्रत्येक विधि के फायदे और नुकसान;
• एक सूचित और इष्टतम विकल्प बनाने के लिए समान और वैकल्पिक उत्पाद और हमेशा किसी परिचित उत्पाद के पक्ष में नहीं।

आपको डेटा स्थानांतरित करने और ईटीएल के साथ एकीकरण के बुनियादी सिद्धांतों को समझने में भी सक्षम होना चाहिए।

असली मामला

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

• सीआई/सीडी बनाएं;
• वास्तुकला की समीक्षा करें;
• यह सब कार्यान्वित करें।

एप्लिकेशन स्वयं माइक्रोसर्विसेज था, और Python/Django कोड को स्क्रैच से और सीधे GCP में विकसित किया गया था। लक्षित दर्शकों के लिए, यह मान लिया गया था कि दो क्षेत्र होंगे - यूएस और ईयू, और ट्रैफ़िक को ग्लोबल लोड बैलेंसर के माध्यम से वितरित किया गया था। सभी वर्कलोड और कंप्यूट वर्कलोड Google Kubernetes इंजन पर चलते थे।

जहां तक ​​डेटा का सवाल है, वहां 3 संरचनाएं थीं:

• घन संग्रहण;
• डेटा भंडारण;
• क्लाउड एसक्यूएल (पोस्टग्रेएसक्यूएल)।

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

जहां तक ​​हमारे मामले की बात है, क्लाउड SQL को निम्नलिखित कारणों से चुना गया था:

1. जैसा कि उल्लेख किया गया है, एप्लिकेशन को Django का उपयोग करके विकसित किया गया था, और इसमें SQL डेटाबेस से Python ऑब्जेक्ट्स (Django ORM) में लगातार डेटा मैप करने के लिए एक मॉडल है।
2. फ़्रेमवर्क स्वयं DBMSs की एक काफी सीमित सूची का समर्थन करता है:

• पोस्टग्रेएसक्यूएल;
• मारियाडीबी;
• माई एसक्यूएल;
• आकाशवाणी;
• SQLite.

तदनुसार, PostgreSQL को इस सूची से काफी सहजता से चुना गया था (वास्तव में, यह चुनने के लिए Oracle नहीं है)।

क्या छूट रहा है:

• एप्लिकेशन को केवल 2 क्षेत्रों में तैनात किया गया था, और तीसरा योजनाओं (एशिया) में दिखाई दिया;
• डेटाबेस उत्तरी अमेरिकी क्षेत्र (आयोवा) में स्थित था;
• ग्राहक की ओर से संभावित के बारे में चिंताएं थीं पहुंच में देरी यूरोप और एशिया से और रुकावट सेवा में DBMS डाउनटाइम के मामले में.

इस तथ्य के बावजूद कि Django स्वयं कई डेटाबेस के साथ समानांतर में काम कर सकता है और उन्हें पढ़ने और लिखने में विभाजित कर सकता है, एप्लिकेशन में इतना लेखन नहीं था (90% से अधिक पढ़ रहा है)। और सामान्य तौर पर, और सामान्य तौर पर, यदि ऐसा करना संभव होता पढ़ें-यूरोप और एशिया में मुख्य आधार की प्रतिकृति, यह एक समझौता समाधान होगा. खैर, इसमें इतना जटिल क्या है?

कठिनाई यह थी कि ग्राहक प्रबंधित सेवाओं और क्लाउड SQL का उपयोग छोड़ना नहीं चाहता था। और क्लाउड SQL की क्षमताएँ वर्तमान में सीमित हैं। क्लाउड SQL उच्च उपलब्धता (HA) और रीड रेप्लिका (RR) का समर्थन करता है, लेकिन वही RR केवल एक क्षेत्र में समर्थित है। अमेरिकी क्षेत्र में एक डेटाबेस बनाने के बाद, आप क्लाउड SQL का उपयोग करके यूरोपीय क्षेत्र में एक रीड प्रतिकृति नहीं बना सकते हैं, हालाँकि Postgres स्वयं आपको ऐसा करने से नहीं रोकता है। Google कर्मचारियों के साथ पत्राचार का कोई परिणाम नहीं निकला और "हम समस्या को जानते हैं और इस पर काम कर रहे हैं, किसी दिन समस्या का समाधान हो जाएगा" की शैली में वादों के साथ समाप्त हो गया।

यदि हम क्लाउड SQL की क्षमताओं को संक्षेप में सूचीबद्ध करें, तो यह कुछ इस तरह दिखाई देगी:

1. उच्च उपलब्धता (एचए):

• एक क्षेत्र के भीतर;
• डिस्क प्रतिकृति के माध्यम से;
• PostgreSQL इंजन का उपयोग नहीं किया जाता है;
• स्वचालित और मैन्युअल नियंत्रण संभव - फेलओवर/फेलबैक;
• स्विच करते समय, DBMS कई मिनटों तक अनुपलब्ध रहता है।

2. प्रतिकृति पढ़ें (आरआर):

• एक क्षेत्र के भीतर;
• गर्म स्टैंडबाय;
• PostgreSQL स्ट्रीमिंग प्रतिकृति।

इसके अलावा, जैसा कि प्रथागत है, कोई तकनीक चुनते समय आपको हमेशा कुछ का सामना करना पड़ता है सीमाओं:

• ग्राहक GKE को छोड़कर, इकाइयाँ बनाना और IaaS का उपयोग नहीं करना चाहता था;
• ग्राहक स्वयं सेवा PostgreSQL/MySQL तैनात नहीं करना चाहेगा;
• खैर, सामान्य तौर पर, Google स्पैनर काफी उपयुक्त होता अगर इसकी कीमत नहीं होती, हालाँकि, Django ORM इसके साथ काम नहीं कर सकता, लेकिन यह एक अच्छी बात है।

स्थिति को ध्यान में रखते हुए, ग्राहक को एक अनुवर्ती प्रश्न प्राप्त हुआ: "क्या आप ऐसा कुछ कर सकते हैं ताकि यह Google स्पैनर की तरह हो, लेकिन Django ORM के साथ भी काम करे?"

समाधान विकल्प क्रमांक 0

पहली बात जो मन में आई:

• CloudSQL के भीतर रहें;
• किसी भी रूप में क्षेत्रों के बीच कोई अंतर्निहित प्रतिकृति नहीं होगी;
• PostgreSQL द्वारा मौजूदा क्लाउड SQL में एक प्रतिकृति संलग्न करने का प्रयास करें;
• किसी पोस्टग्रेएसक्यूएल इंस्टेंस को कहीं और किसी तरह लॉन्च करें, लेकिन कम से कम मास्टर को न छुएं।

अफसोस, यह पता चला कि ऐसा नहीं किया जा सकता, क्योंकि होस्ट तक कोई पहुंच नहीं है (यह पूरी तरह से एक अलग परियोजना में है) - pg_hba और इसी तरह, और सुपरयूजर के तहत भी कोई पहुंच नहीं है।

समाधान विकल्प क्रमांक 1

आगे विचार करने और पिछली परिस्थितियों को ध्यान में रखने के बाद, विचार की प्रक्रिया कुछ हद तक बदल गई:

• हम अभी भी CloudSQL के भीतर रहने की कोशिश कर रहे हैं, लेकिन हम MySQL पर स्विच कर रहे हैं, क्योंकि MySQL द्वारा क्लाउड SQL में एक बाहरी मास्टर है, जो:

- बाहरी MySQL के लिए एक प्रॉक्सी है;
- एक MySQL उदाहरण जैसा दिखता है;
- अन्य क्लाउड या ऑन-प्रिमाइसेस से डेटा स्थानांतरित करने के लिए आविष्कार किया गया।

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

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

समाधान विकल्प क्रमांक 2

चूंकि क्लाउड SQL ढांचे के भीतर रहना संभव नहीं था, इसलिए हमने एक समझौता समाधान के लिए आवश्यकताओं को तैयार करने का प्रयास किया। आवश्यकताएँ निम्नलिखित निकलीं:

• कुबेरनेट्स में काम, कुबेरनेट्स (डीसीएस, ...) और जीसीपी (एलबी, ...) के संसाधनों और क्षमताओं का अधिकतम उपयोग;
• क्लाउड में HA प्रॉक्सी जैसी अनावश्यक चीजों के समूह से गिट्टी की कमी;
• मुख्य HA क्षेत्र में PostgreSQL या MySQL चलाने की क्षमता; अन्य क्षेत्रों में - मुख्य क्षेत्र के आरआर से एचए प्लस इसकी प्रतिलिपि (विश्वसनीयता के लिए);
• मल्टी मास्टर (मैं उससे संपर्क नहीं करना चाहता था, लेकिन यह बहुत महत्वपूर्ण नहीं था)

.
इन मांगों के परिणामस्वरूप, पउपयुक्त DBMS और बाइंडिंग विकल्प:

• MySQL गैलेरा;
• कॉकरोचडीबी;
• पोस्टग्रेएसक्यूएल उपकरण

:
- पीजीपूल-द्वितीय;
- पेट्रोनी.

MySQL गैलेरा

MySQL गैलेरा तकनीक कोडरशिप द्वारा विकसित की गई थी और यह InnoDB के लिए एक प्लगइन है। ख़ासियतें:

• मल्टी मास्टर;
• तुल्यकालिक प्रतिकृति;
• किसी भी नोड से पढ़ना;
• किसी भी नोड पर रिकॉर्डिंग;
• अंतर्निर्मित एचए तंत्र;
• बिटनामी का एक हेल्म चार्ट है।

कॉकरोचडीबी

विवरण के अनुसार, यह चीज़ बिल्कुल बम है और गो में लिखा गया एक ओपन सोर्स प्रोजेक्ट है। मुख्य भागीदार कॉकरोच लैब्स (Google के लोगों द्वारा स्थापित) है। यह संबंधपरक DBMS मूल रूप से वितरित (बॉक्स के बाहर क्षैतिज स्केलिंग के साथ) और दोष-सहिष्णु के लिए डिज़ाइन किया गया था। कंपनी के इसके लेखकों ने "NoSQL समाधानों से परिचित क्षैतिज पहुंच के साथ SQL कार्यक्षमता की समृद्धि को संयोजित करने" के लक्ष्य को रेखांकित किया।

एक अच्छा बोनस पोस्ट-ग्रेस कनेक्शन प्रोटोकॉल के लिए समर्थन है।

पीजीपूल

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

संरक्षक

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

आख़िर में आपने क्या चुना?

चुनाव आसान नहीं था:

1. कॉकरोचडीबी - आग, लेकिन अंधेरा;
2. MySQL गैलेरा - यह भी बुरा नहीं है, इसका उपयोग कई जगहों पर किया जाता है, लेकिन MySQL;
3. पीजीपूल - बहुत सारी अनावश्यक इकाइयाँ, क्लाउड और K8s के साथ इतना एकीकरण;
4. संरक्षक - K8s के साथ उत्कृष्ट एकीकरण, कोई अनावश्यक इकाई नहीं, GCP LB के साथ अच्छी तरह से एकीकृत होता है।

इस प्रकार, चुनाव पेट्रोनी पर आ गया।

निष्कर्ष

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

जहाँ तक SQL की बात है, SQL जीवित रहेगा। इसका मतलब है कि आपको PostgreSQL और MySQL को जानना होगा और उनके साथ काम करने में सक्षम होना होगा, लेकिन इससे भी अधिक महत्वपूर्ण है उनका सही ढंग से उपयोग करने में सक्षम होना।

स्रोत: www.habr.com