Si të mbijetoni një bazë të dhënash SQL në shekullin 21: retë, Kubernetes dhe PostgreSQL multimaster

Përshëndetje, banorë të Khabrovsk. Mësimet në grupin e parë të kursit nisin sot "PostgreSQL". Në këtë drejtim, do të donim t'ju tregojmë se si u zhvillua webinari i hapur në këtë kurs.

В mësimi tjetër i hapur folëm për sfidat me të cilat përballen bazat e të dhënave SQL në epokën e reve dhe Kubernetes. Në të njëjtën kohë, ne shikuam se si bazat e të dhënave SQL përshtaten dhe ndryshojnë nën ndikimin e këtyre sfidave.

U mbajt webinari Valery Bezrukov, Google Cloud Practice Delivery Manager në EPAM Systems.

Kur pemët ishin të vogla...

Së pari, le të kujtojmë se si filloi zgjedhja e DBMS në fund të shekullit të kaluar. Sidoqoftë, kjo nuk do të jetë e vështirë, sepse zgjedhja e një DBMS në ato ditë filloi dhe mbaroi Orakull.

Në fund të viteve '90 dhe në fillim të viteve 2, në thelb nuk kishte zgjidhje kur bëhet fjalë për bazat e të dhënave industriale të shkallëzueshme. Po, kishte IBM DBXNUMX, Sybase dhe disa baza të dhënash të tjera që vinin dhe shkuan, por në përgjithësi ato nuk ishin aq të dukshme në sfondin e Oracle. Prandaj, aftësitë e inxhinierëve të atyre kohërave ishin disi të lidhura me zgjedhjen e vetme që ekzistonte.

Oracle DBA duhej të ishte në gjendje të:

• instaloni Oracle Server nga kompleti i shpërndarjes;
• konfiguroni serverin Oracle:

• init.ora;
• dëgjues.ora;

- krijoni:

• hapësira tavoline;
• skemat;
• përdoruesit;

— kryeni kopje rezervë dhe rivendosni;
— të kryejë monitorim;
— merreni me kërkesa jo optimale.

Në të njëjtën kohë, nuk kishte asnjë kërkesë të veçantë nga Oracle DBA:

• të jetë në gjendje të zgjedhë DBMS optimale ose teknologji tjetër për ruajtjen dhe përpunimin e të dhënave;
• të sigurojë disponueshmëri të lartë dhe shkallëzim horizontal (kjo nuk ishte gjithmonë një çështje DBA);
• njohuri të mira të fushës lëndore, infrastrukturës, arkitekturës së aplikacioneve, OS;
• ngarkoni dhe shkarkoni të dhënat, migroni të dhënat midis DBMS-ve të ndryshme.

Në përgjithësi, nëse flasim për zgjedhjen në ato ditë, ajo i ngjan zgjedhjes në një dyqan sovjetik në fund të viteve '80:

Koha jonë

Që atëherë, natyrisht, pemët janë rritur, bota ka ndryshuar dhe u bë diçka e tillë:

Tregu i DBMS gjithashtu ka ndryshuar, siç mund të shihet qartë nga raporti i fundit nga Gartner:

Dhe këtu duhet të theksohet se retë, popullariteti i të cilave po rritet, kanë zënë vendin e tyre. Nëse lexojmë të njëjtin raport Gartner, do të shohim përfundimet e mëposhtme:

1. Shumë klientë janë në rrugën e lëvizjes së aplikacioneve në cloud.
2. Teknologjitë e reja shfaqen fillimisht në cloud dhe nuk është fakt që ato do të kalojnë ndonjëherë në infrastrukturën jo-cloud.
3. Modeli i çmimeve paga-as-you-go është bërë i zakonshëm. Të gjithë duan të paguajnë vetëm për atë që përdorin, dhe kjo nuk është as një trend, por thjesht një deklaratë fakti.

Po tani?

Sot jemi të gjithë në re. Dhe pyetjet që na lindin janë pyetje të zgjedhjes. Dhe është e madhe, edhe nëse flasim vetëm për zgjedhjen e teknologjive DBMS në formatin On-premises. Ne gjithashtu kemi menaxhuar shërbime dhe SaaS. Kështu, zgjedhja bëhet më e vështirë çdo vit.

Së bashku me pyetjet e zgjedhjes, ka edhe faktorët kufizues:

• çmim. Shumë teknologji ende kushtojnë para;
• aftësitë. Nëse flasim për softuer të lirë, atëherë lind pyetja e aftësive, pasi softueri i lirë kërkon kompetencë të mjaftueshme nga njerëzit që e vendosin dhe e përdorin atë;
• funksionale. Jo të gjitha shërbimet që janë të disponueshme në cloud dhe të ndërtuara, të themi, edhe në të njëjtin Postgres, kanë të njëjtat veçori si Postgres On-premises. Ky është një faktor thelbësor që duhet njohur dhe kuptuar. Për më tepër, ky faktor bëhet më i rëndësishëm se njohja e disa aftësive të fshehura të një DBMS të vetme.

Çfarë pritet nga DA/DE tani:

• të kuptuarit e mirë të fushës së lëndës dhe arkitekturës së aplikimit;
• aftësia për të zgjedhur saktë teknologjinë e duhur DBMS, duke marrë parasysh detyrën në fjalë;
• aftësia për të zgjedhur metodën optimale për zbatimin e teknologjisë së zgjedhur në kontekstin e kufizimeve ekzistuese;
• aftësia për të kryer transferimin dhe migrimin e të dhënave;
• aftësia për të zbatuar dhe përdorur zgjidhjet e zgjedhura.

Më poshtë shembull bazuar në GCP tregon se si funksionon zgjedhja e një ose një teknologjie tjetër për të punuar me të dhëna në varësi të strukturës së saj:

Ju lutemi vini re se PostgreSQL nuk është përfshirë në skemë dhe kjo për shkak se është e fshehur nën terminologjinë CloudSQL. Dhe kur të arrijmë në Cloud SQL, duhet të bëjmë një zgjedhje përsëri:

Duhet të theksohet se kjo zgjedhje nuk është gjithmonë e qartë, kështu që zhvilluesit e aplikacioneve shpesh udhëhiqen nga intuita.

Total:

1. Sa më tej të shkoni, aq më urgjente bëhet çështja e zgjedhjes. Dhe edhe nëse shikoni vetëm GCP, shërbimet e menaxhuara dhe SaaS, atëherë disa përmendje të RDBMS shfaqen vetëm në hapin e 4-të (dhe aty afër është Spanner). Plus, zgjedhja e PostgreSQL shfaqet në hapin e 5-të, dhe pranë tij ka edhe MySQL dhe SQL Server, d.m.th. ka shumë nga të gjitha, por ju duhet të zgjidhni.
2. Nuk duhet të harrojmë kufizimet në sfondin e tundimeve. Në thelb të gjithë duan një çelës, por është i shtrenjtë. Si rezultat, një kërkesë tipike duket diçka si kjo: "Ju lutemi na bëni një çelës, por për çmimin e Cloud SQL, ju jeni profesionistë!"

Cfare duhet te bejme?

Pa pretenduar se jemi e vërteta përfundimtare, le të themi sa vijon:

Ne duhet të ndryshojmë qasjen tonë ndaj të mësuarit:

• nuk ka asnjë kuptim të mësosh mënyrën se si mësoheshin DBA-të më parë;
• njohja e një produkti nuk është më e mjaftueshme;
• por të njohësh dhjetëra në nivelin e një është e pamundur.

Ju duhet të dini jo vetëm dhe jo sa është produkti, por:

• rasti i përdorimit të aplikimit të tij;
• metoda të ndryshme të vendosjes;
• avantazhet dhe disavantazhet e secilës metodë;
• produkte të ngjashme dhe alternative për të bërë një zgjedhje të informuar dhe optimale dhe jo gjithmonë në favor të një produkti të njohur.

Ju gjithashtu duhet të jeni në gjendje të migroni të dhëna dhe të kuptoni parimet bazë të integrimit me ETL.

Rast real

Në të kaluarën e afërt, ishte e nevojshme të krijohej një backend për një aplikacion celular. Në kohën kur filloi puna për të, backend ishte zhvilluar tashmë dhe ishte gati për zbatim, dhe ekipi i zhvillimit kaloi rreth dy vjet në këtë projekt. U vendosën detyrat e mëposhtme:

• ndërtoni CI/CD;
• rishikoni arkitekturën;
• vënë të gjitha në funksion.

Vetë aplikacioni ishte mikroshërbime, dhe kodi Python/Django u zhvillua nga e para dhe drejtpërdrejt në GCP. Sa i përket audiencës së synuar, supozohej se do të kishte dy rajone - SHBA dhe BE, dhe trafiku shpërndahej përmes balancuesit të ngarkesës globale. Të gjitha ngarkesat e punës dhe llogaritja e ngarkesës së punës u ekzekutuan në Google Kubernetes Engine.

Sa i përket të dhënave, kishte 3 struktura:

• Ruajtja në renë kompjuterike;
• Dyqani i të dhënave;
• Cloud SQL (PostgreSQL).

Dikush mund të pyesë veten pse u zgjodh Cloud SQL? Për të thënë të vërtetën, një pyetje e tillë ka shkaktuar një lloj pauze të sikletshme vitet e fundit - ekziston një ndjenjë që njerëzit janë bërë të trembur për bazat e të dhënave relacionale, por megjithatë ata vazhdojnë t'i përdorin ato në mënyrë aktive ;-).

Sa për rastin tonë, Cloud SQL u zgjodh për arsyet e mëposhtme:

1. Siç u përmend, aplikacioni u zhvillua duke përdorur Django dhe ka një model për hartëzimin e të dhënave të vazhdueshme nga një bazë të dhënash SQL në objektet Python (Django ORM).
2. Vetë korniza mbështeti një listë mjaft të kufizuar të DBMS-ve:

• PostgreSQL;
• MariaDB;
• MySQL;
• Orakulli;
• SQLite.

Prandaj, PostgreSQL u zgjodh nga kjo listë mjaft intuitive (epo, nuk është Oracle për të zgjedhur, me të vërtetë).

Çfarë mungonte:

• aplikacioni u vendos vetëm në 2 rajone, dhe një i tretë u shfaq në plane (Azi);
• Baza e të dhënave ndodhej në rajonin e Amerikës së Veriut (Iowa);
• nga ana e klientit kishte shqetësime për të mundshme vonesat e aksesit nga Evropa dhe Azia dhe ndërprerjet ne sherbim në rast të ndërprerjes së DBMS.

Përkundër faktit se vetë Django mund të punojë me disa baza të dhënash paralelisht dhe t'i ndajë ato në lexim dhe shkrim, nuk kishte aq shumë shkrime në aplikacion (më shumë se 90% po lexojnë). Dhe në përgjithësi, dhe në përgjithësi, nëse do të ishte e mundur të bëhej lexoni-kopje e bazës kryesore në Evropë dhe Azi, kjo do të ishte një zgjidhje kompromisi. Epo, çfarë ka kaq të komplikuar?

Vështirësia ishte se klienti nuk donte të hiqte dorë nga përdorimi i shërbimeve të menaxhuara dhe Cloud SQL. Dhe aftësitë e Cloud SQL janë aktualisht të kufizuara. Cloud SQL mbështet disponueshmërinë e lartë (HA) dhe Read Replica (RR), por e njëjta RR mbështetet vetëm në një rajon. Pasi të keni krijuar një bazë të dhënash në rajonin amerikan, nuk mund të bëni një kopje leximi në rajonin evropian duke përdorur Cloud SQL, megjithëse vetë Postgres nuk ju pengon ta bëni këtë. Korrespondenca me punonjësit e Google nuk çoi askund dhe përfundoi me premtime në stilin e "ne e dimë problemin dhe po punojmë për të, një ditë çështja do të zgjidhet".

Nëse rendisim shkurtimisht aftësitë e Cloud SQL, do të duket diçka si kjo:

1. Disponueshmëri e lartë (HA):

• brenda një rajoni;
• nëpërmjet replikimit të diskut;
• Motorët PostgreSQL nuk përdoren;
• kontrolli automatik dhe manual i mundshëm - failover/failback;
• Kur ndërroni, DBMS nuk është i disponueshëm për disa minuta.

2. Lexoni kopjen (RR):

• brenda një rajoni;
• gatishmëri e nxehtë;
• Replikimi i transmetimit të PostgreSQL.

Përveç kësaj, siç është zakon, kur zgjidhni një teknologji, gjithmonë përballeni me disa kufizimet:

• klienti nuk donte të krijonte entitete dhe të përdorte IaaS, përveçse nëpërmjet GKE;
• klienti nuk do të donte të vendoste vetë shërbimin PostgreSQL/MySQL;
• Epo, në përgjithësi, Google Spanner do të ishte mjaft i përshtatshëm nëse nuk do të ishte për çmimin e tij, megjithatë, Django ORM nuk mund të punojë me të, por është një gjë e mirë.

Duke marrë parasysh situatën, klienti mori një pyetje vijuese: "A mund të bëni diçka të ngjashme që të jetë si Google Spanner, por edhe të funksionojë me Django ORM?"

Opsioni i zgjidhjes nr. 0

Gjëja e parë që më erdhi në mendje:

• qëndroni brenda CloudSQL;
• nuk do të ketë përsëritje të integruar midis rajoneve në asnjë formë;
• përpiquni të bashkëngjitni një kopje në një Cloud SQL ekzistuese nga PostgreSQL;
• nisni një shembull PostgreSQL diku dhe disi, por të paktën mos e prekni masterin.

Mjerisht, doli që kjo nuk mund të bëhet, sepse nuk ka qasje në host (është në një projekt krejt tjetër) - pg_hba dhe kështu me radhë, dhe gjithashtu nuk ka qasje nën superpërdorues.

Opsioni i zgjidhjes nr. 1

Pas reflektimit të mëtejshëm dhe duke marrë parasysh rrethanat e mëparshme, treni i mendimit ndryshoi disi:

• Ne ende po përpiqemi të qëndrojmë brenda CloudSQL, por po kalojmë në MySQL, sepse Cloud SQL nga MySQL ka një master të jashtëm, i cili:

— është një përfaqësues për MySQL të jashtëm;
- duket si një shembull MySQL;
- shpikur për migrimin e të dhënave nga retë e tjera ose në mjedise.

Meqenëse konfigurimi i riprodhimit të MySQL nuk kërkon qasje në host, në parim gjithçka funksionoi, por ishte shumë e paqëndrueshme dhe e papërshtatshme. Dhe kur shkuam më tej, u bë krejtësisht e frikshme, sepse vendosëm të gjithë strukturën me terraform, dhe befas doli që mjeshtri i jashtëm nuk mbështetej nga terraformi. Po, Google ka një CLI, por për disa arsye gjithçka funksiononte këtu herë pas here - ndonjëherë krijohet, ndonjëherë nuk krijohet. Ndoshta sepse CLI u shpik për migrimin e të dhënave të jashtme, dhe jo për kopje.

Në fakt, në këtë pikë u bë e qartë se Cloud SQL nuk është aspak i përshtatshëm. Siç thonë ata, ne bëmë gjithçka që mundëm.

Opsioni i zgjidhjes nr. 2

Meqenëse nuk ishte e mundur të qëndronim brenda kornizës së Cloud SQL, ne u përpoqëm të formulonim kërkesat për një zgjidhje kompromisi. Kërkesat rezultuan të jenë si më poshtë:

• puna në Kubernetes, përdorimi maksimal i burimeve dhe aftësive të Kubernetes (DCS, ...) dhe GCP (LB, ...);
• mungesa e çakëllit nga një mori gjërash të panevojshme në re si përfaqësuesi HA;
• aftësia për të ekzekutuar PostgreSQL ose MySQL në rajonin kryesor HA; në rajone të tjera - HA nga RR e rajonit kryesor plus kopjen e tij (për besueshmëri);
• multi master (nuk doja të kontaktoja me të, por nuk ishte shumë e rëndësishme)

.
Si rezultat i këtyre kërkesave, pDBMS të përshtatshme dhe opsione të detyrueshme:

• MySQL Galera;
• BuburreciDB;
• Mjetet PostgreSQL

:
- pgpool-II;
- Patroni.

MySQL Galera

Teknologjia MySQL Galera u zhvillua nga Codership dhe është një shtojcë për InnoDB. Veçoritë:

• multi master;
• replikimi sinkron;
• lexim nga çdo nyje;
• regjistrim në çdo nyje;
• mekanizëm i integruar HA;
• Ekziston një tabelë Helm nga Bitnami.

BuburreciDB

Sipas përshkrimit, gjëja është absolutisht bombë dhe është një projekt me kod të hapur i shkruar në Go. Pjesëmarrësi kryesor është Cockroach Labs (themeluar nga njerëz nga Google). Kjo DBMS relacionale fillimisht u krijua për t'u shpërndarë (me shkallëzim horizontal jashtë kutisë) dhe tolerante ndaj gabimeve. Autorët e saj nga kompania përshkruan qëllimin e "kombinimit të pasurisë së funksionalitetit SQL me aksesin horizontal të njohur për zgjidhjet NoSQL".

Një bonus i mirë është mbështetja për protokollin e lidhjes post-gress.

Pgpool

Kjo është një shtesë e PostgreSQL, në fakt, një entitet i ri që merr përsipër të gjitha lidhjet dhe i përpunon ato. Ka balancuesin dhe analizuesin e vet të ngarkesës, të licencuar sipas licencës BSD. Ajo ofron mundësi të bollshme, por duket disi e frikshme, sepse prania e një entiteti të ri mund të bëhet burimi i disa aventurave shtesë.

Patroni

Kjo është gjëja e fundit në të cilën më ranë sytë dhe, siç doli, jo më kot. Patroni është një mjet me burim të hapur, i cili në thelb është një demon i Python që ju lejon të ruani automatikisht grupimet PostgreSQL me lloje të ndryshme të replikimit dhe ndërrimin automatik të roleve. Gjëja doli të ishte shumë interesante, pasi integrohet mirë me kuberin dhe nuk prezanton asnjë entitet të ri.

Çfarë zgjodhët në fund?

Zgjedhja nuk ishte e lehtë:

1. BuburreciDB - zjarr, por i errët;
2. MySQL Galera - gjithashtu jo keq, përdoret në shumë vende, por MySQL;
3. Pgpool — shumë entitete të panevojshme, pra integrim me cloud dhe K8;
4. Patroni - Integrim i shkëlqyer me K8, pa entitete të panevojshme, integrohet mirë me GCP LB.

Kështu, zgjedhja ra mbi Patroni.

Gjetjet

Është koha për të përmbledhur shkurt. Po, bota e infrastrukturës IT ka ndryshuar ndjeshëm dhe ky është vetëm fillimi. Dhe nëse më parë retë ishin thjesht një lloj tjetër infrastrukture, tani gjithçka është ndryshe. Për më tepër, risitë në re po shfaqen vazhdimisht, ato do të shfaqen dhe, ndoshta, do të shfaqen vetëm në re dhe vetëm atëherë, me përpjekjet e startup-eve, do të transferohen në On-premises.

Sa për SQL, SQL do të jetojë. Kjo do të thotë që ju duhet të njihni PostgreSQL dhe MySQL dhe të jeni në gjendje të punoni me to, por edhe më e rëndësishme është të jeni në gjendje t'i përdorni ato në mënyrë korrekte.

Burimi: www.habr.com