21 औं शताब्दीमा SQL डाटाबेस कसरी बाँच्ने: क्लाउड, कुबर्नेट्स र PostgreSQL मल्टिमास्टर

नमस्ते, Khabrovsk निवासीहरू। पाठ्यक्रमको पहिलो समूहका कक्षाहरू आजबाट सुरु हुँदैछन् "PostgreSQL"। यस सन्दर्भमा, हामी तपाईंलाई यस पाठ्यक्रममा खुला वेबिनार कसरी भयो भन्ने बारे बताउन चाहन्छौं।

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

वेबिनार आयोजना गरिएको थियो Valery Bezrukov, Google Cloud Practice Delivery Manager в EPAM Systems.

जब रुखहरु साना थिए...

पहिलो, DBMS को छनोट गत शताब्दीको अन्त्यमा कसरी सुरु भयो सम्झौं। यद्यपि, यो गाह्रो हुनेछैन, किनभने ती दिनहरूमा DBMS को छनौट सुरु भयो र समाप्त भयो बजेट.

९० को दशकको उत्तरार्ध र २००० को प्रारम्भमा, औद्योगिक स्केलेबल डाटाबेसहरूमा आउँदा अनिवार्य रूपमा कुनै विकल्प थिएन। हो, त्यहाँ IBM DB90, Sybase र केहि अन्य डाटाबेसहरू थिए जुन आए र गए, तर सामान्यतया तिनीहरू ओरेकलको पृष्ठभूमिमा त्यति ध्यान दिएनन्। तदनुसार, ती समयका इन्जिनियरहरूको सीपहरू कुनै न कुनै रूपमा अवस्थित छनोटमा बाँधिएका थिए।

ओरेकल डीबीए सक्षम हुनुपर्दछ:

• устанавливать Oracle Server из дистрибутива;
• ओरेकल सर्भर कन्फिगर गर्नुहोस्:

• init.ora;
• listener.ora;

- सिर्जना गर्नुहोस्:

• टेबलस्पेस;
• योजनाहरू;
• प्रयोगकर्ताहरू;

- ब्याकअप र पुनर्स्थापना गर्नुहोस्;
- अनुगमन गर्न;
- suboptimal अनुरोधहरु संग सम्झौता।

एकै समयमा, Oracle DBA बाट कुनै विशेष आवश्यकता थिएन:

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

सामान्यतया, यदि हामी ती दिनहरूमा छनोटको बारेमा कुरा गर्छौं भने, यो 80 को दशकको अन्त्यमा सोभियत स्टोरमा छनोटसँग मिल्दोजुल्दो छ:

हाम्रो समय

त्यसबेलादेखि, निस्सन्देह, रूखहरू बढेका छन्, संसार परिवर्तन भएको छ, र यो यस्तो भयो:

DBMS बजार पनि परिवर्तन भएको छ, गार्टनरको पछिल्लो रिपोर्टबाट स्पष्ट रूपमा देख्न सकिन्छ:

र यहाँ यो ध्यान दिनु पर्छ कि बादल, जसको लोकप्रियता बढ्दै गएको छ, आफ्नो स्थान ओगटेको छ। यदि हामीले उही गार्टनर रिपोर्ट पढ्यौं भने, हामी निम्न निष्कर्षहरू देख्नेछौं:

1. धेरै ग्राहकहरू क्लाउडमा अनुप्रयोगहरू सार्ने बाटोमा छन्।
2. नयाँ प्रविधिहरू पहिले क्लाउडमा देखा पर्छन् र तिनीहरू कहिल्यै गैर-क्लाउड पूर्वाधारमा जान्छन् भन्ने तथ्य होइन।
3. भुक्तान-जस्तै-तपाईं-जा मूल्य निर्धारण मोडेल सामान्य भएको छ। सबैजना आफूले प्रयोग गरेको कुराको लागि मात्र तिर्न चाहन्छन्, र यो प्रवृत्ति पनि होइन, तर तथ्यको बयान मात्र हो।

अब के?

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

छनोटका प्रश्नहरूसँगै, त्यहाँ पनि छन् सीमित कारकहरू:

• मूल्य। धेरै प्रविधिहरू अझै पनि पैसा खर्च गर्छन्;
• कौशल। यदि हामी नि: शुल्क सफ्टवेयरको बारेमा कुरा गर्दैछौं भने, सीपको प्रश्न उठ्छ, किनकि नि: शुल्क सफ्टवेयरले यसलाई प्रयोग गर्ने र सञ्चालन गर्ने मानिसहरूबाट पर्याप्त क्षमता चाहिन्छ;
• функционал। सबै सेवाहरू जुन क्लाउडमा उपलब्ध छन् र निर्माण गरिएका छन्, भन्नुहोस्, एउटै Postgres मा पनि, Postgres On-premises जस्तै सुविधाहरू छन्। यो एक आवश्यक कारक हो जुन जान्न र बुझ्न आवश्यक छ। यसबाहेक, यो कारक एकल DBMS को केहि लुकेका क्षमताहरूको ज्ञान भन्दा बढी महत्त्वपूर्ण हुन्छ।

अब DA/DE बाट के अपेक्षा गरिएको छ:

• विषय क्षेत्र र आवेदन वास्तुकला को राम्रो समझ;
• सही रूपमा उपयुक्त DBMS प्रविधि चयन गर्ने क्षमता, हातमा कार्यलाई ध्यानमा राख्दै;
• अवस्थित सीमितताहरूको सन्दर्भमा चयन गरिएको प्रविधि लागू गर्नको लागि इष्टतम विधि चयन गर्ने क्षमता;
• डाटा स्थानान्तरण र माइग्रेसन प्रदर्शन गर्ने क्षमता;
• умения реализовывать и эксплуатировать выбранные решения.

उदाहरण तल GCP मा आधारित डेटा संग काम गर्न को लागी एक वा अर्को प्रविधि को छनोट कसरी यसको संरचना मा निर्भर गर्दछ देखाउँछ:

Обратите внимание, что в схеме отсутствует PostgreSQL, а всё потому, что он прячется под терминологией क्लाउड SQL। र जब हामी क्लाउड SQL मा पुग्छौं, हामीले फेरि छनौट गर्न आवश्यक छ:

यो ध्यान दिनुपर्छ कि यो छनौट सधैं स्पष्ट हुँदैन, त्यसैले अनुप्रयोग विकासकर्ताहरू प्रायः अन्तर्ज्ञानद्वारा निर्देशित हुन्छन्।

कुल:

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

मैले के गर्नुपर्छ?

परम सत्य भएको दाबी नगरी, निम्न कुरा गरौं:

हामीले सिक्ने हाम्रो दृष्टिकोण परिवर्तन गर्न आवश्यक छ:

• DBA लाई पहिले जसरी सिकाइएको थियो त्यसरी सिकाउनुको कुनै अर्थ छैन;
• एक उत्पादनको ज्ञान अब पर्याप्त छैन;
• तर एकको स्तरमा दर्जनौं जान्नु असम्भव छ।

तपाईंले उत्पादन कति छ भनेर मात्र जान्न आवश्यक छ, तर:

• use case его применения;
• विभिन्न परिनियोजन विधिहरू;
• प्रत्येक विधि को लाभ र हानि;
• समान र वैकल्पिक उत्पादनहरू सूचित र इष्टतम छनौट गर्न र सधैं परिचित उत्पादनको पक्षमा हुँदैन।

А ещё нужно уметь мигрировать данные и понимать базовые принципы интеграции с ETL.

वास्तविक मामला

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

• सीआई / सीडी निर्माण;
• वास्तुकला समीक्षा;
• यो सबै सञ्चालनमा राख्नुहोस्।

अनुप्रयोग आफैंमा माइक्रोसर्भिसेस थियो, र पाइथन/ज्याङ्गो कोड स्क्र्याचबाट र सीधा GCP मा विकसित गरिएको थियो। लक्षित दर्शकहरूको लागि, यो अनुमान गरिएको थियो कि त्यहाँ दुई क्षेत्रहरू - US र EU, र यातायात ग्लोबल लोड ब्यालेन्सर मार्फत वितरण गरिएको थियो। सबै कार्यभार र गणना कार्यभार Google Kubernetes इन्जिनमा चल्यो।

डेटाको लागि, त्यहाँ 3 संरचनाहरू थिए:

• क्लाउड भण्डारण;
• डाटास्टोर;
• क्लाउड SQL (PostgreSQL)।

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

हाम्रो मामलाको लागि, क्लाउड SQL निम्न कारणहरूको लागि छनोट गरिएको थियो:

1. उल्लेख गरिए अनुसार, अनुप्रयोग Django प्रयोग गरेर विकसित गरिएको थियो, र यसमा SQL डाटाबेसबाट पाइथन वस्तुहरू (Django ORM) मा लगातार डाटा म्यापिङको लागि मोडेल छ।
2. ढाँचाले नै DBMS को एकदम सीमित सूचीलाई समर्थन गर्‍यो:

• PostgreSQL;
• मारियाडीबी;
• MySQL;
• ओरेकल;
• SQLite।

तदनुसार, PostgreSQL यस सूचीबाट बरु सहज रूपमा छनोट गरिएको थियो (राम्रो, यो Oracle छनौट गर्न होइन, वास्तवमा)।

के छुटेको थियो:

• एप्लिकेसन २ वटा क्षेत्रहरूमा मात्र प्रयोग गरिएको थियो, र तेस्रो एउटा योजना (एसिया) मा देखा पर्‍यो;
• डाटाबेस उत्तर अमेरिकी क्षेत्र (आयोवा) मा स्थित थियो;
• ग्राहकको पक्षमा सम्भावित बारेमा चिन्ता थियो पहुँच ढिलाइ युरोप र एशियाबाट र अवरोधहरू सेवामा DBMS डाउनटाइमको अवस्थामा।

При том, что сам Django может работать с несколькими БД параллельно и делить их по чтению и записи, записи в приложении было не так уж и много (более 90 % — чтение). И в общем, и в целом, если можно было сделать युरोप र एशिया मा मुख्य आधार को पढ्न-प्रतिकृति, यो एक सम्झौता समाधान हुनेछ। खैर, यसमा यति जटिल के छ?

कठिनाई यो थियो कि ग्राहक व्यवस्थित सेवाहरू र क्लाउड SQL प्रयोग गरेर छोड्न चाहँदैनन्। र क्लाउड SQL को क्षमताहरू हाल सीमित छन्। क्लाउड SQL ले उच्च उपलब्धता (HA) र Read Replica (RR) लाई समर्थन गर्दछ, तर उही RR एक क्षेत्रमा मात्र समर्थित छ। अमेरिकी क्षेत्रमा डाटाबेस सिर्जना गरिसकेपछि, तपाईंले क्लाउड SQL प्रयोग गरेर युरोपेली क्षेत्रमा पढ्ने प्रतिकृति बनाउन सक्नुहुन्न, यद्यपि Postgres आफैले तपाईंलाई यो गर्नबाट रोक्दैन। गुगलका कर्मचारीहरूसँगको पत्राचार कतै नपुगेको र "हामीलाई समस्या थाहा छ र यसमा काम गरिरहेका छौं, कुनै दिन समस्या समाधान हुनेछ" भन्ने शैलीमा वाचासहित समाप्त भयो।

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

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

• एक क्षेत्र भित्र;
• डिस्क प्रतिकृति मार्फत;
• не используются механизмы PostgreSQL;
• возможно автоматическое и ручное управление — failover/failback;
• स्विच गर्दा, DBMS धेरै मिनेटको लागि उपलब्ध छैन।

२. प्रतिकृति पढ्नुहोस् (RR):

• एक क्षेत्र भित्र;
• hot standby;
• PostgreSQL स्ट्रिमिङ प्रतिकृति।

थप रूपमा, प्रचलन अनुसार, टेक्नोलोजी छनौट गर्दा तपाईलाई सधैं केहि सामना गर्नु पर्छ प्रतिबन्धहरू:

• заказчик не хотел плодить сущности и использовать IaaS, кроме как через GKE;
• ग्राहक स्वयं सेवा PostgreSQL/MySQL प्रयोग गर्न चाहँदैनन्;
• ठीक छ, सामान्यतया, गुगल स्प्यानर एकदम उपयुक्त हुनेछ यदि यो यसको मूल्यको लागि नभएको भए, तथापि, Django ORM ले यसको साथ काम गर्न सक्दैन, तर यो राम्रो कुरा हो।

स्थितिलाई ध्यानमा राख्दै, ग्राहकले फलो-अप प्रश्न प्राप्त गर्यो: «А можете что-нибудь похожее сделать, чтобы было, как Google Spanner, но работало ещё и с Django ORM?»

समाधान विकल्प नम्बर ०

Первое, что пришло в голову:

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

अफसोस, यो बाहिरियो कि यो गर्न सकिँदैन, किनभने होस्टमा पहुँच छैन (यो पूर्ण रूपमा फरक परियोजनामा ​​​​छ) - pg_hba र यस्तै, र त्यहाँ सुपर प्रयोगकर्ता अन्तर्गत पहुँच पनि छैन।

समाधान विकल्प नम्बर ०

थप प्रतिबिम्ब र विगतका परिस्थितिहरूलाई ध्यानमा राखेर, विचारको रेल केही हदसम्म परिवर्तन भयो:

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

- बाह्य MySQL को लागि प्रोक्सी हो;
- MySQL उदाहरण जस्तो देखिन्छ;
— придуман для миграции данных из других облаков или On-premises.

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

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

समाधान विकल्प नम्बर ०

Так как остаться в рамках Cloud SQL не получилось, попытались сформулировать требования к компромиссному решению. Требования оказались следующие:

• работа в Kubernetes, максимальное использование ресурсов и возможностей Kubernetes (DCS, …) и GCP (LB, …);
• HA प्रोक्सी जस्तै क्लाउडमा अनावश्यक चीजहरूको गुच्छाबाट गिट्टीको अभाव;
• मुख्य HA क्षेत्रमा PostgreSQL वा MySQL चलाउने क्षमता; अन्य क्षेत्रहरूमा - मुख्य क्षेत्रको RR बाट HA र यसको प्रतिलिपि (विश्वसनीयताको लागि);
• multi master (связываться с ним не хотелось, но это было не очень принципиально)

.
В результате этих требований на горизонте наконец-то появились подходящие варианты СУБД и обвязки:

• MySQL Galera;
• CockroachDB;
• PostgreSQL उपकरणहरू

:
- pgpool-II;
- संरक्षक।

MySQL Galera

MySQL Galera प्रविधि Codership द्वारा विकसित गरिएको थियो र InnoDB को लागी एक प्लगइन हो। विशेषताहरु:

• बहु मास्टर;
• सिंक्रोनस प्रतिकृति;
• कुनै नोडबाट पढाइ;
• कुनै नोडमा रेकर्डिङ;
• निर्मित HA संयन्त्र;
• Bitnami बाट एक हेलम चार्ट छ।

काकरोचडीबी

По описанию вещь совершенно бомбическая и представляет собой open source-проект, написанный на Go. Основной участник — Cockroach Labs (основана выходцами из Google). Эта реляционная СУБД изначально создана быть распределённой (с горизонтальным масштабированием «из коробки») и отказоустойчивой. Её авторы из компании обозначили цель «совместить богатство функциональности SQL с горизонтальной доступностью, привычной для NoSQL-решений».

राम्रो बोनस पोस्ट-ग्रेस जडान प्रोटोकलको लागि समर्थन हो।

pgpool

यो PostgreSQL मा एक एड-अन हो, वास्तवमा, एउटा नयाँ इकाई जसले सबै जडानहरू लिन्छ र तिनीहरूलाई प्रक्रिया गर्दछ। यसको आफ्नै लोड ब्यालेन्सर र पार्सर छ, BSD लाइसेन्स अन्तर्गत इजाजतपत्र प्राप्त। यसले पर्याप्त अवसरहरू प्रदान गर्दछ, तर केही हदसम्म डरलाग्दो देखिन्छ, किनभने नयाँ निकायको उपस्थिति केही थप साहसिक कार्यहरूको स्रोत बन्न सक्छ।

संरक्षक

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

तपाईंले अन्तमा के रोज्नुभयो?

छनौट सजिलो थिएन:

1. काकरोचडीबी — огонь, но стрёмно;
2. MySQL Galera - पनि खराब छैन, यो धेरै ठाउँहरूमा प्रयोग गरिन्छ, तर MySQL;
3. pgpool - धेरै अनावश्यक संस्थाहरू, क्लाउड र K8s सँग एकीकरण;
4. संरक्षक - K8s सँग उत्कृष्ट एकीकरण, कुनै अनावश्यक संस्थाहरू छैनन्, GCP LB सँग राम्रोसँग एकीकृत हुन्छ।

यसरी, छनोट Patroni मा पर्यो।

निष्कर्ष

Пришла пора подвести краткие итоги. Да, мир ИТ-инфраструктуры существенно поменялся, и это только начало. И если раньше облака были лишь другим типом инфраструктуры, то теперь всё иначе. Мало того, инновации в облаках появляются постоянно, появляться будут и, возможно, они будут появляться только в облаках и лишь потом, силами стартапов, будут переноситься в On-premises.

SQL को लागि, SQL लाइभ हुनेछ। यसको मतलब तपाईलाई PostgreSQL र MySQL जान्न आवश्यक छ र तिनीहरूसँग काम गर्न सक्षम हुनुपर्दछ, तर अझ महत्त्वपूर्ण कुरा तिनीहरूलाई सही रूपमा प्रयोग गर्न सक्षम हुनु हो।

स्रोत: www.habr.com