Pozdravljeni, prebivalci Khabrovsk. Danes se začne pouk v prvi skupini tečaja . V zvezi s tem vam želimo povedati, kako je potekal odprti spletni seminar o tem tečaju.
В govorili smo o izzivih, s katerimi se soočajo baze podatkov SQL v dobi oblakov in Kubernetesa. Hkrati smo pogledali, kako se baze podatkov SQL prilagajajo in mutirajo pod vplivom teh izzivov.
Webinar je bil izveden , Google Cloud Practice Delivery Manager pri EPAM Systems.
Ko so bila drevesa majhna ...
Najprej se spomnimo, kako se je izbira DBMS začela konec prejšnjega stoletja. Vendar to ne bo težko, saj se je izbira DBMS v tistih dneh začela in končala Oracle.
V poznih 90-ih in zgodnjih 2-ih v bistvu ni bilo izbire, ko gre za industrijske razširljive baze podatkov. Da, bile so IBM DBXNUMX, Sybase in nekatere druge baze podatkov, ki so prišle in odšle, vendar na splošno niso bile tako opazne v ozadju Oracle. Skladno s tem so bile veščine inženirjev tistega časa nekako vezane na edino izbiro, ki je obstajala.
Oracle DBA je moral biti sposoben:
- namestite strežnik Oracle iz distribucijskega kompleta;
- konfigurirajte strežnik Oracle:
- init.ora;
- poslušalec.ora;
- ustvariti:
- mizni prostori;
- sheme;
- uporabniki;
— izdelati varnostno kopijo in obnoviti;
— izvajati spremljanje;
— obravnavati neoptimalne zahteve.
Hkrati Oracle DBA ni imel posebnih zahtev:
- znati izbrati optimalno DBMS ali drugo tehnologijo za shranjevanje in obdelavo podatkov;
- zagotoviti visoko razpoložljivost in horizontalno razširljivost (to ni bila vedno težava DBA);
- dobro poznavanje predmetnega področja, infrastrukture, arhitekture aplikacije, OS;
- nalaganje in razlaganje podatkov, selitev podatkov med različnimi DBMS.
Na splošno, če govorimo o izbiri v tistih časih, je podobna izbiri v sovjetski trgovini v poznih 80-ih:
Naš čas
Od takrat so seveda drevesa zrasla, svet se je spremenil in postal je nekako takole:
Tudi trg DBMS se je spremenil, kot je jasno razvidno iz najnovejšega poročila Gartnerja:
In tukaj je treba opozoriti, da so oblaki, katerih priljubljenost narašča, zasedli svojo nišo. Če preberemo isto Gartnerjevo poročilo, bomo videli naslednje zaključke:
- Veliko strank je na poti premakniti aplikacije v oblak.
- Nove tehnologije se najprej pojavijo v oblaku in ni dejstvo, da se bodo kdaj preselile v neoblačno infrastrukturo.
- Model plačevanja po uporabi je postal vsakdanjik. Vsakdo želi plačati samo tisto, kar uporablja, in to niti ni trend, ampak preprosto izjava o dejstvih.
Kaj zdaj?
Danes smo vsi v oblaku. In vprašanja, ki se nam porajajo, so vprašanja izbire. In to je ogromno, tudi če govorimo le o izbiri tehnologij DBMS v formatu On-premises. Imamo tudi upravljane storitve in SaaS. Tako je izbira vsako leto le težja.
Poleg izbirnih vprašanj obstajajo tudi omejevalni dejavniki:
- Cena. Številne tehnologije še vedno stanejo;
- spretnosti. Če govorimo o brezplačnem programju, se pojavi vprašanje veščin, saj prosto programje zahteva zadostno usposobljenost ljudi, ki ga nameščajo in upravljajo;
- delujoč. Vse storitve, ki so na voljo v oblaku in zgrajene, recimo, celo na istem Postgresu, nimajo enakih funkcij kot Postgres On-premises. To je bistven dejavnik, ki ga je treba poznati in razumeti. Poleg tega postane ta dejavnik pomembnejši od poznavanja nekaterih skritih zmožnosti posameznega DBMS.
Kaj se zdaj pričakuje od DA/DE:
- dobro razumevanje predmetnega področja in arhitekture aplikacije;
- sposobnost pravilne izbire ustrezne tehnologije DBMS ob upoštevanju zastavljene naloge;
- sposobnost izbire optimalnega načina implementacije izbrane tehnologije glede na obstoječe omejitve;
- sposobnost izvajanja prenosa in migracije podatkov;
- sposobnost izvajanja in delovanja izbranih rešitev.
Spodaj primer temelji na GCP prikazuje, kako poteka izbira ene ali druge tehnologije za delo s podatki glede na njihovo strukturo:
Upoštevajte, da PostgreSQL ni vključen v shemo, in to zato, ker je skrit pod terminologijo SQL v oblaku. In ko pridemo do Cloud SQL, se moramo znova odločiti:
Treba je opozoriti, da ta izbira ni vedno jasna, zato razvijalce aplikacij pogosto vodi intuicija.
Skupaj:
- Dlje kot greš, bolj pereče postaja vprašanje izbire. In tudi če pogledate samo GCP, upravljane storitve in SaaS, se nekaj omemb RDBMS pojavi šele na 4. koraku (in tam je blizu Spanner). Poleg tega se v 5. koraku pojavi izbira PostgreSQL, zraven pa še MySQL in SQL Server, tj. vsega je veliko, a je treba izbrati.
- Ne smemo pozabiti na omejitve v ozadju skušnjav. V bistvu si vsi želijo Spanner, vendar je drag. Kot rezultat, tipična zahteva izgleda nekako takole: "Prosim, naredite nam Spanner, vendar za ceno Cloud SQL ste profesionalci!"
Kaj naj storimo?
Ne da bi trdili, da je končna resnica, povejmo naslednje:
Spremeniti moramo pristop k učenju:
- nima smisla poučevati tako, kot so poučevali DBA prej;
- poznavanje enega izdelka ni več dovolj;
- a poznavanje desetin na ravni ena je nemogoče.
Vedeti morate ne samo in ne koliko je izdelek, ampak:
- primer uporabe njegove aplikacije;
- različne metode uvajanja;
- prednosti in slabosti posamezne metode;
- podobnih in alternativnih izdelkov, da naredijo ozaveščeno in optimalno izbiro in ne vedno v korist znanega izdelka.
Prav tako morate znati seliti podatke in razumeti osnovna načela integracije z ETL.
Pravi primer
V bližnji preteklosti je bilo treba ustvariti zaledje za mobilno aplikacijo. Do začetka dela na njem je bilo zaledje že razvito in pripravljeno za implementacijo, razvojna ekipa pa je za ta projekt porabila približno dve leti. Zastavljene so bile naslednje naloge:
- zgraditi CI/CD;
- pregledati arhitekturo;
- spraviti vse v pogon.
Sama aplikacija je bila mikrostoritev, koda Python/Django pa je bila razvita iz nič in neposredno v GCP. Kar zadeva ciljno občinstvo, je bilo predvideno, da bosta obstajali dve regiji - ZDA in EU, promet pa je bil porazdeljen prek Global Load balancerja. Vse delovne obremenitve in računska delovna obremenitev so se izvajale na Google Kubernetes Engine.
Kar zadeva podatke, so bile 3 strukture:
- Shranjevanje v oblaku;
- shramba podatkov;
- Cloud SQL (PostgreSQL).
Lahko bi se vprašali, zakaj je bil izbran Cloud SQL? Resnici na ljubo je takšno vprašanje v zadnjih letih povzročilo neprijeten premor - obstaja občutek, da so ljudje postali sramežljivi do relacijskih baz podatkov, a jih kljub temu še naprej aktivno uporabljajo ;-).
V našem primeru je bil Cloud SQL izbran iz naslednjih razlogov:
- Kot že omenjeno, je bila aplikacija razvita z uporabo Djanga in ima model za preslikavo trajnih podatkov iz baze podatkov SQL v objekte Python (Django ORM).
- Sam okvir je podpiral dokaj omejen seznam DBMS-jev:
- PostgreSQL;
- MariaDB;
- MySQL;
- oraklji;
- SQLite.
V skladu s tem je bil PostgreSQL izbran s tega seznama precej intuitivno (no, res ni Oracle, da bi izbral).
Kaj je manjkalo:
- aplikacija je bila nameščena samo v 2 regijah, tretja pa se je pojavila v načrtih (Azija);
- Baza podatkov je bila locirana v severnoameriški regiji (Iowa);
- s strani stranke so bili pomisleki glede možnih zamude pri dostopu iz Evrope in Azije ter prekinitve v službi v primeru izpada DBMS.
Kljub temu, da zna Django sam delati z več zbirkami podatkov vzporedno in jih razdeliti na branje in pisanje, pisanja v aplikaciji ni bilo toliko (več kot 90% je branje). In na splošno in na splošno, če bi bilo mogoče read-replika glavne baze v Evropi in Aziji, bi bila to kompromisna rešitev. No, kaj je tako zapletenega?
Težava je bila v tem, da stranka ni želela opustiti uporabe upravljanih storitev in Cloud SQL. In zmogljivosti Cloud SQL so trenutno omejene. Cloud SQL podpira visoko razpoložljivost (HA) in branje replike (RR), vendar je isti RR podprt samo v eni regiji. Ko ste ustvarili bazo podatkov v ameriški regiji, ne morete narediti replike branja v evropski regiji z uporabo Cloud SQL, čeprav vam sam Postgres tega ne preprečuje. Dopisovanje z zaposlenimi pri Googlu ni privedlo nikamor in se je končalo z obljubami v stilu »poznamo težavo in delamo na njej, nekega dne bo težava rešena«.
Če na kratko naštejemo zmogljivosti Cloud SQL, bo videti nekako takole:
1. Visoka razpoložljivost (HA):
- znotraj ene regije;
- prek replikacije diska;
- Motorji PostgreSQL se ne uporabljajo;
- možno avtomatsko in ročno krmiljenje - failover/failback;
- Pri preklopu je DBMS več minut nedosegljiv.
2. Preberi repliko (RR):
- znotraj ene regije;
- vroča pripravljenost;
- Pretočna replikacija PostgreSQL.
Poleg tega se, kot je običajno, pri izbiri tehnologije vedno soočite z nekaterimi omejitve:
- stranka ni želela ustvarjati entitet in uporabljati IaaS, razen prek GKE;
- stranka ne želi uvajati samopostrežnega PostgreSQL/MySQL;
- No, na splošno bi bil Google Spanner zelo primeren, če ne bi bilo njegove cene, vendar Django ORM ne more delati z njim, vendar je dobra stvar.
Glede na situacijo je stranka prejela dodatno vprašanje: »Ali lahko naredite nekaj podobnega, tako da bo kot Google Spanner, vendar bo deloval tudi z Django ORM?«
Možnost rešitve št. 0
Prva stvar, ki mi je prišla na misel:
- ostati znotraj CloudSQL;
- v nobeni obliki ne bo vgrajenega podvajanja med regijami;
- poskusite pritrditi repliko na obstoječi Cloud SQL s strani PostgreSQL;
- zaženite primerek PostgreSQL nekje in nekako, vendar se vsaj ne dotikajte masterja.
Žal se je izkazalo, da tega ni mogoče storiti, ker ni dostopa do gostitelja (je v čisto drugem projektu) - pg_hba in tako naprej, prav tako ni dostopa pod superuserjem.
Možnost rešitve št. 1
Po nadaljnjem razmisleku in ob upoštevanju prejšnjih okoliščin se je tok misli nekoliko spremenil:
- Še vedno poskušamo ostati znotraj CloudSQL, a prehajamo na MySQL, ker ima Cloud SQL by MySQL zunanjega masterja, ki:
— je proxy za zunanji MySQL;
- izgleda kot primerek MySQL;
- izumljeno za selitev podatkov iz drugih oblakov ali na mestu uporabe.
Ker nastavitev replikacije MySQL ne zahteva dostopa do gostitelja, je načeloma vse delovalo, vendar je bilo zelo nestabilno in neprijetno. In ko smo šli dlje, je postalo popolnoma grozljivo, saj smo celotno strukturo razporedili s teraformo in nenadoma se je izkazalo, da zunanji master ni podprt s teraformo. Da, Google ima CLI, vendar je iz nekega razloga tu in tam vse delovalo - včasih je ustvarjeno, včasih ni ustvarjeno. Morda zato, ker je bil CLI izumljen za zunanjo migracijo podatkov in ne za replike.
Pravzaprav je na tej točki postalo jasno, da Cloud SQL sploh ni primeren. Kot pravijo, smo naredili vse, kar smo lahko.
Možnost rešitve št. 2
Ker ni bilo mogoče ostati v okviru Cloud SQL, smo poskušali oblikovati zahteve za kompromisno rešitev. Izkazalo se je, da so zahteve naslednje:
- delo v Kubernetesu, maksimalen izkoristek virov in zmogljivosti Kubernetesa (DCS, ...) in GCP (LB, ...);
- pomanjkanje balasta iz kopice nepotrebnih stvari v oblaku, kot je HA proxy;
- možnost izvajanja PostgreSQL ali MySQL v glavni regiji HA; v drugih regijah - HA iz RR glavne regije plus njegova kopija (za zanesljivost);
- multi mojster (nisem želel kontaktirati z njim, vendar ni bilo zelo pomembno)
.
Vsled teh zahtev je pustrezne DBMS in možnosti vezave:
- MySQL Galera;
- CockroachDB;
- Orodja PostgreSQL
:
- pgpool-II;
— Patroni.
MySQL Galera
Tehnologijo MySQL Galera je razvil Codership in je vtičnik za InnoDB. Posebnosti:
- več mojster;
- sinhrono podvajanje;
- branje iz katerega koli vozlišča;
- snemanje v katero koli vozlišče;
- vgrajen mehanizem HA;
- Obstaja grafikon Helm iz Bitnamija.
Ščurek DB
Po opisu sodeč je zadeva čista bomba in je odprtokodni projekt napisan v Go. Glavni udeleženec je Cockroach Labs (ustanovili so ga ljudje iz Googla). Ta relacijski DBMS je bil prvotno zasnovan za distribucijo (s horizontalnim skaliranjem takoj po namestitvi) in odporen na napake. Njegovi avtorji iz podjetja so orisali cilj "združevanja bogastva funkcionalnosti SQL s horizontalno dostopnostjo, ki je znana rešitvam NoSQL."
Lep bonus je podpora za post-gress povezovalni protokol.
Pgpool
To je dodatek k PostgreSQL, pravzaprav nova entiteta, ki prevzame vse povezave in jih obdela. Ima lasten izenačevalnik obremenitve in razčlenjevalec, licenciran pod licenco BSD. Zagotavlja veliko priložnosti, vendar izgleda nekoliko strašljivo, saj lahko prisotnost nove entitete postane vir nekaterih dodatnih dogodivščin.
Patroni
To je zadnja stvar, na katero so mi padle oči, in kot se je izkazalo, ne zaman. Patroni je odprtokodni pripomoček, ki je v bistvu demon Python, ki vam omogoča samodejno vzdrževanje gruč PostgreSQL z različnimi vrstami replikacije in samodejnim preklapljanjem vlog. Zadeva se je izkazala za zelo zanimivo, saj se dobro integrira s cuberjem in ne uvaja novih entitet.
Kaj ste na koncu izbrali?
Izbira ni bila lahka:
- Ščurek DB - ogenj, vendar temen;
- MySQL Galera - tudi ni slabo, uporablja se marsikje, ampak MySQL;
- Pgpool — veliko nepotrebnih entitet, tako-tako integracija z oblakom in K8s;
- Patroni - odlična integracija s K8s, brez nepotrebnih entitet, dobro se integrira z GCP LB.
Tako je izbira padla na Patroni.
Ugotovitve
Čas je, da na kratko povzamemo. Da, svet IT infrastrukture se je močno spremenil in to je šele začetek. In če so bili prej oblaki le še ena vrsta infrastrukture, je zdaj vse drugače. Še več, inovacije v oblakih se nenehno pojavljajo, pojavljale se bodo in morda le v oblakih in šele nato bodo s prizadevanji startupov prenesene v prostore.
Kar zadeva SQL, bo SQL živel. To pomeni, da morate poznati PostgreSQL in MySQL ter znati delati z njima, še pomembneje pa je, da ju znate pravilno uporabljati.
Vir: www.habr.com