Kuidas ellu jääda SQL-põhises maailmas 21. sajandil: pilved, Kubernetes ja PostgreSQL multimaster

Tere, Habr'i kasutajad. Täna algavad kursuse esimese grupi tunnid «PostgreSQL». Seoses sellega tahame rääkida teile, kuidas toimus avatud veebinar selle kursuse kohta.

Uues järgmine avatud õppetund räägiti sellest, milliste väljakutsetega SQL-andmebaasid silmitsi seisavad pilvetehnoloogia ja Kubernetes'iga. Samuti vaatasime, kuidas SQL-andmebaasid kohanduvad ja muteeruvad nendele väljakutsetele vastates.

Veebinari viis läbi Valeri Bezrukov, Google Cloud Practice Delivery Manager EPAM Systems'is.

Kui puud olid väikesed ...

Esiteks, meenutame, kuidas toona viimase sajandi lõpus andmebaaside valik algas. Kuid see ei tohiks olla keeruline, sest andmebaaside valik sel ajal algas ja lõppes Oracle.

90ndate lõpus ja 2000. alguses ei olnud tegelikult suurt valikut tööstuslike skaleeritavate andmebaaside osas. Jah, oli IBM DB2, Sybase ja veel mõned andmebaasid, mis tulid ja kadusid, kuid üldiselt ei olnud nad Oracle'i taustal eriti silmatorkavad. Seetõttu olid nende aegade inseneride oskused seotud selle ainukese valikuga, mis olemas oli.

Oracle DBA pidi oskama:

• installer Oracle Serverit distribuutsioonist;
• seade Oracle Serverit:

• init.ora;
• listener.ora;

— luua:

• tabeliruumid;
• skeemid;
• kasutajad;

— teostada varukoopiate loomine ja taastamine;
— teostada jälgimist;
— võidelda mitteoptimaalsete päringutega.

Samal ajal ei nõutud Oracle DBA-lt eriti:

• osata valida optimaalseid andmebaasisüsteeme või muid andmete salvestamise ja töötlemise tehnoloogiaid;
• tagada kõrge kättesaadavus ja horisontaalne skaleeritavus (see ei olnud alati DBA küsimus);
• hästi tunda valdkonna, infrastruktuuri, rakenduste arhitektuuri, OS-i;
• teostada andmete laadimist ja väljastamist, andmete migreerimist erinevate andmebaaside vahel.

Üldiselt, kui rääkida selle aja valikust, sarnaneb see valikuga Nõukogude poe lõpus 80ndatel:

Meie aeg

Alates sellest ajast on puud muidugi kasvanud, maailm on muutunud ja nüüd on see kuidagi nii:

Andmebaasiturgu on samuti muutunud, mida tõendab värske Gartneri raport:

Ja siinkohal ei saa mainimata jätta, et oma niši on leidnud pilvetehnoloogiad, mille populaarsus kasvab. Kui lugeda sama Gartneri raportit, näeme järgmisi järeldusi:

1. Paljud kliendid on teel rakenduste pilve viimise poole.
2. Uued tehnoloogiad ilmuvad kõigepealt pilve ja pole sugugi kindel, et need kunagi üleminekuks mitte-pilve infrastruktuuri leiavad.
3. Maksustamismodel, mis põhineb pay-as-you-go põhimõttel, on saanud tavapäraseks. Kõik soovivad maksta ainult selle eest, mida nad kasutavad, ja see on isegi enam mitte trend, vaid lihtsalt fakti konstateerimine.

Mis nüüd?

Täna oleme kõik pilves. Ja küsimused, mis meil tekivad, on valikuküsimused. Need on tohutud, isegi kui räägime ainult andmebaaside valikust On-premises formaadis. Ja meil on ka hallatud teenused ja SaaS. Seega, valikud keerduvad iga aastaga aina rohkem.

Valikuküsimustega koos toimivad ka piiravad tegurid:

• hind. Paljud tehnoloogiad maksavad endiselt raha;
• oskused. Kui räägime vabavarast, siis tõstatub oskuste küsimus, kuna tasuta tarkvara nõuab inimestelt, kes seda juurutavad ja kasutavad, piisavat kompetentsust;
• funktsionaalsus. Mitte kõik teenused, mis on saadaval pilves ja mis on ehitatud näiteks PostgreSQL alusel, ei oma samu funktsioone, mis PostgreSQL On-premises. See on oluline tegur, mida tuleb teada ja mõista. Lisaks muutub see tegur tihti olulisemaks kui teadmised mingitest varjatud võimalustest konkreetse andmebaasi kohta.

Mis on DA/DE ootused:

• hea arusaam valdkonnast ja rakendusarhitektuurist;
• oskus valida sobiv andmebaasitehnoloogia arvestades seatud ülesandeid;
• oskus valida valitud tehnoloogia rakendamise optimaalne meetod olemasolevate piirangute kontekstis;
• oskus andmete üleviimiseks ja migreerimiseks;
• oskus rakendada ja hallata valitud lahendusi.

Alljärgnev näide GCP alusel demonstrib, kuidas toimub valiku tegemine sõltuvalt andmete struktuurist:

Pange tähele, et skeemist puudub PostgreSQL, kuna see varjatakse terminoloogia Cloud SQL. Ja kui satume Cloud SQL-i, siis peame jälle valima:

Siinkohal tuleb märkida, et see valik ei ole alati arusaadav, seega arendajad juhinduvad sageli intuitsioonist.

Kokkuvõtteks:

1. Mida kaugemale, seda aktuaalsemaks muutub valikute küsimus. Ja isegi kui vaadata ainult GCP-d, siis managed teenuste ja SaaS-i puhul ilmub mingisugune viide RDBMS-ile alles 4. sammul (ja seal on Spanner kõrval). Lisaks, PostgreSQL-i valik ilmub üldse alles 5. sammul, samas kui kõrval on veel MySQL ja SQL Server, ehk kõike on palju, aga valida tuleb..
2. Ei saa unustada ka piiranguid ahvatluste taustal. Peamiselt soovivad kõik Spannerit, kuid see on kallis. Lõppkokkuvõttes näeb tüüpiline päring välja umbes nii: «Palun tehke meile Spanner, kuid Cloud SQL-i hinnaga, noh, teie olete professionaalid!»

Aga mida siis teha?

Ilma lõpliku tõe pretensioonita ütleme järgmist:

On vaja muuta lähenemist õppimisele:

• ei ole mõtet õpetada nagu varem DBA-sid;
• ühe toote teadmine ei ole enam piisav;
• ja kümne tasemel ühe puhul on võimatu.

On vaja teada mitte ainult toodet, vaid ka:

• kasutuse juhtumit;
• erinevaid rakendusmeetodeid;
• iga meetodi eelised ja puudused;
• sarnased ja alternatiivsed tooted, et teha teadlik ja optimaalne valik ning mitte alati tuttava toote kasuks.

Ja veel tuleb osata andmeid migreerida ja mõista ETL-i põhiprintsiipe.

Reaalne juhtum

Hiljuti tuli teha mobiilirakenduse tagapoolt. Enne töö alustamist oli tagapool juba välja töötatud ja valmis rakendamiseks, ning arendajate meeskond oli sellele projektile kulutanud umbes kaks aastat. Sel ajal pandi paika järgmised ülesanded:

• luua CI/CD;
• teha arhitektuuri ülevaatus;
• käivitada kõik see tootmisse.

Ise rakendus oli mikroteenustel põhinev, ning Python/Django kood oli välja töötatud nullist ja kohe GCP-s. Mis puudutas sihtrühma, siis eeldati, et piirkondi on kaks — USA ja EL, ning liiklus jaotati ülemaailmse koormuse tasandaja kaudu. Kõik töökoormused ja arvutuskoormus töötasid Google Kubernetes Engine'is.

Andmete osas oli 3 struktuuri:

• Cloud Storage;
• Datastore;
• Cloud SQL (PostgreSQL).

Võib tekkida küsimus, miks valiti Cloud SQL? Tõele au andes tekitab see küsimus viimastel aastatel mõningast kohmetust — tundub, et inimesed on hakanud rikkaid andmebaase häbenema, kuid siiski jätkavad nad nende aktiivset kasutamist ;-).

Mis puutub meie juhtumisse, siis Cloud SQL valiti järgmistel põhjustel:

1. Nagu mainitud, rakendust arendati Django abil, kus on mudel, mis näitab püsivaid andmeid SQL-andmebaasist Python (Django ORM) objektidesse.
2. Kogu raamistik toetas üsna piiratud nimekirja andmebaasihaldussüsteemidest:

• PostgreSQL;
• MariaDB;
• MySQL;
• Oracle;
• SQLite.

Seega valisime PostgreSQL selle nimekirja hulgast peamiselt intuitsiooni põhjal (noh, mitte tõesti Oracle'i valida).

Mida puudus:

• rakendus oli juurutatud vaid kahes piirkonnas ja plaanidesse lisandus kolmas (Aasia);
• Andmebaas asus Põhja-Ameerika piirkonnas (Iowa);
• tellija poolt oli muresid seoses võimalike juurdepääsu viivitustega Euroopast ja Aasiast ning teenuse katkestustega andmebaasi talitluse katkestamise korral. Kuigi Django saab töötada mitme andmebaasiga samal ajal ja jagada neid lugemiseks ja kirjutamiseks, ei olnud rakenduses väga palju kirjeid (üle 90% — lugemine). Seega, kui oleks võimalik teha

read-replika põhiteabasal Euroopas ja Aasias , oleks see kompromisslahendus. Mis siin siis nii keerulist on?Küsimus seisnes selles, et tellija ei soovinud loobuda hallatud teenuste ja Cloud SQL kasutamisest. Kahjuks on Cloud SQL'i võimalused praegusel hetkel piiratud. Cloud SQL toetab kõrge kättesaadavuse (HA) ja lugemisreplikatsioonide (RR) loomist, kuid sama RR toetatakse vaid ühes piirkonnas. Luues andmebaasi Ameerika piirkonnas, ei saa Cloud SQL-i vahendeid kasutades teha read-replikat Euroopa piirkonnas, kuigi PostgreSQL ise ei takista seda tegemast. Suhtlemine Google'i töötajatega ei toonud mingeid tulemusi ja lõppes lubadustega stiilis „me teame probleemist ja töötame selle kallal, ühel päeval küsimus lahendatakse“.

Kui loetleda Cloud SQL-i võimalusi kokkuvõtlikult, näeb see välja umbes nii:

1. Kõrge kättesaadavus (HA):

ühes piirkonnas;

• ketta replikatsiooni kaudu;
• PostgreSQL mehhanisme ei kasutata;
• võimalik automaatne ja käsitsi juhtimine — failover / failback;
• andmebaasi vahetamisel ei ole see kättesaadav mitmeid minuteid.
• 2. Lugemisreplika (RR):

kuum varukoopia;

• ketta replikatsiooni kaudu;
• PostgreSQL voogedastuse replikatsioon.
• Lisaks on tavapäraselt tehnoloogia valimisel silmitsi mitmesuguste

piirangutega, tellija ei soovinud luua üksteise kõrval olevaid teenuseid ega kasutada IaaS-i, välja arvatud GKE kaudu;:

• tellija ei soovinud juurutada ise teenindavat PostgreSQL / MySQL-i;
• klient ei soovinud self service PostgreSQL/MySQL-i kasutusele võtta;
• ja ja, Google Spanner sobis sobis hästi, kui mitte tema hinna pärast, kuigi Django ORM ei saa sellega töötada, aga asi on tõesti hea.

Arvestades olukorda, küsis tellijalt küsimus, mis jäi muljeid jätma: „Kas saate midagi sarnast teha, et see oleks nagu Google Spanner, aga töötaks ka Django ORM-iga?”

Lahenduse variant nr 0

Esimene mõte, mis pähe tuli:

• jääda CloudSQL piiresse;
• regionite vahel mingit sisseehitatud replikatsiooni ei tule üldse;
• proovida ühendada olemasolev Cloud SQL by PostgreSQL replikatsioon;
• kusagil ja kuidagi käivitada PostgreSQL instants, aga vähemalt masterit mitte puudutada.

Kahjuks selgus, et seda ei saa teha, kuna puudub juurdepääs hostile (see on üldse teises projektis) — pg_hba ja nii edasi, ning veel pole juurdepääsu superkasutajana.

Lahenduse variant nr 1

Pärast järgmisi mõtisklusi ja arvestades eelnevaid asjaolusid, muutus mõtteliin veidi:

• me üritame ikka jääda CloudSQL piiresse, kuid liigume MySQL-i suunas, kuna Cloud SQL by MySQL-l on väliseid mastereid, mis:

— on proxy välisele MySQL-ile;
— näeb välja nagu MySQL instants;
— on mõeldud andmete migreerimiseks teistest pilvedest või kohapealsest süsteemist.

Kuna MySQL replikatsiooni seadistamine ei vaja juurdepääsu hostile, töötab põhimõtteliselt kõik, aga see oli väga ebausaldusväärne ja ebamugav. Ja kui edasi minna, siis oli see tõeliselt hirmus, kuna me kõik struktuuri käivitasime terraformiga ja äkki selgus, et välised masterid ei ole terraformi toetatud. Jah, Google'il on CLI, aga mikski ei töötanud ka seal kõik usaldusväärselt — mõni kord loodi, mõni kord ei loodud. Võib-olla seetõttu, et CLI on mõeldud andmete välise migreerimise jaoks, mitte replikatsioonide jaoks.

Nüüd on selge, et Cloud SQL ei sobi absoluutselt. Nagu öeldakse, tegime kõik, mis võimalik.

Lahenduse variant nr 2

Kuna Cloud SQL piiresse jäämine ei õnnestunud, püüdsime formulida kompromisslahenduse nõuded. Nõuded olid järgmised:

• töö Kuberneteses, maksimaalne ressursside ja Kubernetes (DCS, …) ning GCP (LB, …) võimaluste kasutamine;
• ükski kasutu kaubik pilve asjadest nagu HA proxy ei ole lubatud;
• võimalus käivitada peamises piirkonnas HA PostgreSQL või MySQL; teistes piirkondades — HA põhijoonest ja selle koopiast (usaldusväärsuse tagamiseks);
• multi master (oli vaja sellega siduda, kuid see ei olnud nii põhimõtteline)

.
Nende nõuete tulemusena ilmus lõpuks silmapiirile psobivad variantid andmebaasidele ja pistikprogrammidele:

• MySQL Galera;
• CockroachDB;
• PostgreSQL tööriistad

:
— pgpool-II;
— Patroni.

MySQL Galera

MySQL Galera tehnoloogia on välja töötatud ettevõtte Codership poolt ja see on plugin InnoDB jaoks. Omadused:

• mitu masterit;
• sünkroonne replikatsioon;
• lugemine igast sõlmest;
• kirjutamine igasse sõlme;
• sisseehitatud HA mehhanism;
• on olemas Bitnami jaoks Helm chart.

CockroachDB

Kirjelduse kohaselt on see täiesti fantastiline ja esindab end avatud allika projektina, mis on kirjutatud Go-s. Peamine osaleja on Cockroach Labs (asutasid Google'i endised töötajad). See relatsiooniline andmebaas on algselt loodud olema jaotatud (horisontaalse skaleeritavusega 'karbist välja') ja tõrkeotsing. Selle autorid on määratlenud eesmärgi 'ühendada SQL-i funktsionaalsuse rikkus horisontaalse kättesaadavusega, mis on NoSQL lahendustele tuttav.'

Meeldiva boonusena — PostgreSQL-i ühendusprotokolli tugi.

Pgpool

See on PostgreSQL-i kohalduv kiht, tegelikult uus entiteet, mis võtab enda alla kõik ühendused ja töötleb neid. Sellel on oma koormuse tasakaalustaja ja parser, see litsentseeritakse BSD litsentsi alusel. See pakub laialdasi võimalusi, kuid näeb välja veidi hirmutav, kuna uus entiteet võiks tekitada mingeid lisaseiklusi.

Patronit

See on viimane, millele ma tähelepanu pöörasin, ja nagu selgus, mitte asjata. Patroni on avatud allika utiliit, mis põhimõtteliselt esindab Pythonis kirjutatud deemonit, mis võimaldab automaatset PostgreSQL klastrite teenindamist erinevate replikatsioonitüüpide ja automaatse rollide vahetamisega. Asi osutus väga huvitavaks, kuna see integreerub hästi kubernekidega ja ei too endaga kaasa uusi entiteete.

Kuidas me lõpuks valisime

Valik ei olnud kerge:

1. CockroachDB — lahe, aga hirmutav;
2. MySQL Galera — ka üsna hea, palju kasutatakse, kuid MySQL;
3. Pgpool — palju liigseid entiteete, halb integreerimine pilve ja K8s-iga;
4. Patronit — suurepärane integreerimine K8s-iga, ei ole liigseid entiteete, integreerub hästi GCP LB-ga.

Seega langetati otsus Patroni kasuks.

Järeldused

On aeg teha lühikokkuvõte. Jah, IT-infrastruktuuri maailm on oluliselt muutunud ja see on alles algus. Ja kui varem olid pilved lihtsalt teistsugune infrastruktuuri tüüp, siis nüüd on kõik teistmoodi. Rohkemgi veel, pilvetooteid kerkib pidevalt esile ning neid võib-olla arendavad vaid pilved ja hiljem, algatajate poolt, viiakse need On-premises.

Mis SQL-i kohta on SQL elujõuline. See tähendab, et PostgreSQL-i ja MySQL-i tuleb tunda ja osata nendega töötada, kuid veel olulisem on osata neid õigesti rakendada.

Allikas: habr.com