21 व्या शतकात एसक्यूएल डेटाबेस कसा टिकवायचा: क्लाउड्स, कुबर्नेट्स आणि पोस्टग्रेएसक्यूएल मल्टीमास्टर

हॅलो, खाब्रोव्स्क रहिवासी. अभ्यासक्रमाच्या पहिल्या गटातील वर्ग आजपासून सुरू होत आहेत "पोस्टग्रेएसक्यूएल". या संदर्भात, आम्ही तुम्हाला या कोर्सवरील ओपन वेबिनार कसा झाला याबद्दल सांगू इच्छितो.

В पुढील खुला धडा आम्ही ढग आणि कुबर्नेट्सच्या युगात SQL डेटाबेसेसना येणाऱ्या आव्हानांबद्दल बोललो. त्याच वेळी, आम्ही या आव्हानांच्या प्रभावाखाली SQL डेटाबेस कसे जुळवून घेतात आणि बदलतात ते पाहिले.

वेबिनार आयोजित करण्यात आला होता व्हॅलेरी बेझ्रुकोव्ह, EPAM सिस्टीम्सवर Google क्लाउड प्रॅक्टिस डिलिव्हरी मॅनेजर.

झाडं लहान होती तेव्हा...

प्रथम, गेल्या शतकाच्या शेवटी डीबीएमएसची निवड कशी सुरू झाली हे लक्षात ठेवूया. तथापि, हे कठीण होणार नाही, कारण त्या दिवसात डीबीएमएसची निवड सुरू झाली आणि संपली ओरॅकल.

90 च्या दशकाच्या उत्तरार्धात आणि 2 च्या दशकाच्या सुरुवातीस, जेव्हा औद्योगिक स्केलेबल डेटाबेसचा विचार केला जातो तेव्हा मूलत: कोणताही पर्याय नव्हता. होय, तेथे IBM DBXNUMX, Sybase आणि काही इतर डेटाबेस होते जे आले आणि गेले, परंतु सर्वसाधारणपणे ते ओरॅकलच्या पार्श्वभूमीवर इतके लक्षणीय नव्हते. त्यानुसार, त्या काळातील अभियंत्यांची कौशल्ये अस्तित्वात असलेल्या एकमेव निवडीशी जोडलेली होती.

ओरॅकल डीबीएला सक्षम असणे आवश्यक होते:

• वितरण किटमधून ओरॅकल सर्व्हर स्थापित करा;
• ओरॅकल सर्व्हर कॉन्फिगर करा:

• init.ora;
• listener.ora;

- तयार करा:

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

- बॅकअप आणि पुनर्संचयित करा;
- निरीक्षण करा;
- सबऑप्टिमल विनंत्यांना सामोरे जा.

त्याच वेळी, ओरॅकल डीबीएकडून कोणतीही विशेष आवश्यकता नव्हती:

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

सर्वसाधारणपणे, जर आपण त्या दिवसातील निवडीबद्दल बोललो तर ते 80 च्या दशकाच्या उत्तरार्धात सोव्हिएत स्टोअरमधील निवडीसारखे दिसते:

आमची वेळ

तेव्हापासून, नक्कीच, झाडे वाढली आहेत, जग बदलले आहे आणि ते असे काहीतरी झाले:

डीबीएमएस मार्केट देखील बदलले आहे, जसे गार्टनरच्या ताज्या अहवालावरून स्पष्टपणे पाहिले जाऊ शकते:

आणि येथे हे लक्षात घेतले पाहिजे की ढग, ज्यांची लोकप्रियता वाढत आहे, त्यांनी त्यांचे स्थान व्यापले आहे. जर आपण हाच गार्टनर अहवाल वाचला तर आपल्याला पुढील निष्कर्ष दिसतील:

1. बरेच ग्राहक क्लाउडवर अनुप्रयोग हलवण्याच्या मार्गावर आहेत.
2. नवीन तंत्रज्ञान प्रथम क्लाउडमध्ये दिसून येतात आणि ते कधीही नॉन-क्लाउड इन्फ्रास्ट्रक्चरकडे जातील हे सत्य नाही.
3. पे-एज-यू-गो प्राइसिंग मॉडेल सामान्य झाले आहे. प्रत्येकाला ते जे वापरतात त्यासाठीच पैसे द्यायचे असतात आणि हा ट्रेंड देखील नाही तर फक्त वस्तुस्थितीचे विधान आहे.

आता काय?

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

निवडीच्या प्रश्नांबरोबरच आहेत मर्यादित घटक:

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

DA/DE कडून आता काय अपेक्षित आहे:

• विषय क्षेत्र आणि अनुप्रयोग आर्किटेक्चरची चांगली समज;
• हातातील कार्य लक्षात घेऊन योग्य DBMS तंत्रज्ञान योग्यरित्या निवडण्याची क्षमता;
• विद्यमान मर्यादांच्या संदर्भात निवडलेल्या तंत्रज्ञानाची अंमलबजावणी करण्यासाठी इष्टतम पद्धत निवडण्याची क्षमता;
• डेटा हस्तांतरण आणि स्थलांतर करण्याची क्षमता;
• निवडलेल्या उपायांची अंमलबजावणी आणि ऑपरेट करण्याची क्षमता.

खाली उदाहरण GCP वर आधारित डेटासह कार्य करण्यासाठी एक किंवा दुसर्या तंत्रज्ञानाची निवड त्याच्या संरचनेवर अवलंबून कशी कार्य करते हे दर्शवते:

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

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

एकूण:

1. तुम्ही जितके पुढे जाल तितकेच निवडीचा प्रश्न अधिक दाबला जाईल. आणि जरी तुम्ही फक्त GCP, व्यवस्थापित सेवा आणि SaaS कडे पाहिले तरी RDBMS चा काही उल्लेख फक्त चौथ्या पायरीवर दिसतो (आणि तिथे स्पॅनर जवळपास आहे). शिवाय, PostgreSQL ची निवड 4 व्या चरणात दिसून येते आणि त्याच्या पुढे MySQL आणि SQL सर्व्हर देखील आहेत, म्हणजे तेथे बरेच काही आहे, परंतु आपल्याला निवडावे लागेल.
2. प्रलोभनांच्या पार्श्वभूमीवर आपण निर्बंध विसरू नये. मुळात प्रत्येकाला स्पॅनर हवा असतो, पण तो महाग असतो. परिणामी, एक सामान्य विनंती असे दिसते: "कृपया आम्हाला स्पॅनर बनवा पण क्लाउड SQL च्या किमतीसाठी, तुम्ही व्यावसायिक आहात!"

आपण काय केले पाहिजे?

अंतिम सत्य असल्याचा दावा न करता, पुढील गोष्टी सांगू या:

आपण शिकण्याचा आपला दृष्टिकोन बदलला पाहिजे:

• पूर्वी ज्या प्रकारे डीबीए शिकवले जात होते त्याप्रमाणे शिकवण्यात काही अर्थ नाही;
• एका उत्पादनाचे ज्ञान यापुढे पुरेसे नाही;
• परंतु एकाच्या पातळीवर डझनभर जाणून घेणे अशक्य आहे.

आपल्याला उत्पादन किती आहे हे माहित असणे आवश्यक आहे आणि नाही, परंतु:

• त्याच्या अनुप्रयोगाचा वापर केस;
• विविध उपयोजन पद्धती;
• प्रत्येक पद्धतीचे फायदे आणि तोटे;
• माहितीपूर्ण आणि इष्टतम निवड करण्यासाठी समान आणि पर्यायी उत्पादने आणि नेहमी परिचित उत्पादनाच्या बाजूने नसतात.

तुम्हाला डेटा स्थलांतरित करण्यात आणि ETL सह एकत्रीकरणाची मूलभूत तत्त्वे समजून घेण्यास सक्षम असणे देखील आवश्यक आहे.

वास्तविक केस

अलिकडच्या काळात, मोबाईल ऍप्लिकेशनसाठी बॅकएंड तयार करणे आवश्यक होते. त्यावर काम सुरू होईपर्यंत, बॅकएंड आधीच विकसित केला गेला होता आणि अंमलबजावणीसाठी तयार होता आणि विकास संघाने या प्रकल्पावर सुमारे दोन वर्षे घालवली. खालील कार्ये सेट केली आहेत:

• सीआय/सीडी तयार करा;
• आर्किटेक्चरचे पुनरावलोकन करा;
• ते सर्व कार्यात ठेवा.

अनुप्रयोग स्वतः मायक्रोसर्व्हिसेस होता, आणि पायथन/जॅंगो कोड सुरवातीपासून आणि थेट GCP मध्ये विकसित केला गेला. लक्ष्यित प्रेक्षकांसाठी, असे गृहित धरले गेले होते की दोन प्रदेश असतील - यूएस आणि ईयू, आणि रहदारी ग्लोबल लोड बॅलेन्सरद्वारे वितरित केली गेली. सर्व वर्कलोड्स आणि कॉम्प्युट वर्कलोड Google Kubernetes Engine वर चालतात.

डेटासाठी, 3 संरचना होत्या:

• क्लाउड स्टोरेज;
• डेटास्टोअर;
• क्लाउड SQL (PostgreSQL).

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

आमच्या बाबतीत, क्लाउड SQL खालील कारणांसाठी निवडले गेले:

1. नमूद केल्याप्रमाणे, अॅप्लिकेशन जॅंगो वापरून विकसित केले गेले होते, आणि त्यात SQL डेटाबेसमधून पायथन ऑब्जेक्ट्स (जॅंगो ORM) मध्ये पर्सिस्टंट डेटा मॅप करण्यासाठी मॉडेल आहे.
2. फ्रेमवर्कने स्वतःच डीबीएमएसच्या बर्‍यापैकी मर्यादित सूचीचे समर्थन केले:

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

त्यानुसार, PostgreSQL या यादीतून ऐवजी अंतर्ज्ञानाने निवडले गेले (ठीक आहे, ते निवडण्यासाठी ओरॅकल नाही, खरोखर).

काय गहाळ होते:

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

Django स्वतः समांतरपणे अनेक डेटाबेससह कार्य करू शकतो आणि त्यांना वाचन आणि लेखनात विभागू शकतो हे असूनही, अनुप्रयोगात इतके लेखन नव्हते (90% पेक्षा जास्त वाचन आहे). आणि सर्वसाधारणपणे, आणि सर्वसाधारणपणे, हे करणे शक्य असल्यास युरोप आणि आशियातील मुख्य तळाची वाचन-प्रतिकृती, हा एक तडजोड उपाय असेल. बरं, त्यात इतके गुंतागुंतीचे काय आहे?

अडचण अशी होती की ग्राहक व्यवस्थापित सेवा आणि क्लाउड SQL वापरून सोडू इच्छित नव्हता. आणि क्लाउड SQL च्या क्षमता सध्या मर्यादित आहेत. क्लाउड SQL उच्च उपलब्धता (HA) आणि रीड प्रतिकृती (RR) ला समर्थन देते, परंतु समान RR फक्त एका प्रदेशात समर्थित आहे. अमेरिकन प्रदेशात डेटाबेस तयार केल्यावर, तुम्ही क्लाउड एसक्यूएल वापरून युरोपियन प्रदेशात वाचन प्रतिकृती बनवू शकत नाही, जरी पोस्टग्रेस स्वतः तुम्हाला हे करण्यापासून प्रतिबंधित करत नाही. Google कर्मचार्‍यांशी केलेला पत्रव्यवहार कुठेही नेला नाही आणि "आम्हाला समस्या माहित आहे आणि त्यावर काम करत आहोत, एक दिवस ही समस्या सोडवली जाईल" अशा आश्‍वासनांसह संपली.

जर आम्ही क्लाउड एसक्यूएलच्या क्षमतांची थोडक्यात यादी केली, तर ते असे दिसेल:

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

• एका प्रदेशात;
• डिस्क प्रतिकृतीद्वारे;
• PostgreSQL इंजिन वापरले जात नाहीत;
• स्वयंचलित आणि मॅन्युअल नियंत्रण शक्य - फेलओव्हर/फेलबॅक;
• स्विच करताना, DBMS अनेक मिनिटांसाठी अनुपलब्ध आहे.

2. प्रतिकृती (RR) वाचा:

• एका प्रदेशात;
• गरम स्टँडबाय;
• PostgreSQL स्ट्रीमिंग प्रतिकृती.

याव्यतिरिक्त, प्रथेप्रमाणे, तंत्रज्ञान निवडताना आपल्याला नेहमीच काही गोष्टींचा सामना करावा लागतो निर्बंध:

• GKE शिवाय ग्राहकाला संस्था निर्माण करायची आणि IaaS वापरायची नव्हती;
• ग्राहक स्वत: सेवा PostgreSQL/MySQL तैनात करू इच्छित नाही;
• बरं, सर्वसाधारणपणे, गुगल स्पॅनर त्याच्या किंमतीसाठी नसता तर अगदी योग्य असेल, तथापि, जॅंगो ORM त्याच्यासह कार्य करू शकत नाही, परंतु ही चांगली गोष्ट आहे.

परिस्थिती लक्षात घेऊन, ग्राहकाला एक फॉलो-अप प्रश्न प्राप्त झाला: "तुम्ही असे काहीतरी करू शकता जेणेकरुन ते Google Spanner सारखे असेल, परंतु Django ORM सह देखील कार्य करते?"

उपाय पर्याय क्रमांक 0

मनात आलेली पहिली गोष्ट:

• CloudSQL मध्ये रहा;
• कोणत्याही स्वरूपात प्रदेशांमध्ये अंगभूत प्रतिकृती असणार नाही;
• PostgreSQL द्वारे विद्यमान क्लाउड SQL ला प्रतिकृती जोडण्याचा प्रयत्न करा;
• कुठेतरी आणि कसा तरी PostgreSQL उदाहरण लाँच करा, परंतु किमान मास्टरला स्पर्श करू नका.

अरेरे, असे दिसून आले की हे केले जाऊ शकत नाही, कारण होस्टमध्ये प्रवेश नाही (ते पूर्णपणे वेगळ्या प्रकल्पात आहे) - pg_hba आणि असेच, आणि सुपरयूझर अंतर्गत देखील प्रवेश नाही.

उपाय पर्याय क्रमांक 1

पुढील चिंतन केल्यानंतर आणि मागील परिस्थिती लक्षात घेतल्यावर, विचारांची ट्रेन काहीशी बदलली:

• आम्‍ही अजूनही CloudSQL मध्‍ये राहण्‍याचा प्रयत्‍न करत आहोत, परंतु आम्‍ही MySQL वर स्‍विच करत आहोत, कारण MySQL च्‍या क्‍लाउड SQLमध्‍ये बाह्य मास्‍टर आहे, जे:

- बाह्य MySQL साठी प्रॉक्सी आहे;
- MySQL उदाहरणासारखे दिसते;
- इतर ढग किंवा ऑन-प्रिमाइसेसमधून डेटा स्थलांतरित करण्यासाठी शोध लावला.

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

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

उपाय पर्याय क्रमांक 2

क्लाउड SQL फ्रेमवर्कमध्ये राहणे शक्य नसल्याने, आम्ही तडजोड समाधानासाठी आवश्यकता तयार करण्याचा प्रयत्न केला. आवश्यकता खालीलप्रमाणे असल्याचे दिसून आले:

• Kubernetes मध्ये कार्य, संसाधनांचा जास्तीत जास्त वापर आणि Kubernetes (DCS, ...) आणि GCP (LB, ...) च्या क्षमता;
• HA प्रॉक्सी सारख्या क्लाउडमधील अनावश्यक गोष्टींच्या गुच्छातून गिट्टीची कमतरता;
• मुख्य HA प्रदेशात PostgreSQL किंवा MySQL चालवण्याची क्षमता; इतर क्षेत्रांमध्ये - मुख्य क्षेत्राच्या RR वरून HA आणि त्याची प्रत (विश्वसनीयतेसाठी);
• मल्टी मास्टर (मला त्याच्याशी संपर्क साधायचा नव्हता, पण ते फार महत्वाचे नव्हते)

.
या मागण्यांचा परिणाम म्हणून पीयोग्य DBMS आणि बंधनकारक पर्याय:

• मायएसक्यूएल गॅलेरा;
• झुरळ डीबी;
• PostgreSQL साधने

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

MySQL गॅलेरा

MySQL Galera तंत्रज्ञान Codership ने विकसित केले आहे आणि InnoDB साठी प्लगइन आहे. वैशिष्ठ्य:

• मल्टी मास्टर;
• समकालिक प्रतिकृती;
• कोणत्याही नोडमधून वाचन;
• कोणत्याही नोडवर रेकॉर्डिंग;
• अंगभूत HA यंत्रणा;
• Bitnami पासून एक हेल्म चार्ट आहे.

झुरळ डीबी

वर्णनानुसार, गोष्ट पूर्णपणे बॉम्ब आहे आणि गो मध्ये लिहिलेला एक ओपन सोर्स प्रोजेक्ट आहे. मुख्य सहभागी म्हणजे कॉकरोच लॅब्स (Google च्या लोकांनी स्थापन केलेल्या). हे रिलेशनल डीबीएमएस मूळतः वितरित करण्यासाठी (बॉक्सच्या बाहेर क्षैतिज स्केलिंगसह) आणि दोष-सहिष्णुतेसाठी डिझाइन केले होते. कंपनीच्या लेखकांनी "NoSQL सोल्यूशन्सशी परिचित असलेल्या क्षैतिज प्रवेशयोग्यतेसह SQL कार्यक्षमतेची समृद्धता एकत्र करणे" हे उद्दिष्ट रेखाटले आहे.

पोस्ट-ग्रेस कनेक्शन प्रोटोकॉलसाठी एक चांगला बोनस म्हणजे समर्थन.

Pgpool

हे PostgreSQL वर अॅड-ऑन आहे, खरं तर, एक नवीन संस्था जी सर्व कनेक्शन्स घेते आणि त्यावर प्रक्रिया करते. त्याचे स्वतःचे लोड बॅलन्सर आणि पार्सर आहे, जो BSD परवान्याअंतर्गत परवानाकृत आहे. हे भरपूर संधी प्रदान करते, परंतु काहीसे भितीदायक दिसते, कारण नवीन अस्तित्वाची उपस्थिती काही अतिरिक्त साहसांचे स्त्रोत बनू शकते.

संरक्षक

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

आपण शेवटी काय निवडले?

निवड सोपी नव्हती:

1. झुरळ डीबी - आग, पण गडद;
2. MySQL गॅलेरा - देखील वाईट नाही, ते बर्याच ठिकाणी वापरले जाते, परंतु MySQL;
3. Pgpool - पुष्कळ अनावश्यक घटक, क्लाउड आणि K8 सह इतके एकत्रीकरण;
4. संरक्षक - K8s सह उत्कृष्ट एकीकरण, अनावश्यक घटक नाहीत, GCP LB सह उत्तम प्रकारे एकत्रित होते.

त्यामुळे निवड पटरोनी यांच्यावर पडली.

निष्कर्ष

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

SQL साठी, SQL जगेल. याचा अर्थ असा आहे की तुम्हाला PostgreSQL आणि MySQL माहित असणे आवश्यक आहे आणि त्यांच्याबरोबर कार्य करण्यास सक्षम असणे आवश्यक आहे, परंतु त्याहूनही महत्त्वाचे म्हणजे ते योग्यरित्या वापरण्यास सक्षम असणे.

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