Kuidas SQL-andmebaas 21. sajandil ellu jääda: pilved, Kubernetes ja PostgreSQL multimaster

Tere, Habrovski elanikud. Täna algavad tunnid kursuse esimeses rühmas "PostgreSQL". Sellega seoses tahaksime teile rääkida, kuidas selle kursuse avatud veebiseminar toimus.

В järgmine avatud õppetund rääkisime väljakutsetest, millega SQL-andmebaasid pilvede ja Kubernetese ajastul silmitsi seisavad. Samal ajal uurisime, kuidas SQL-andmebaasid nende väljakutsete mõjul kohanduvad ja muteeruvad.

Veebiseminar peeti Valeri Bezrukov, Google Cloud Practice Delivery Manager ettevõttes EPAM Systems.

Kui puud olid väikesed...

Kõigepealt meenutagem, kuidas sai alguse DBMS-i valik eelmise sajandi lõpus. See pole aga keeruline, sest DBMS-i valik neil päevil algas ja lõppes Oraakel.

90ndate lõpus ja 2ndate alguses ei olnud tööstuslike skaleeritavate andmebaaside osas sisuliselt valikut. Jah, oli IBM DBXNUMX, Sybase ja mõned teised andmebaasid, mis tulid ja läksid, kuid üldiselt ei olnud need Oracle'i taustal nii märgatavad. Sellest tulenevalt olid nende aegade inseneride oskused kuidagi seotud ainsa olemasoleva valikuga.

Oracle DBA pidi suutma:

• installige Oracle Server turustuskomplektist;
• konfigureerige Oracle Server:

• init.ora;
• kuulaja.ora;

- luua:

• lauapinnad;
• skeemid;
• kasutajad;

— varundada ja taastada;
— teostada järelevalvet;
— tegelema mitteoptimaalsete taotlustega.

Samal ajal ei esitanud Oracle DBA erinõuet:

• oskama valida andmete salvestamiseks ja töötlemiseks optimaalset DBMS-i või muud tehnoloogiat;
• pakkuda kõrget kättesaadavust ja horisontaalset skaleeritavust (see ei olnud alati DBA probleem);
• hea ainevaldkonna, infrastruktuuri, rakenduste arhitektuuri, OS-i tundmine;
• andmete laadimine ja mahalaadimine, andmete migreerimine erinevate DBMS-ide vahel.

Üldiselt, kui me räägime nendel päevadel valikust, siis see sarnaneb valikuga nõukogude poes 80ndate lõpus:

Meie aeg

Sellest ajast peale on puud muidugi kasvanud, maailm muutunud ja sellest sai umbes selline:

DBMS-i turg on samuti muutunud, nagu on selgelt näha Gartneri viimasest aruandest:

Ja siin tuleb märkida, et pilved, mille populaarsus kasvab, on hõivanud oma niši. Kui loeme sama Gartneri aruannet, näeme järgmisi järeldusi:

1. Paljud kliendid on teel rakenduste pilve teisaldamisele.
2. Uued tehnoloogiad ilmuvad esmalt pilves ja pole tõsi, et need liiguvad kunagi pilvevälisesse infrastruktuuri.
3. Makstav hinnamudel on muutunud tavapäraseks. Igaüks tahab maksta ainult selle eest, mida ta kasutab, ja see pole isegi trend, vaid lihtsalt faktiväide.

Mis nüüd?

Täna oleme kõik pilves. Ja küsimused, mis meie jaoks tekivad, on valiku küsimused. Ja see on tohutu, isegi kui räägime ainult DBMS-i tehnoloogiate valikust kohapealses vormingus. Meil on ka hallatavad teenused ja SaaS. Seega muutub valik iga aastaga ainult raskemaks.

Lisaks valikuküsimustele on ka piiravad tegurid:

• hind. Paljud tehnoloogiad maksavad endiselt raha;
• oskused. Kui me räägime vabast tarkvarast, siis tekib oskuste küsimus, kuna vaba tarkvara nõuab selle juurutajatelt ja käitajatelt piisavat kompetentsi;
• funktsionaalne. Kõigil pilves saadaolevatel ja näiteks isegi samale Postgresile ehitatud teenustel pole samu funktsioone nagu Postgres On-premises. See on oluline tegur, mida tuleb teada ja mõista. Veelgi enam, see tegur muutub olulisemaks kui teadmised ühe DBMS-i varjatud võimalustest.

Mida DA/DE-lt praegu oodatakse:

• hea ainevaldkonna ja rakenduste arhitektuuri tundmine;
• oskus õigesti valida sobiv DBMS-tehnoloogia, võttes arvesse käsilolevat ülesannet;
• oskus valida optimaalne meetod valitud tehnoloogia rakendamiseks olemasolevate piirangute kontekstis;
• võime teostada andmeedastust ja migratsiooni;
• oskus valitud lahendusi rakendada ja opereerida.

Allpool näide põhineb GCP-l demonstreerib, kuidas ühe või teise andmetega töötamise tehnoloogia valik sõltub selle struktuurist:

Pange tähele, et PostgreSQL ei sisaldu skeemis, kuna see on terminoloogia all peidetud Pilv SQL. Ja kui jõuame Cloud SQL-i, peame uuesti tegema valiku:

Tuleb märkida, et see valik ei ole alati selge, seetõttu juhinduvad rakenduste arendajad sageli intuitsioonist.

Kokku:

1. Mida edasi, seda teravamaks muutub valiku küsimus. Ja isegi kui vaatate ainult GCP-d, hallatud teenuseid ja SaaS-i, ilmub mõni RDBMS-i mainimine alles 4. sammul (ja seal on lähedal ka Spanner). Lisaks ilmub 5. sammus valik PostgreSQL ja selle kõrval on ka MySQL ja SQL Server, st. kõike on palju, aga valida tuleb.
2. Me ei tohi unustada piiranguid kiusatuste taustal. Põhimõtteliselt tahavad kõik mutrivõtit, kuid see on kallis. Selle tulemusena näeb tüüpiline taotlus välja umbes selline: "Palun tehke meist mutrivõti, kuid Cloud SQL-i hinna eest olete professionaalid!"

Mida me peaksime tegema?

Väitlemata, et see on ülim tõde, ütleme järgmist:

Peame muutma oma lähenemisviisi õppimisele:

• pole mõtet õpetada nii, nagu varem DBA-sid õpetati;
• teadmisest ühe toote kohta enam ei piisa;
• aga kümnete tundmine ühe tasemel on võimatu.

Peate teadma mitte ainult seda, kui palju toode on, vaid ka:

• selle rakenduse kasutusjuht;
• erinevad kasutuselevõtumeetodid;
• iga meetodi eelised ja puudused;
• sarnaseid ja alternatiivseid tooteid, et teha teadlik ja optimaalne valik ning mitte alati eelistada tuttavat toodet.

Samuti peate suutma andmeid migreerida ja mõistma ETL-iga integreerimise põhiprintsiipe.

tõeline juhtum

Lähiminevikus oli vaja luua mobiilirakendusele taustaprogramm. Selleks ajaks, kui selle kallal tööd alustati, oli taustaprogramm juba välja töötatud ja kasutamiseks valmis ning arendusmeeskond veetis selle projektiga umbes kaks aastat. Määrati järgmised ülesanded:

• ehitada CI/CD;
• vaadata üle arhitektuur;
• pane see kõik tööle.

Rakendus ise oli mikroteenused ja Python/Django kood töötati välja nullist ja otse GCP-s. Sihtrühma osas eeldati, et seal on kaks piirkonda - USA ja EL ning liiklus jagati Global Load balanceri kaudu. Kõik töökoormused ja arvutustöökoormus töötasid Google Kubernetes Engine'is.

Mis puutub andmetesse, siis oli 3 struktuuri:

• pilvesalvestus;
• Andmehoidla;
• Pilv-SQL (PostgreSQL).

Võib küsida, miks valiti Cloud SQL? Tõtt-öelda on selline küsimus viimastel aastatel tekitanud omamoodi piinliku pausi – on tunne, et inimesed on relatsiooniandmebaaside suhtes häbelikuks muutunud, kuid sellest hoolimata jätkavad nad nende aktiivset kasutamist ;-).

Meie puhul valiti Cloud SQL järgmistel põhjustel:

1. Nagu mainitud, töötati rakendus välja Django abil ja sellel on mudel püsivate andmete kaardistamiseks SQL-i andmebaasist Pythoni objektidele (Django ORM).
2. Raamistik ise toetas üsna piiratud DBMS-ide loendit:

• PostgreSQL;
• MariaDB;
• MySQL;
• oraaklid;
• SQLite.

Sellest lähtuvalt valiti PostgreSQL sellest loendist üsna intuitiivselt (tegelikult pole Oracle valida).

Mis puudus:

• rakendust kasutati ainult kahes piirkonnas ja kolmas ilmus plaanidesse (Aasia);
• Andmebaas asus Põhja-Ameerika piirkonnas (Iowa);
• klient oli mures võimaliku juurdepääsu viivitused Euroopast ja Aasiast ning katkestused teenistuses DBMS-i seisaku korral.

Vaatamata sellele, et Django ise suudab paralleelselt töötada mitme andmebaasiga ja jagada need lugemiseks ja kirjutamiseks, ei olnud rakenduses nii palju kirjutamist (üle 90% on lugemine). Ja üldiselt ja üleüldse, kui seda oli võimalik teha Euroopa ja Aasia põhibaasi lugemis-koopia, oleks see kompromisslahendus. No mis selles nii keerulist on?

Raskus seisnes selles, et klient ei tahtnud hallatavate teenuste ja Cloud SQL-i kasutamisest loobuda. Ja Cloud SQL-i võimalused on praegu piiratud. Cloud SQL toetab kõrget kättesaadavust (HA) ja Read Replica (RR), kuid sama RR-i toetatakse ainult ühes piirkonnas. Pärast Ameerika piirkonnas andmebaasi loomist ei saa te Euroopa piirkonnas Cloud SQL-i abil lugemiskoopiat teha, kuigi Postgres ise ei takista teil seda teha. Kirjavahetus Google'i töötajatega ei viinud kuhugi ja lõppes lubadustega stiilis "me teame probleemi ja töötame selle kallal, millalgi see probleem laheneb."

Kui loetleme lühidalt Cloud SQL-i võimalused, näeb see välja umbes selline:

1. Kõrge saadavus (HA):

• ühes piirkonnas;
• ketta replikatsiooni kaudu;
• PostgreSQL mootoreid ei kasutata;
• võimalik automaatne ja käsitsi juhtimine – tõrkeotsas/tõrketagastus;
• Ümberlülitamisel pole DBMS mitu minutit saadaval.

2. Lugege koopiat (RR):

• ühes piirkonnas;
• kuum ooterežiim;
• PostgreSQL-i voogesituse replikatsioon.

Lisaks, nagu kombeks, seisate tehnoloogiat valides alati silmitsi mõnega piirangud:

• klient ei soovinud olemeid luua ja IaaS-i kasutada, välja arvatud GKE kaudu;
• klient ei soovi iseteenindust PostgreSQL/MySQL-i juurutada;
• Noh, üldiselt oleks Google Spanner üsna sobiv, kui see poleks selle hinna eest, kuid Django ORM ei saa sellega töötada, kuid see on hea asi.

Arvestades olukorda, sai klient järelküsimuse: "Kas saate teha midagi sarnast, et see oleks nagu Google Spanner, kuid töötaks ka Django ORM-iga?"

Lahenduse variant nr 0

Esimene asi, mis pähe tuli:

• püsida CloudSQL-is;
• piirkondade vahel ei toimu sisseehitatud replikatsiooni ühelgi kujul;
• proovige lisada PostgreSQL-i abil replika olemasolevale pilv-SQL-ile;
• käivitage kuskil ja kuidagi PostgreSQL-i eksemplar, kuid ärge vähemalt puudutage masterit.

Paraku selgus, et seda ei saa teha, kuna puudub ligipääs hostile (see on hoopis teises projektis) - pg_hba ja nii edasi, samuti pole ligipääsu superkasutaja all.

Lahenduse variant nr 1

Pärast edasist järelemõtlemist ja varasemaid asjaolusid arvesse võttes mõttekäik mõnevõrra muutus:

• Püüame endiselt CloudSQL-i piires püsida, kuid läheme üle MySQL-ile, kuna MySQL-i Cloud SQL-il on väline juht, mis:

— on välise MySQL-i puhverserver;
- näeb välja nagu MySQL-i eksemplar;
- leiutatud andmete migreerimiseks teistest pilvedest või kohapealsest.

Kuna MySQL replikatsiooni seadistamine ei vaja ligipääsu hostile, siis põhimõtteliselt kõik toimis, kuid see oli väga ebastabiilne ja ebamugav. Ja kui me edasi läksime, muutus see täiesti hirmutavaks, kuna kasutasime kogu konstruktsiooni terraformiga ja järsku selgus, et välist meistrit terraform ei toetanud. Jah, Google'il on CLI, kuid millegipärast töötas siin aeg-ajalt kõik – mõnikord luuakse, mõnikord mitte. Võib-olla seetõttu, et CLI leiutati andmete väliseks migratsiooniks, mitte koopiate jaoks.

Tegelikult sai sel hetkel selgeks, et Cloud SQL ei sobi üldse. Nagu öeldakse, tegime kõik, mis suutsime.

Lahenduse variant nr 2

Kuna Cloud SQL raamistikus püsida ei olnud võimalik, püüdsime sõnastada nõuded kompromisslahendusele. Nõuded osutusid järgmisteks:

• töö Kubernetes, Kubernetese (DCS, ...) ja GCP (LB, ...) ressursside ja võimaluste maksimaalne kasutamine;
• ballasti puudumine pilves olevate ebavajalike asjade (nt HA puhverserveri) tõttu;
• võimalus käivitada PostgreSQL või MySQL põhiregioonis HA; teistes piirkondades - HA põhipiirkonna RR-st pluss selle koopia (usaldusväärsuse tagamiseks);
• multi master (ma ei tahtnud temaga ühendust võtta, aga see polnud väga oluline)

.
Nende nõudmiste tulemusena on lksobivad DBMS-i ja sidumisvõimalused:

• MySQL Galera;
• PrussakasDB;
• PostgreSQL-i tööriistad

:
- pgpool-II;
— Patroon.

MySQL galerii

MySQL Galera tehnoloogia töötas välja Codership ja see on InnoDB pistikprogramm. Iseärasused:

• multi master;
• sünkroonne replikatsioon;
• lugemine mis tahes sõlmest;
• salvestamine mis tahes sõlme;
• sisseehitatud HA mehhanism;
• Bitnamist on Helmi diagramm.

PrussakasDB

Kirjelduse järgi on asi täiesti pomm ja tegemist Go-s kirjutatud avatud lähtekoodiga projektiga. Peaosaleja on Cockroach Labs (asutatud Google'i inimeste poolt). See relatsiooniline DBMS oli algselt mõeldud hajutamiseks (koos horisontaalse skaleerimisega) ja tõrketaluvaks. Selle ettevõtte autorid tõid välja eesmärgi "kombineerida SQL-i funktsionaalsuse rikkalikkus NoSQL-i lahendustele tuttava horisontaalse juurdepääsetavusega".

Hea boonus on post-gressi ühendusprotokolli tugi.

pgpool

See on PostgreSQL-i lisand, tegelikult uus üksus, mis võtab üle kõik ühendused ja töötleb neid. Sellel on oma koormuse tasakaalustaja ja parser, mis on litsentsitud BSD litsentsi alusel. See pakub küllaldaselt võimalusi, kuid tundub mõnevõrra hirmutav, sest uue olemi olemasolu võib saada täiendavate seikluste allikaks.

Patroni

See on viimane asi, millele mu pilk langes, ja nagu selgus, mitte asjata. Patroni on avatud lähtekoodiga utiliit, mis on sisuliselt Pythoni deemon, mis võimaldab teil automaatselt hooldada PostgreSQL-klastreid erinevat tüüpi replikatsiooni ja automaatse rollivahetusega. Asi osutus väga huvitavaks, kuna see sulandub hästi cuberiga ega too sisse uusi üksusi.

Mida sa lõpuks valisid?

Valik polnud lihtne:

1. PrussakasDB - tuli, kuid tume;
2. MySQL galerii - ka pole paha, seda kasutatakse paljudes kohtades, aga MySQL;
3. pgpool — palju tarbetuid üksusi, nii-nii integratsioon pilve ja K8-dega;
4. Patroni - suurepärane integratsioon K8-dega, ilma tarbetute üksusteta, integreerub hästi GCP LB-ga.

Seega langes valik Patronile.

Järeldused

On aeg teha lühikokkuvõte. Jah, IT-taristu maailm on oluliselt muutunud ja see on alles algus. Ja kui varem olid pilved lihtsalt teist tüüpi infrastruktuur, siis nüüd on kõik teisiti. Pealegi ilmuvad pilvedes uuendused pidevalt, need ilmuvad ja võib-olla ilmuvad ainult pilvedes ja alles siis viiakse need idufirmade jõupingutustega üle On-premisesse.

Mis puutub SQL-i, siis SQL jääb elama. See tähendab, et peate teadma PostgreSQL-i ja MySQL-i ning oskama nendega töötada, kuid veelgi olulisem on osata neid õigesti kasutada.

Allikas: www.habr.com