Pozdrav, stanovnici Khabrovsk. Danas počinje nastava u prvoj grupi tečaja . S tim u vezi, želimo vam reći kako je protekao otvoreni webinar na ovom tečaju.
В razgovarali smo o izazovima s kojima se SQL baze podataka suočavaju u eri oblaka i Kubernetesa. Istodobno smo promatrali kako se SQL baze podataka prilagođavaju i mijenjaju pod utjecajem ovih izazova.
Webinar je održan , Google Cloud Practice voditelj isporuke u EPAM Systems.
Kad je drveće bilo malo...
Prvo, prisjetimo se kako je počeo izbor DBMS-a krajem prošlog stoljeća. Međutim, to neće biti teško, jer je izbor DBMS-a tih dana počeo i završio Proročanstvo.
Kasnih 90-ih i ranih 2-ih nije bilo izbora kada su u pitanju industrijske skalabilne baze podataka. Da, postojale su IBM DBXNUMX, Sybase i neke druge baze podataka koje su dolazile i odlazile, ali općenito nisu bile toliko uočljive na pozadini Oraclea. Sukladno tome, vještine inženjera tog vremena bile su nekako vezane uz jedini izbor koji je postojao.
Oracle DBA morao je moći:
- instalirajte Oracle Server iz distribucijskog paketa;
- konfigurirajte Oracle poslužitelj:
- init.ora;
- slušatelj.ora;
- stvoriti:
- stolni prostori;
- sheme;
- korisnici;
— napraviti sigurnosnu kopiju i vratiti;
— provoditi praćenje;
— baviti se suboptimalnim zahtjevima.
U isto vrijeme, nije bilo posebnih zahtjeva od Oracle DBA:
- znati odabrati optimalnu DBMS ili drugu tehnologiju za pohranu i obradu podataka;
- pružiti visoku dostupnost i horizontalnu skalabilnost (ovo nije uvijek bio problem DBA);
- dobro poznavanje predmetnog područja, infrastrukture, arhitekture aplikacije, OS-a;
- učitavanje i istovar podataka, migriranje podataka između različitih DBMS-ova.
Općenito, ako govorimo o izboru u to vrijeme, on podsjeća na izbor u sovjetskoj trgovini kasnih 80-ih:
Naše vrijeme
Od tada je, naravno, drveće raslo, svijet se promijenio i postao je otprilike ovako:
Tržište DBMS-a također se promijenilo, kao što se jasno može vidjeti iz najnovijeg izvješća Gartnera:
I ovdje treba napomenuti da su oblaci, čija popularnost raste, zauzeli svoju nišu. Ako pročitamo isto izvješće Gartnera, vidjet ćemo sljedeće zaključke:
- Mnogi korisnici su na putu premještanja aplikacija u oblak.
- Nove tehnologije se prvo pojavljuju u oblaku i nije činjenica da će ikada prijeći na infrastrukturu koja nije u oblaku.
- Pay-as-you-go model određivanja cijena postao je uobičajen. Svatko želi platiti samo ono što koristi, a to čak nije ni trend, već jednostavno izjava o činjenici.
Što sada?
Danas smo svi u oblaku. A pitanja koja nam se postavljaju pitanja su izbora. A golem je, čak i ako govorimo samo o izboru DBMS tehnologija u On-premises formatu. Također imamo upravljane usluge i SaaS. Samim time izbor svake godine postaje samo teži.
Uz pitanja izbora, tu su i ograničavajući faktori:
- cijena. Mnoge tehnologije još uvijek koštaju;
- vještine. Ako govorimo o slobodnom softveru, postavlja se pitanje vještina, budući da slobodni softver zahtijeva dostatnu kompetenciju ljudi koji ga postavljaju i rukuju njime;
- funkcionalna. Nemaju sve usluge koje su dostupne u oblaku i izgrađene, recimo, čak ni na istom Postgresu, iste značajke kao Postgres On-premises. Ovo je bitan faktor koji treba znati i razumjeti. Štoviše, ovaj faktor postaje važniji od znanja o nekim skrivenim mogućnostima jednog DBMS-a.
Što se sada očekuje od DA/DE:
- dobro razumijevanje predmetnog područja i arhitekture aplikacije;
- sposobnost ispravnog odabira odgovarajuće tehnologije DBMS-a, uzimajući u obzir zadatak koji je pri ruci;
- sposobnost odabira optimalne metode za implementaciju odabrane tehnologije u kontekstu postojećih ograničenja;
- sposobnost obavljanja prijenosa i migracije podataka;
- sposobnost implementacije i rada odabranih rješenja.
Donji primjer na temelju GCP-a pokazuje kako funkcionira izbor jedne ili druge tehnologije za rad s podacima ovisno o njihovoj strukturi:
Imajte na umu da PostgreSQL nije uključen u shemu, a to je zato što je skriven ispod terminologije SQL u oblaku. A kada dođemo do Cloud SQL-a, moramo ponovno napraviti izbor:
Treba napomenuti da ovaj izbor nije uvijek jasan, pa se programeri aplikacija često vode intuicijom.
Ukupno:
- Što dalje idete, pitanje izbora postaje goruće. Čak i ako pogledate samo GCP, upravljane usluge i SaaS, tada se RDBMS spominje tek na 4. koraku (a tu je i Spanner u blizini). Plus, u 5. koraku se pojavljuje izbor PostgreSQL, a pored njega tu su i MySQL i SQL Server, tj. ima puno svega, ali treba birati.
- Ne smijemo zaboraviti na ograničenja u pozadini iskušenja. Uglavnom svi žele Spanner, ali je skup. Kao rezultat toga, tipični zahtjev izgleda otprilike ovako: "Molim vas, napravite nam Spanner, ali za cijenu Cloud SQL-a, vi ste profesionalci!"
Što da radimo?
Bez pretenzija da je to konačna istina, recimo sljedeće:
Moramo promijeniti pristup učenju:
- nema smisla podučavati na način na koji su se prije podučavali DBA;
- poznavanje jednog proizvoda više nije dovoljno;
- ali poznavanje desetaka na razini jedan je nemoguće.
Morate znati ne samo i ne koliko je proizvod, već:
- slučaj upotrebe njegove primjene;
- različite metode postavljanja;
- prednosti i nedostaci svake metode;
- slične i alternativne proizvode kako biste napravili informiran i optimalan izbor, a ne uvijek u korist poznatog proizvoda.
Također morate biti u mogućnosti migrirati podatke i razumjeti osnovna načela integracije s ETL-om.
Pravi slučaj
U nedavnoj prošlosti bilo je potrebno izraditi backend za mobilnu aplikaciju. Do početka rada na njemu backend je već bio razvijen i spreman za implementaciju, a razvojni tim je na ovom projektu proveo oko dvije godine. Postavljeni su sljedeći zadaci:
- izgraditi CI/CD;
- pregledati arhitekturu;
- sve to staviti u pogon.
Sama aplikacija bila je mikroservis, a Python/Django kod razvijen je od nule i izravno u GCP-u. Što se tiče ciljane publike, pretpostavljeno je da će postojati dvije regije - SAD i EU, a promet se distribuirao kroz Global Load balancer. Sva radna opterećenja i radno opterećenje računanja izvodili su se na Google Kubernetes Engineu.
Što se tiče podataka, postojale su 3 strukture:
- Pohrana u oblaku;
- Datastore;
- Cloud SQL (PostgreSQL).
Netko bi se mogao zapitati zašto je odabran Cloud SQL? Istini za volju, takvo je pitanje posljednjih godina izazvalo neku vrstu neugodne stanke - postoji osjećaj da su ljudi postali sramežljivi prema relacijskim bazama podataka, ali ih svejedno nastavljaju aktivno koristiti ;-).
Što se tiče našeg slučaja, Cloud SQL je odabran iz sljedećih razloga:
- Kao što je spomenuto, aplikacija je razvijena pomoću Djanga i ima model za mapiranje trajnih podataka iz SQL baze podataka u Python objekte (Django ORM).
- Sam okvir je podržavao prilično konačan popis DBMS-ova:
- PostgreSQL;
- MariaDB;
- MySQL;
- proročišta;
- SQLite.
Sukladno tome, PostgreSQL je odabran s ovog popisa prilično intuitivno (pa, nije Oracle da bira, stvarno).
Što je nedostajalo:
- aplikacija je postavljena samo u 2 regije, a treća se pojavila u planu (Azija);
- Baza podataka nalazila se u sjevernoameričkoj regiji (Iowa);
- od strane kupca postojala je zabrinutost oko mogućih kašnjenja pristupa iz Europe i Azije i prekidi u službi u slučaju zastoja DBMS-a.
Unatoč činjenici da sam Django može raditi s nekoliko baza podataka paralelno i podijeliti ih na čitanje i pisanje, u aplikaciji nije bilo toliko pisanja (više od 90% je čitanje). I općenito, i općenito, ako je to bilo moguće učiniti read-replika glavne baze u Europi i Aziji, ovo bi bilo kompromisno rješenje. Pa, što je tu tako komplicirano?
Poteškoća je bila u tome što kupac nije želio odustati od korištenja upravljanih usluga i Cloud SQL-a. A mogućnosti Cloud SQL-a trenutno su ograničene. Cloud SQL podržava visoku dostupnost (HA) i čitanje replike (RR), ali isti RR podržan je samo u jednoj regiji. Nakon što ste kreirali bazu podataka u američkoj regiji, ne možete napraviti repliku za čitanje u europskoj regiji koristeći Cloud SQL, iako vas sam Postgres ne sprječava u tome. Prepiska sa zaposlenicima Googlea nije vodila nikuda i završila je obećanjima u stilu “znamo problem i radimo na njemu, jednog dana će problem biti riješen”.
Ako ukratko nabrojimo mogućnosti Cloud SQL-a, to će izgledati otprilike ovako:
1. Visoka dostupnost (HA):
- unutar jedne regije;
- putem replikacije diska;
- PostgreSQL motori se ne koriste;
- moguće automatsko i ručno upravljanje - failover/failback;
- Prilikom prebacivanja, DBMS je nedostupan nekoliko minuta.
2. Pročitajte repliku (RR):
- unutar jedne regije;
- vruće stanje pripravnosti;
- PostgreSQL strujanje replikacije.
Osim toga, kao što je uobičajeno, pri odabiru tehnologije uvijek se susrećete s nekima ograničenja:
- kupac nije želio kreirati entitete i koristiti IaaS, osim kroz GKE;
- kupac ne želi implementirati samoposlužni PostgreSQL/MySQL;
- Pa, općenito, Google Spanner bi bio sasvim prikladan da nije njegove cijene, međutim, Django ORM ne može raditi s njim, ali to je dobra stvar.
S obzirom na situaciju, kupac je dobio dodatno pitanje: "Možete li napraviti nešto slično tako da bude kao Google Spanner, ali da radi i s Django ORM-om?"
Mogućnost rješenja br. 0
Prvo što mi je palo na pamet:
- ostati unutar CloudSQL-a;
- neće biti ugrađene replikacije između regija u bilo kojem obliku;
- pokušati priložiti repliku na postojeći Cloud SQL by PostgreSQL;
- pokrenite PostgreSQL instancu negdje i nekako, ali barem ne dirajte master.
Jao, pokazalo se da se to ne može učiniti, jer nema pristupa hostu (ukupno je u drugom projektu) - pg_hba i tako dalje, a također nema pristupa pod superuserom.
Mogućnost rješenja br. 1
Nakon daljnjeg razmišljanja i uzimanja u obzir prethodnih okolnosti, tijek misli se donekle promijenio:
- I dalje pokušavamo ostati unutar CloudSQL-a, ali prelazimo na MySQL, jer Cloud SQL by MySQL ima vanjski master koji:
— je proxy za vanjski MySQL;
- izgleda kao MySQL instanca;
- izumljen za migraciju podataka iz drugih oblaka ili lokalnog sustava.
Budući da postavljanje MySQL replikacije ne zahtijeva pristup hostu, u principu je sve radilo, ali je bilo vrlo nestabilno i nezgodno. A kad smo otišli dalje, postalo je potpuno strašno, jer smo cijelu strukturu postavili teraformom, a odjednom se pokazalo da vanjski master nije poduprt teraformom. Da, Google ima CLI, ali iz nekog razloga ovdje je sve radilo s vremena na vrijeme - ponekad se stvori, ponekad se ne stvori. Možda zato što je CLI izmišljen za vanjsku migraciju podataka, a ne za replike.
Zapravo, u ovom je trenutku postalo jasno da Cloud SQL uopće nije prikladan. Kako kažu, učinili smo sve što smo mogli.
Mogućnost rješenja br. 2
Budući da nije bilo moguće ostati unutar Cloud SQL okvira, pokušali smo formulirati zahtjeve za kompromisno rješenje. Ispostavilo se da su zahtjevi sljedeći:
- rad u Kubernetesu, maksimalno korištenje resursa i mogućnosti Kubernetesa (DCS, ...) i GCP (LB, ...);
- nedostatak balasta od hrpe nepotrebnih stvari u oblaku poput HA proxyja;
- mogućnost pokretanja PostgreSQL ili MySQL u glavnoj HA regiji; u drugim regijama - HA iz RR glavne regije plus njegova kopija (za pouzdanost);
- multimajstor (nisam ga htio kontaktirati, ali nije bilo bitno)
.
Kao rezultat ovih zahtjeva, strprikladni DBMS i opcije vezanja:
- MySQL Galera;
- ŽoharDB;
- PostgreSQL alati
:
- pgpool-II;
— Patroni.
MySQL Galerija
Tehnologiju MySQL Galera razvila je tvrtka Codership i dodatak je za InnoDB. Osobitosti:
- multi master;
- sinkrona replikacija;
- čitanje iz bilo kojeg čvora;
- snimanje na bilo koji čvor;
- ugrađen HA mehanizam;
- Postoji Helmova karta iz Bitnamija.
Bubašvaba DB
Prema opisu, stvar je čista bomba i open source projekt napisan u Go-u. Glavni sudionik je Cockroach Labs (koji su osnovali ljudi iz Googlea). Ovaj relacijski DBMS izvorno je dizajniran da bude distribuiran (s horizontalnim skaliranjem odmah po otvaranju) i tolerantan na greške. Njegovi autori iz tvrtke istaknuli su cilj "kombiniranja bogatstva SQL funkcionalnosti s horizontalnom dostupnošću poznatom NoSQL rješenjima."
Dobar bonus je podrška za post-gress protokol povezivanja.
Pgpool
Ovo je dodatak PostgreSQL-u, zapravo novi entitet koji preuzima sve veze i obrađuje ih. Ima vlastiti balanser opterećenja i parser, licenciran pod BSD licencom. Pruža brojne mogućnosti, ali izgleda pomalo zastrašujuće, jer bi prisutnost novog entiteta mogla postati izvor nekih dodatnih avantura.
pokrovitelj
Ovo je posljednja stvar na koju su mi oči pale, i, kako se pokazalo, ne uzalud. Patroni je uslužni program otvorenog koda, koji je u biti Python demon koji vam omogućuje automatsko održavanje PostgreSQL klastera s različitim vrstama replikacije i automatskom izmjenom uloga. Stvar se pokazala vrlo zanimljivom jer se dobro integrira s cuberom i ne uvodi nikakve nove entitete.
Što ste na kraju odabrali?
Izbor nije bio lak:
- Bubašvaba DB - vatra, ali tamna;
- MySQL Galerija - također nije loše, koristi se na mnogo mjesta, ali MySQL;
- Pgpool — puno nepotrebnih entiteta, tako-tako integracija s oblakom i K8s;
- pokrovitelj - izvrsna integracija s K8s, nema nepotrebnih entiteta, dobro se integrira s GCP LB.
Tako je izbor pao na Patroni.
Zaključci
Vrijeme je da ukratko rezimiramo. Da, svijet IT infrastrukture značajno se promijenio, a ovo je tek početak. I ako su prije oblaci bili samo još jedna vrsta infrastrukture, sada je sve drugačije. Štoviše, inovacije u oblacima se stalno pojavljuju, pojavit će se, a možda će se i pojaviti samo u oblacima i tek tada će, naporima startupa, biti prebačene u On-premises.
Što se tiče SQL-a, SQL će živjeti. To znači da morate poznavati PostgreSQL i MySQL i znati raditi s njima, ali još je važnije znati ih ispravno koristiti.
Izvor: www.habr.com