Üdvözlet Habrovszk lakosai! A tanfolyam első csoportjában a mai napon kezdődnek a foglalkozások . Ezzel kapcsolatban szeretnénk elmondani, hogyan zajlott a kurzusról szóló nyílt webinárium.
В beszéltünk az SQL adatbázisok kihívásairól a felhők és a Kubernetes korszakában. Ugyanakkor megvizsgáltuk, hogy az SQL-adatbázisok hogyan alkalmazkodnak és mutálódnak ezeknek a kihívásoknak a hatására.
A webináriumot megtartották , Google Cloud Practice Delivery Manager, EPAM Systems.
Amikor kicsik voltak a fák...
Először is emlékezzünk arra, hogyan kezdődött a DBMS választása a múlt század végén. Ez azonban nem lesz nehéz, mert a DBMS választás akkoriban kezdődött és véget ért Jóslat.
A 90-es évek végén és a 2-es évek elején lényegében nem volt más választás, amikor az ipari méretezhető adatbázisokról volt szó. Igen, voltak IBM DBXNUMX, Sybase és más adatbázisok, amelyek jöttek és mentek, de általában nem voltak annyira feltűnőek az Oracle hátterében. Ennek megfelelően az akkori mérnökök képességei valahogyan az egyetlen létező választáshoz kötődnek.
Az Oracle DBA-nak tudnia kellett:
- telepítse az Oracle Servert a terjesztési készletből;
- Oracle Server konfigurálása:
- init.ora;
- hallgató.ora;
- létrehozni:
- asztalterek;
- rendszer;
- felhasználók;
— biztonsági mentés és visszaállítás végrehajtása;
— ellenőrzés végrehajtása;
— az optimálistól eltérő kérések kezelése.
Ugyanakkor az Oracle DBA-tól nem volt különleges követelmény:
- képes legyen kiválasztani az optimális DBMS-t vagy egyéb technológiát az adatok tárolására és feldolgozására;
- magas rendelkezésre állást és horizontális méretezhetőséget biztosítanak (ez nem mindig volt DBA probléma);
- a témakör, az infrastruktúra, az alkalmazás architektúra, az operációs rendszer jó ismerete;
- adatok betöltése és eltávolítása, adatok migrálása a különböző DBMS-ek között.
Általánosságban elmondható, hogy ha az akkori választásról beszélünk, akkor az egy szovjet boltban történt választáshoz hasonlít a 80-as évek végén:
A mi időnk
Azóta persze nőttek a fák, megváltozott a világ, és valami ilyesmi lett belőle:
A DBMS-piac is megváltozott, amint az jól látható a Gartner legfrissebb jelentéséből:
És itt meg kell jegyezni, hogy a felhők, amelyek népszerűsége növekszik, elfoglalták a rést. Ha elolvassuk ugyanazt a Gartner-jelentést, a következő következtetéseket fogjuk látni:
- Sok ügyfél azon az úton halad, hogy az alkalmazásokat a felhőbe helyezze át.
- Az új technológiák először a felhőben jelennek meg, és nem tény, hogy valaha is áttérnek a nem felhőalapú infrastruktúrára.
- A felosztó-kirovó árképzési modell általánossá vált. Mindenki csak azért akar fizetni, amit használ, és ez nem is trend, hanem egyszerűen ténymegállapítás.
És most?
Ma mindannyian a felhőben vagyunk. A számunkra felmerülő kérdések pedig választás kérdései. És ez óriási, még akkor is, ha csak a DBMS-technológiák helyszíni formátumban történő kiválasztásáról beszélünk. Felügyelt szolgáltatásokkal és SaaS-szel is rendelkezünk. Így a választás évről évre csak nehezebbé válik.
A választási kérdések mellett vannak olyanok is korlátozó tényezők:
- ár. Sok technológia még mindig pénzbe kerül;
- készségeket. Ha szabad szoftverekről beszélünk, akkor felmerül a képességek kérdése, hiszen a szabad szoftverek kellő kompetenciát igényelnek az azt telepítő és üzemeltető emberektől;
- funkcionális. Nem minden szolgáltatás, amely elérhető a felhőben, és mondjuk ugyanarra a Postgresre épül, nem rendelkezik ugyanazokkal a szolgáltatásokkal, mint a Postgres On-premises. Ez egy alapvető tényező, amelyet ismerni és megérteni kell. Sőt, ez a tényező fontosabbá válik, mint egyetlen DBMS egyes rejtett képességeinek ismerete.
Ami most várható a DA/DE-től:
- a témakör és az alkalmazási architektúra jó ismerete;
- a megfelelő DBMS technológia helyes kiválasztásának képessége, figyelembe véve az adott feladatot;
- az optimális módszer kiválasztásának képessége a kiválasztott technológia megvalósításához a meglévő korlátok között;
- adatátvitel és migráció végrehajtásának képessége;
- a kiválasztott megoldások megvalósításának és működtetésének képessége.
Lent példa GCP alapján bemutatja, hogyan működik az adatokkal való munkavégzés egyik vagy másik technológiájának kiválasztása annak szerkezetétől függően:
Kérjük, vegye figyelembe, hogy a PostgreSQL nem szerepel a sémában, és ez azért van, mert el van rejtve a terminológia alatt Felhő SQL. És amikor a Cloud SQL-hez érünk, ismét választanunk kell:
Meg kell jegyezni, hogy ez a választás nem mindig egyértelmű, ezért az alkalmazásfejlesztőket gyakran az intuíció vezérli.
Összesen:
- Minél tovább megy, annál sürgetőbbé válik a választás kérdése. És még ha csak a GCP-t, a felügyelt szolgáltatásokat és a SaaS-t nézzük is, akkor is csak a 4. lépésnél jelenik meg az RDBMS említése (és ott van a Spanner a közelben). Ráadásul az 5. lépésben megjelenik a PostgreSQL választása, és mellette van még a MySQL és az SQL Server, azaz sok minden van, de választani kell.
- Nem szabad megfeledkeznünk a kísértésekkel szembeni korlátozásokról. Alapvetően mindenki villáskulcsot akar, de az drága. Ennek eredményeként egy tipikus kérés valahogy így néz ki: „Kérjük, csináljon nekünk csavarkulcsot, de a Cloud SQL áráért Ön profi!”
De mit kell tenni?
Anélkül, hogy azt állítanánk, hogy ez a végső igazság, mondjuk a következőket:
Meg kell változtatnunk a tanuláshoz való hozzáállásunkat:
- nincs értelme úgy tanítani, ahogyan korábban a DBA-kat tanították;
- egy termék ismerete már nem elég;
- de tucatokat egy szinten tudni lehetetlen.
Tudnia kell nemcsak és nem a termék ára, hanem:
- alkalmazásának használati esete;
- különböző telepítési módszerek;
- az egyes módszerek előnyei és hátrányai;
- hasonló és alternatív termékeket, hogy tájékozott és optimális választást tudjunk hozni, és nem mindig egy ismerős termék javára.
Ezenkívül képesnek kell lennie az adatok migrálására, és meg kell értenie az ETL-lel való integráció alapelveit.
valós eset
A közelmúltban szükség volt egy mobilalkalmazás háttérprogramjának létrehozására. Mire a munka elkezdődött, a backend már ki lett fejlesztve és készen állt a bevezetésre, és a fejlesztőcsapat körülbelül két évet töltött ezen a projekten. A következő feladatokat tűzték ki:
- CI/CD összeállítása;
- tekintse át az architektúrát;
- üzembe helyezze az egészet.
Maga az alkalmazás mikroszolgáltatásokból állt, a Python/Django kódot pedig a semmiből, közvetlenül a GCP-ben fejlesztették ki. Ami a célközönséget illeti, azt feltételezték, hogy két régió lesz - az Egyesült Államok és az EU, és a forgalmat a Global Load Balanceren keresztül osztják el. Minden munkaterhelés és számítási terhelés a Google Kubernetes Engine-en futott.
Ami az adatokat illeti, 3 struktúra volt:
- Cloud Storage;
- Adattár;
- Cloud SQL (PostgreSQL).
Felmerülhet a kérdés, hogy miért a Cloud SQL-t választották? Az igazat megvallva, egy ilyen kérdés némi kínos szünetet okozott az elmúlt években - van egy olyan érzés, hogy az emberek félénkek lettek a relációs adatbázisokkal szemben, de ennek ellenére továbbra is aktívan használják őket ;-).
A mi esetünkben a Cloud SQL-t választottuk a következő okok miatt:
- Mint említettük, az alkalmazást a Django segítségével fejlesztették ki, és rendelkezik egy modellel az SQL-adatbázisból a Python-objektumokra (Django ORM) lévő állandó adatok leképezésére.
- Maga a keretrendszer a DBMS-ek meglehetősen véges listáját támogatta:
- PostgreSQL;
- MariaDB;
- MySQL;
- Jóslat;
- SQLite.
Ennek megfelelően a PostgreSQL-t meglehetősen intuitív módon választották ki ebből a listából (hát, igazából nem az Oracle-t kell választani).
Ami hiányzott:
- az alkalmazást csak 2 régióban vezették be, és egy harmadik is megjelent a tervekben (Ázsia);
- Az adatbázis az észak-amerikai régióban (Iowa) található;
- az ügyfél részéről aggályok merültek fel a lehetséges hozzáférési késések Európából és Ázsiából és megszakítások szolgálatban DBMS leállás esetén.
Annak ellenére, hogy maga a Django több adatbázissal is tud párhuzamosan dolgozni, és azokat olvasásra és írásra osztja, az alkalmazásban nem volt annyi írás (több mint 90% olvasás). És általában, és általában, ha lehetséges az európai és ázsiai fő bázis olvasási replikája, ez egy kompromisszumos megoldás lenne. Nos, mi ebben olyan bonyolult?
A nehézséget az jelentette, hogy az ügyfél nem akart lemondani a menedzselt szolgáltatások és a Cloud SQL használatáról. A Cloud SQL képességei pedig jelenleg korlátozottak. A Cloud SQL támogatja a magas rendelkezésre állást (HA) és az olvasási replikát (RR), de ugyanaz az RR csak egy régióban támogatott. Miután létrehoztunk egy adatbázist az amerikai régióban, nem készíthetünk olvasási replikát az európai régióban a Cloud SQL használatával, bár maga a Postgres nem akadályozza meg ebben. A Google alkalmazottaival folytatott levelezés nem vezetett sehova, és a következő stílusú ígéretekkel végződött: „ismerjük a problémát, dolgozunk rajta, egyszer majd megoldódik a probléma”.
Ha röviden felsoroljuk a Cloud SQL képességeit, akkor valahogy így fog kinézni:
1. Magas rendelkezésre állás (HA):
- egy régión belül;
- lemezreplikáción keresztül;
- PostgreSQL motorok nem használatosak;
- automatikus és kézi vezérlés lehetséges - feladatátvétel/feladatvisszavétel;
- Váltáskor a DBMS néhány percig nem elérhető.
2. Replika (RR) olvasása:
- egy régión belül;
- forró készenlét;
- PostgreSQL streaming replikáció.
Ezenkívül, ahogy az lenni szokott, a technológia kiválasztásakor mindig szembesül néhány problémával korlátozásokat:
- az ügyfél nem akart entitásokat létrehozni és IaaS-t használni, kivéve a GKE-n keresztül;
- az ügyfél nem szeretne önkiszolgáló PostgreSQL/MySQL-t telepíteni;
- Általánosságban elmondható, hogy a Google Spanner teljesen megfelelő lenne, ha nem az áráért, de a Django ORM nem tud vele működni, de jó dolog.
A helyzetre való tekintettel az ügyfél egy további kérdést kapott: „Csinálhat valami hasonlót, hogy olyan legyen, mint a Google Spanner, de működjön a Django ORM-mel is?”
0. számú megoldási lehetőség
Ami először eszembe jutott:
- maradjon a CloudSQL-en belül;
- nem lesz beépített replikáció a régiók között semmilyen formában;
- próbáljon meg replikát csatolni egy meglévő Cloud SQL-hez a PostgreSQL segítségével;
- indítson el egy PostgreSQL példányt valahol és valahogy, de legalább ne érintse meg a mestert.
Sajnos kiderült, hogy ezt nem lehet megtenni, mert nincs hozzáférés a gazdagéphez (az teljesen más projektben van) - pg_hba és így tovább, és nincs hozzáférés a superuser alatt sem.
1. számú megoldási lehetőség
További elmélkedés és a korábbi körülmények figyelembe vétele után a gondolatmenet némileg megváltozott:
- Továbbra is igyekszünk a CloudSQL-en belül maradni, de átállunk a MySQL-re, mivel a Cloud SQL by MySQL rendelkezik egy külső mesterrel, amely:
— a külső MySQL proxyja;
- úgy néz ki, mint egy MySQL példány;
- más felhőkből vagy helyszíni adatok migrálására találták ki.
Mivel a MySQL replikáció beállítása nem igényel hozzáférést a gazdagéphez, elvileg minden működött, de nagyon instabil és kényelmetlen volt. És amikor tovább mentünk, teljesen ijesztő lett, mert az egész szerkezetet terraformmal telepítettük, és hirtelen kiderült, hogy a külső mestert nem támogatja a terraform. Igen, a Google-nak van CLI-je, de valamiért itt időnként minden működött – néha létrejön, néha nem. Talán azért, mert a CLI-t külső adatmigrációra találták ki, nem pedig replikákhoz.
Valójában ezen a ponton világossá vált, hogy a Cloud SQL egyáltalán nem alkalmas. Ahogy mondani szokás, mindent megtettünk, amit lehetett.
2. számú megoldási lehetőség
Mivel nem lehetett a Cloud SQL keretrendszeren belül maradni, igyekeztünk kompromisszumos megoldási követelményeket megfogalmazni. A követelmények a következők lettek:
- a Kubernetesben végzett munka, a Kubernetes (DCS, ...) és GCP (LB, ...) erőforrásainak és képességeinek maximális kihasználása;
- ballaszt hiánya egy csomó felesleges dologtól a felhőben, mint például a HA proxy;
- a PostgreSQL vagy a MySQL futtatásának képessége a fő HA régióban; más régiókban - HA a fő régió RR-jéből plusz annak másolata (a megbízhatóság érdekében);
- multi master (nem akartam vele felvenni a kapcsolatot, de nem volt túl fontos)
.
Ezen követelések eredményeként a XNUMX. omegfelelő DBMS és kötési lehetőségek:
- MySQL Galera;
- CockroachDB;
- PostgreSQL eszközök
:
- pgpool-II;
— Patroni.
MySQL Galera
A MySQL Galera technológiát a Codership fejlesztette ki, és az InnoDB bővítménye. Sajátosságok:
- multi master;
- szinkron replikáció;
- olvasás bármely csomópontból;
- rögzítés bármely csomópontra;
- beépített HA mechanizmus;
- Van egy Helm diagram a Bitnamitól.
CsótányDB
A leírás szerint a dolog abszolút bomba és egy Go-ban írt nyílt forráskódú projekt. A fő résztvevő a Cockroach Labs (a Google emberei által alapított). Ezt a relációs DBMS-t eredetileg elosztott (vízszintes méretezéssel) és hibatűrésre tervezték. A cég szerzői azt a célt vázolták fel, hogy „az SQL funkcionalitás gazdagságát ötvözzék a NoSQL-megoldásokban megszokott horizontális hozzáférhetőséggel”.
Jó bónusz a post-gress csatlakozási protokoll támogatása.
pgpool
Ez a PostgreSQL kiegészítője, valójában egy új entitás, amely átveszi az összes kapcsolatot és feldolgozza azokat. Saját terheléselosztóval és elemzővel rendelkezik, a BSD licenc alatt. Bőséges lehetőséget kínál, de kissé ijesztőnek tűnik, mert egy új entitás jelenléte további kalandok forrása lehet.
Patroni
Erre utoljára esett a szemem, és mint kiderült, nem hiába. A Patroni egy nyílt forráskódú segédprogram, amely lényegében egy Python démon, amely lehetővé teszi a PostgreSQL-fürtök automatikus karbantartását különféle típusú replikációval és automatikus szerepváltással. A dolog nagyon érdekesnek bizonyult, mivel jól integrálódik a cuberbe, és nem vezet be új entitásokat.
Mit választottál végül?
Nem volt könnyű a választás:
- CsótányDB - tűz, de sötét;
- MySQL Galera - szintén nem rossz, sok helyen használják, de MySQL;
- pgpool — sok szükségtelen entitás, oly-olyan integráció a felhővel és a K8-al;
- Patroni - Kiváló integráció a K8-asokkal, nincs szükségtelen entitás, jól integrálható a GCP LB-vel.
Így a választás Patronira esett.
Álláspontja
Ideje röviden összefoglalni. Igen, az IT infrastruktúra világa jelentősen megváltozott, és ez még csak a kezdet. És ha korábban a felhők csak egy másik típusú infrastruktúra voltak, most minden más. Sőt, a felhőkben folyamatosan jelennek meg újítások, jelennek meg, és talán csak a felhőkben jelennek meg, és csak ezután, a startupok erőfeszítései révén kerülnek át az On-premises-be.
Ami az SQL-t illeti, az SQL élni fog. Ez azt jelenti, hogy ismernie kell a PostgreSQL-t és a MySQL-t, és tudnia kell velük dolgozni, de még ennél is fontosabb, hogy megfelelően tudja használni őket.
Forrás: will.com