Sveiki, Habrovskas iedzÄ«votÄji. Å odien sÄkas nodarbÄ«bas kursa pirmajÄ grupÄ . Å ajÄ sakarÄ mÄs vÄlamies jums pastÄstÄ«t par to, kÄ notika Ŕī kursa atklÄtais vebinÄrs.
Š mÄs runÄjÄm par izaicinÄjumiem, ar kuriem saskaras SQL datu bÄzes mÄkoÅu un Kubernetes laikmetÄ. TajÄ paÅ”Ä laikÄ mÄs apskatÄ«jÄm, kÄ SQL datu bÄzes pielÄgojas un mainÄs Å”o izaicinÄjumu ietekmÄ.
VebinÄrs notika , Google Cloud Practice Delivery Manager EPAM Systems.
Kad koki bija mazi...
Vispirms atcerÄsimies, kÄ pagÄjuÅ”Ä gadsimta beigÄs sÄkÄs DBVS izvÄle. TomÄr tas nebÅ«s grÅ«ti, jo DBVS izvÄle tajos laikos sÄkÄs un beidzÄs OrÄkuls.
90. gadu beigÄs un 2. gadu sÄkumÄ praktiski nebija izvÄles, kad runa ir par rÅ«pnieciskÄm mÄrogojamÄm datubÄzÄm. JÄ, bija IBM DBXNUMX, Sybase un dažas citas datu bÄzes, kas nÄca un aizgÄja, bet kopumÄ tÄs nebija tik pamanÄmas uz Oracle fona. AttiecÄ«gi to laiku inženieru prasmes kaut kÄ bija saistÄ«tas ar vienÄ«go pastÄvoÅ”o izvÄli.
Oracle DBA bija jÄspÄj:
- instalÄt Oracle Server no izplatÄ«Å”anas komplekta;
- konfigurÄt Oracle serveri:
- init.ora;
- klausÄ«tÄjs.ora;
- izveidot:
- galda vietas;
- shÄmas;
- lietotÄjiem;
ā veikt dublÄÅ”anu un atjaunoÅ”anu;
ā veikt monitoringu;
ā izskatÄ«t neoptimÄlus pieprasÄ«jumus.
TajÄ paÅ”Ä laikÄ Oracle DBA nebija Ä«paÅ”u prasÄ«bu:
- prast izvÄlÄties optimÄlo DBVS vai citu tehnoloÄ£iju datu uzglabÄÅ”anai un apstrÄdei;
- nodroÅ”inÄt augstu pieejamÄ«bu un horizontÄlo mÄrogojamÄ«bu (tÄ ne vienmÄr bija DBA problÄma);
- labas zinÄÅ”anas par mÄcÄ«bu priekÅ”metu jomu, infrastruktÅ«ru, aplikÄciju arhitektÅ«ru, OS;
- ielÄdÄt un izlÄdÄt datus, migrÄt datus starp dažÄdÄm DBVS.
KopumÄ, ja runÄjam par izvÄli tajos laikos, tas atgÄdina izvÄli padomju veikalÄ 80. gadu beigÄs:
MÅ«su laiks
KopÅ” tÄ laika, protams, koki ir auguÅ”i, pasaule ir mainÄ«jusies, un tas kļuva apmÄram Å”Äds:
ArÄ« DBVS tirgus ir mainÄ«jies, kÄ skaidri redzams jaunÄkajÄ Gartner ziÅojumÄ:
Un te jÄatzÄ«mÄ, ka mÄkoÅi, kuru popularitÄte pieaug, ir ieÅÄmuÅ”i savu niÅ”u. Ja mÄs lasÄm to paÅ”u Gartnera ziÅojumu, mÄs redzÄsim Å”Ädus secinÄjumus:
- Daudzi klienti ir ceÄ¼Ä uz lietojumprogrammu pÄrvietoÅ”anu uz mÄkoni.
- JaunÄs tehnoloÄ£ijas vispirms parÄdÄs mÄkonÄ«, un nav fakts, ka tÄs kÄdreiz pÄries uz infrastruktÅ«ru, kas nav mÄkoÅains.
- Cenu noteikÅ”anas modelis, kurÄ maksÄ, kad iet, ir kļuvis ikdieniŔķs. Ikviens vÄlas maksÄt tikai par to, ko izmanto, un tÄ pat nav tendence, bet vienkÄrÅ”i fakta konstatÄcija.
Ko tagad?
Å odien mÄs visi esam mÄkonÄ«. Un jautÄjumi, kas mums rodas, ir izvÄles jautÄjumi. Un tas ir milzÄ«gs, pat ja runÄjam tikai par DBVS tehnoloÄ£iju izvÄli On-premises formÄtÄ. Mums ir arÄ« pÄrvaldÄ«ti pakalpojumi un SaaS. TÄdÄjÄdi izvÄle ar katru gadu kļūst tikai grÅ«tÄka.
LÄ«dzÄs izvÄles jautÄjumiem ir arÄ« ierobežojoÅ”ie faktori:
- cena. Daudzas tehnoloÄ£ijas joprojÄm maksÄ naudu;
- prasmes. Ja mÄs runÄjam par bezmaksas programmatÅ«ru, tad rodas jautÄjums par prasmÄm, jo āābrÄ«vÄ programmatÅ«ra prasa pietiekamu kompetenci no cilvÄkiem, kuri to izvieto un izmanto;
- funkcionÄls. Ne visiem pakalpojumiem, kas ir pieejami mÄkonÄ« un ir izveidoti, piemÄram, pat tajÄ paÅ”Ä Postgres, ir tÄdas paÅ”as funkcijas kÄ Postgres On-premises. Tas ir bÅ«tisks faktors, kas ir jÄzina un jÄsaprot. TurklÄt Å”is faktors kļūst svarÄ«gÄks par zinÄÅ”anÄm par dažÄm vienas DBVS slÄptÄm iespÄjÄm.
Kas tagad tiek gaidīts no DA/DE:
- laba priekŔmeta jomas un pielietojuma arhitektūras izpratne;
- spÄja pareizi izvÄlÄties atbilstoÅ”o DBVS tehnoloÄ£iju, Åemot vÄrÄ veicamo uzdevumu;
- spÄja izvÄlÄties optimÄlo metodi izvÄlÄtÄs tehnoloÄ£ijas ievieÅ”anai esoÅ”o ierobežojumu kontekstÄ;
- spÄja veikt datu pÄrsÅ«tÄ«Å”anu un migrÄciju;
- spÄja ieviest un darbinÄt izvÄlÄtos risinÄjumus.
ZemÄk piemÄrs pamatojoties uz GSP parÄda, kÄ darbojas vienas vai citas tehnoloÄ£ijas izvÄle darbam ar datiem atkarÄ«bÄ no to struktÅ«ras:
LÅ«dzu, Åemiet vÄrÄ, ka PostgreSQL nav iekļauts shÄmÄ, un tas ir tÄpÄc, ka tas ir paslÄpts zem terminoloÄ£ijas MÄkoÅa SQL. Kad mÄs nonÄkam pie Cloud SQL, mums vÄlreiz jÄizdara izvÄle:
JÄpiebilst, ka Ŕī izvÄle ne vienmÄr ir skaidra, tÄpÄc aplikÄciju izstrÄdÄtÄji bieži vien vadÄs pÄc intuÄ«cijas.
KopÄ:
- Jo tÄlÄk, jo aktuÄlÄks kļūst izvÄles jautÄjums. Un pat ja skatÄties tikai uz GCP, pÄrvaldÄ«tajiem pakalpojumiem un SaaS, tad daži pieminÄjumi par RDBMS parÄdÄs tikai 4. solÄ« (un turpat netÄlu ir Spanner). TurklÄt 5. solÄ« parÄdÄs PostgreSQL izvÄle, un tai blakus ir arÄ« MySQL un SQL Server, tas ir visa kÄ ir daudz, bet jÄizvÄlas.
- MÄs nedrÄ«kstam aizmirst par ierobežojumiem uz kÄrdinÄjumu fona. BÅ«tÄ«bÄ visi vÄlas uzgriežÅu atslÄgu, bet tas ir dÄrgs. RezultÄtÄ tipisks pieprasÄ«jums izskatÄs apmÄram Å”Ädi: āLÅ«dzu, padariet mÅ«s par uzgriežÅu atslÄgu, taÄu par Cloud SQL cenu jÅ«s esat profesionÄļi!ā
Ko man darīt?
NepretendÄjot uz galÄ«go patiesÄ«bu, teiksim sekojoÅ”o:
Mums ir jÄmaina mÅ«su pieeja mÄcÄ«bÄm:
- nav jÄgas mÄcÄ«t tÄ, kÄ iepriekÅ” mÄcÄ«ja DBA;
- ar zinÄÅ”anÄm par vienu produktu vairs nepietiek;
- bet desmitiem zinÄt viena lÄ«menÄ« nav iespÄjams.
Jums jÄzina ne tikai produkta cena, bet arÄ«:
- tÄ pielietojuma lietoÅ”anas gadÄ«jums;
- dažÄdas izvietoÅ”anas metodes;
- katras metodes priekŔrocības un trūkumi;
- lÄ«dzÄ«giem un alternatÄ«viem produktiem, lai izdarÄ«tu apzinÄtu un optimÄlu izvÄli un ne vienmÄr par labu pazÄ«stamam produktam.
Jums arÄ« jÄspÄj migrÄt datus un saprast integrÄcijas ar ETL pamatprincipus.
ReÄls gadÄ«jums
NesenÄ pagÄtnÄ bija nepiecieÅ”ams izveidot aizmuguri mobilajai lietojumprogrammai. LÄ«dz brÄ«dim, kad tika sÄkts darbs pie tÄ, aizmugure jau bija izstrÄdÄta un bija gatava ievieÅ”anai, un izstrÄdes komanda Å”im projektam pavadÄ«ja apmÄram divus gadus. Tika izvirzÄ«ti Å”Ädi uzdevumi:
- veidot CI/CD;
- pÄrskatÄ«t arhitektÅ«ru;
- nodot to visu ekspluatÄcijÄ.
Pati lietojumprogramma bija mikropakalpojumi, un Python/Django kods tika izstrÄdÄts no jauna un tieÅ”i GCP. RunÄjot par mÄrÄ·auditoriju, tika pieÅemts, ka bÅ«s divi reÄ£ioni - ASV un ES, un satiksme tika sadalÄ«ta caur Global Load balancer. Visas darba slodzes un aprÄÄ·inu slodzes darbojÄs Google Kubernetes Engine.
AttiecÄ«bÄ uz datiem bija 3 struktÅ«ras:
- MÄkoÅglabÄtuve;
- Datu krÄtuve;
- MÄkoÅa SQL (PostgreSQL).
VarÄtu rasties jautÄjums, kÄpÄc tika izvÄlÄts Cloud SQL? TaisnÄ«bu sakot, Å”Äds jautÄjums pÄdÄjos gados ir izraisÄ«jis kaut kÄdu neveiklu pauzi - ir sajÅ«ta, ka cilvÄki ir kļuvuÅ”i kautrÄ«gi pret relÄciju datu bÄzÄm, bet tomÄr turpina tÄs aktÄ«vi izmantot ;-).
MÅ«su gadÄ«jumÄ Cloud SQL tika izvÄlÄts Å”Ädu iemeslu dÄļ:
- KÄ minÄts, lietojumprogramma tika izstrÄdÄta, izmantojot Django, un tai ir modelis pastÄvÄ«gu datu kartÄÅ”anai no SQL datu bÄzes uz Python objektiem (Django ORM).
- Pati sistÄma atbalstÄ«ja diezgan ierobežotu DBVS sarakstu:
- PostgreSQL;
- MariaDB;
- MySQL;
- OrÄkuls;
- SQLite.
AttiecÄ«gi PostgreSQL no Ŕī saraksta tika izvÄlÄts diezgan intuitÄ«vi (nu, Oracle tieÅ”Äm nav jÄizvÄlas).
Kas pietrūka:
- lietojumprogramma tika izvietota tikai 2 reÄ£ionos, un plÄnos parÄdÄ«jÄs treÅ”ais (Äzija);
- DatubÄze atradÄs Ziemeļamerikas reÄ£ionÄ (Aiova);
- no klienta puses bija bažas par iespÄjamu piekļuves kavÄÅ”anÄs no Eiropas un Äzijas un pÄrtraukumi servisÄ DBVS dÄ«kstÄves gadÄ«jumÄ.
Neskatoties uz to, ka pats Django var strÄdÄt ar vairÄkÄm datu bÄzÄm paralÄli un sadalÄ«t tÄs lasÄ«Å”anai un rakstÄ«Å”anai, aplikÄcijÄ nebija tik daudz rakstÄ«Å”anas (vairÄk nekÄ 90% ir lasÄ«Å”ana). Un vispÄr, un vispÄr, ja to varÄja izdarÄ«t galvenÄs bÄzes lasÄ«Å”ana-reprodukcija EiropÄ un ÄzijÄ, tas bÅ«tu kompromisa risinÄjums. Nu, kas tur tik sarežģīts?
GrÅ«tÄ«bas radÄ«ja tas, ka klients nevÄlÄjÄs atteikties no pÄrvaldÄ«to pakalpojumu un Cloud SQL lietoÅ”anas. Un Cloud SQL iespÄjas paÅ”laik ir ierobežotas. MÄkoÅa SQL atbalsta augstas pieejamÄ«bas (HA) un lasÄ«Å”anas reprodukciju (RR), taÄu viena un tÄ pati RR tiek atbalstÄ«ta tikai vienÄ reÄ£ionÄ. Izveidojot datubÄzi Amerikas reÄ£ionÄ, jÅ«s nevarat izveidot lasÄ«Å”anas kopiju Eiropas reÄ£ionÄ, izmantojot Cloud SQL, lai gan Postgres pati par sevi neliedz jums to darÄ«t. Sarakste ar Google darbiniekiem nekur nenoveda un beidzÄs ar solÄ«jumiem stilÄ āmÄs zinÄm problÄmu un strÄdÄjam pie tÄs, kÄdreiz problÄma tiks atrisinÄtaā.
Ja mÄs Ä«si uzskaitÄm Cloud SQL iespÄjas, tas izskatÄ«sies apmÄram Å”Ädi:
1. Augsta pieejamība (HA):
- viena reģiona ietvaros;
- izmantojot diska replikÄciju;
- PostgreSQL dzinÄji netiek izmantoti;
- iespÄjama automÄtiska un manuÄla vadÄ«ba - failover/failback;
- PÄrslÄdzoties, DBVS nav pieejama vairÄkas minÅ«tes.
2. Izlasiet reprodukciju (RR):
- viena reģiona ietvaros;
- karstÄ gaidÄ«Å”anas režīms;
- PostgreSQL straumÄÅ”anas replikÄcija.
TurklÄt, kÄ tas ir ierasts, izvÄloties tehnoloÄ£iju, jÅ«s vienmÄr saskaraties ar dažiem ierobežojumiem:
- klients nevÄlÄjÄs izveidot entÄ«tijas un izmantot IaaS, izÅemot, izmantojot GKE;
- klients nevÄlas izvietot paÅ”pakalpojumu PostgreSQL/MySQL;
- Nu, kopumÄ Google Spanner bÅ«tu diezgan piemÄrots, ja tas nebÅ«tu par savu cenu, tomÄr Django ORM ar to nevar strÄdÄt, taÄu tÄ ir laba lieta.
Å emot vÄrÄ situÄciju, klients saÅÄma sekojoÅ”u jautÄjumu: "Vai varat darÄ«t kaut ko lÄ«dzÄ«gu, lai tas bÅ«tu kÄ Google Spanner, bet darbotos arÄ« ar Django ORM?"
RisinÄjuma variants Nr.0
PirmÄ lieta, kas ienÄca prÄtÄ:
- palikt CloudSQL ietvaros;
- starp reÄ£ioniem nebÅ«s iebÅ«vÄtas replikÄcijas nekÄdÄ veidÄ;
- mÄÄ£inÄt pievienot repliku esoÅ”am Cloud SQL, izmantojot PostgreSQL;
- kaut kur un kaut kÄ palaidiet PostgreSQL gadÄ«jumu, bet vismaz nepieskarieties galvenajam.
DiemžÄl izrÄdÄ«jÄs, ka to nevar izdarÄ«t, jo nav piekļuves hostam (tas ir pavisam citÄ projektÄ) - pg_hba un tÄ tÄlÄk, un nav arÄ« piekļuves zem superlietotÄja.
RisinÄjuma variants Nr.1
PÄc turpmÄkÄm pÄrdomÄm un, Åemot vÄrÄ iepriekÅ”Äjos apstÄkļus, domu gÄjiens nedaudz mainÄ«jÄs:
- MÄs joprojÄm cenÅ”amies palikt CloudSQL ietvaros, taÄu mÄs pÄrejam uz MySQL, jo Cloud SQL by MySQL ir ÄrÄjs galvenais serveris, kas:
ā ir ÄrÄja MySQL starpniekserveris;
- izskatÄs pÄc MySQL instances;
- izgudrots datu migrÄÅ”anai no citiem mÄkoÅiem vai lokÄlÄm vietÄm.
TÄ kÄ MySQL replikÄcijas iestatÄ«Å”anai nav nepiecieÅ”ama piekļuve resursdatoram, principÄ viss darbojÄs, taÄu tas bija ļoti nestabils un neÄrti. Un, kad devÄmies tÄlÄk, kļuva pavisam biedÄjoÅ”i, jo mÄs izvietojÄm visu konstrukciju ar terraformu, un pÄkÅ”Åi izrÄdÄ«jÄs, ka ÄrÄjais meistars nav atbalstÄ«ts ar terraformu. JÄ, Google ir CLI, taÄu kaut kÄdu iemeslu dÄļ Å”eit ik pa laikam viss darbojÄs - dažreiz tas tiek izveidots, dažreiz tas nav izveidots. VarbÅ«t tÄpÄc, ka CLI tika izgudrots ÄrÄjai datu migrÄcijai, nevis replikÄm.
PatiesÄ«bÄ Å”ajÄ brÄ«dÄ« kļuva skaidrs, ka Cloud SQL vispÄr nav piemÄrots. KÄ saka, darÄ«jÄm visu, ko varÄjÄm.
RisinÄjuma variants Nr.2
TÄ kÄ nebija iespÄjams palikt Cloud SQL ietvaros, mÄs centÄmies formulÄt prasÄ«bas kompromisa risinÄjumam. PrasÄ«bas izrÄdÄ«jÄs Å”Ädas:
- darbs Kubernetes, Kubernetes (DCS, ...) un GCP (LB, ...) resursu un iespÄju maksimÄla izmantoÅ”ana;
- balasta trÅ«kums no daudzÄm nevajadzÄ«gÄm lietÄm mÄkonÄ«, piemÄram, HA starpniekserveris;
- iespÄja palaist PostgreSQL vai MySQL galvenajÄ HA reÄ£ionÄ; citos reÄ£ionos - HA no galvenÄ reÄ£iona RR plus tÄ kopija (uzticamÄ«bas labad);
- multi meistars (es negribÄju ar viÅu sazinÄties, bet tas nebija Ä«paÅ”i svarÄ«gi)
.
Å o prasÄ«bu rezultÄtÄ ppiemÄrotas DBVS un saistÄ«Å”anas iespÄjas:
- MySQL Galera;
- PrusakuDB;
- PostgreSQL rīki
:
- pgpool-II;
ā Patrons.
MySQL Galera
MySQL Galera tehnoloÄ£iju izstrÄdÄja Codership, un tÄ ir InnoDB spraudnis. ÄŖpatnÄ«bas:
- multi meistars;
- sinhronÄ replikÄcija;
- lasīŔana no jebkura mezgla;
- ierakstÄ«Å”ana jebkurÄ mezglÄ;
- iebÅ«vÄts HA mehÄnisms;
- Ir Helm diagramma no Bitnami.
TarakÄnsDB
PÄc apraksta lieta ir absolÅ«ti bomba un ir Go rakstÄ«ts atvÄrtÄ koda projekts. Galvenais dalÄ«bnieks ir Cockroach Labs (dibinÄja cilvÄki no Google). Å Ä« relÄciju DBVS sÄkotnÄji tika izstrÄdÄta izplatÄ«Å”anai (ar horizontÄlu mÄrogoÅ”anu no komplektÄcijas) un kļūdu tolerantu. TÄs autori no uzÅÄmuma izklÄstÄ«ja mÄrÄ·i "apvienot SQL funkcionalitÄtes bagÄtÄ«bu ar horizontÄlo pieejamÄ«bu, kas pazÄ«stama NoSQL risinÄjumiem".
Jauks bonuss ir atbalsts savienojuma protokolam pÄc progresa.
pgpool
Å is ir PostgreSQL papildinÄjums, faktiski jauna entÄ«tija, kas pÄrÅem visus savienojumus un apstrÄdÄ tos. Tam ir savs slodzes balansÄtÄjs un parsÄtÄjs, kas licencÄts saskaÅÄ ar BSD licenci. Tas sniedz plaÅ”as iespÄjas, bet izskatÄs nedaudz biedÄjoÅ”i, jo jaunas bÅ«tnes klÄtbÅ«tne var kļūt par dažu papildu piedzÄ«vojumu avotu.
Patroni
Å Ä« ir pÄdÄjÄ lieta, uz ko manas acis iekrita, un, kÄ izrÄdÄ«jÄs, ne velti. Patroni ir atvÄrtÄ pirmkoda utilÄ«ta, kas bÅ«tÄ«bÄ ir Python dÄmons, kas ļauj automÄtiski uzturÄt PostgreSQL klasterus ar dažÄda veida replikÄciju un automÄtisku lomu maiÅu. Lieta izrÄdÄ«jÄs ļoti interesanta, jo tÄ labi integrÄjas ar kuberu un neievieÅ” jaunas entÄ«tijas.
Ko jÅ«s beigÄs izvÄlÄjÄties?
IzvÄle nebija viegla:
- TarakÄnsDB - uguns, bet tumÅ”s;
- MySQL Galera - arī nav slikti, to lieto daudzviet, bet MySQL;
- pgpool ā daudz nevajadzÄ«gu entÄ«tiju, tÄ-tik integrÄcija ar mÄkoni un K8s;
- Patroni - lieliska integrÄcija ar K8s, nav nevajadzÄ«gu entÄ«tiju, labi integrÄjas ar GCP LB.
TÄdÄjÄdi izvÄle krita uz Patroni.
Atzinumi
Ir pienÄcis laiks Ä«si apkopot. JÄ, IT infrastruktÅ«ras pasaule ir bÅ«tiski mainÄ«jusies, un tas ir tikai sÄkums. Un, ja agrÄk mÄkoÅi bija tikai cita veida infrastruktÅ«ra, tad tagad viss ir savÄdÄk. TurklÄt jauninÄjumi mÄkoÅos parÄdÄs nepÄrtraukti, parÄdÄ«sies un, iespÄjams, parÄdÄ«sies tikai mÄkoÅos un tikai tad ar startup pÅ«lÄm tiks pÄrnesti uz On-premises.
Kas attiecas uz SQL, SQL dzÄ«vos. Tas nozÄ«mÄ, ka jums ir jÄzina PostgreSQL un MySQL un jÄprot ar tiem strÄdÄt, bet vÄl svarÄ«gÄk ir prast tos pareizi lietot.
Avots: www.habr.com