Dobrý deň, obyvatelia Khabrovska. Vyučovanie v prvej skupine kurzu začína dnes . V tejto súvislosti by sme vám chceli povedať, ako prebiehal otvorený webinár o tomto kurze.
В hovorili sme o výzvach, ktorým čelia databázy SQL v ére cloudov a Kubernetes. Zároveň sme sa pozreli na to, ako sa SQL databázy prispôsobujú a mutujú pod vplyvom týchto výziev.
Uskutočnil sa webinár , Google Cloud Practice Delivery Manager v EPAM Systems.
Keď boli stromy malé...
Najprv si pripomeňme, ako začal výber DBMS na konci minulého storočia. Nebude to však ťažké, pretože výber DBMS v tých dňoch začal a skončil veštec.
Koncom 90. rokov a začiatkom 2. storočia v podstate neexistovala žiadna voľba, pokiaľ ide o priemyselné škálovateľné databázy. Áno, existovali databázy IBM DBXNUMX, Sybase a niektoré ďalšie databázy, ktoré prichádzali a odchádzali, ale vo všeobecnosti neboli na pozadí Oracle také viditeľné. V súlade s tým boli schopnosti inžinierov tých čias nejako spojené s jedinou možnosťou, ktorá existovala.
Oracle DBA musel byť schopný:
- nainštalovať Oracle Server z distribučnej súpravy;
- konfigurácia servera Oracle:
- init.ora;
- poslucháč.ora;
- vytvoriť:
- tabuľkové priestory;
- schémy;
- používateľov;
— vykonať zálohovanie a obnovenie;
— vykonávať monitorovanie;
— zaoberať sa suboptimálnymi požiadavkami.
Zároveň neexistovala žiadna špeciálna požiadavka od Oracle DBA:
- vedieť vybrať optimálnu DBMS alebo inú technológiu na ukladanie a spracovanie údajov;
- poskytovať vysokú dostupnosť a horizontálnu škálovateľnosť (toto nebolo vždy problémom DBA);
- dobrá znalosť predmetu, infraštruktúry, aplikačnej architektúry, OS;
- načítať a vyložiť dáta, migrovať dáta medzi rôznymi DBMS.
Vo všeobecnosti, ak hovoríme o výbere v tých dňoch, pripomína to výber v sovietskom obchode koncom 80-tych rokov:
Náš čas
Odvtedy, samozrejme, stromy vyrástli, svet sa zmenil a stalo sa niečo také:
Zmenil sa aj trh DBMS, ako je jasne vidieť z najnovšej správy od Gartner:
A tu treba poznamenať, že oblaky, ktorých popularita rastie, obsadili svoje miesto. Ak si prečítame rovnakú správu Gartner, uvidíme nasledujúce závery:
- Mnoho zákazníkov je na ceste k presunu aplikácií do cloudu.
- Nové technológie sa prvýkrát objavujú v cloude a nie je pravda, že sa niekedy presunú do necloudovej infraštruktúry.
- Priebežný cenový model sa stal bežným. Každý chce platiť len za to, čo používa, a to ani nie je trend, ale len konštatovanie faktu.
Čo teraz?
Dnes sme všetci v cloude. A otázky, ktoré sa nám vynárajú, sú otázkami voľby. A je obrovský, aj keď hovoríme len o výbere technológií DBMS vo formáte On-premises. Máme tiež riadené služby a SaaS. Preto je výber každým rokom ťažší.
Spolu s otázkami výberu existujú aj limitujúce faktory:
- cena. Mnohé technológie stále stoja peniaze;
- zručností. Ak hovoríme o slobodnom softvéri, potom vyvstáva otázka zručností, keďže slobodný softvér vyžaduje dostatočnú kompetenciu od ľudí, ktorí ho nasadzujú a prevádzkujú;
- funkčné. Nie všetky služby, ktoré sú dostupné v cloude a postavené, povedzme, dokonca aj na rovnakom Postgrese, majú rovnaké funkcie ako Postgres On-premises. Toto je podstatný faktor, ktorý treba poznať a pochopiť. Navyše sa tento faktor stáva dôležitejším ako znalosť niektorých skrytých schopností jedného DBMS.
Čo sa teraz očakáva od DA/DE:
- dobré pochopenie predmetu a aplikačnej architektúry;
- schopnosť správne vybrať vhodnú technológiu DBMS s prihliadnutím na danú úlohu;
- schopnosť vybrať optimálnu metódu implementácie zvolenej technológie v kontexte existujúcich obmedzení;
- schopnosť vykonávať prenos a migráciu údajov;
- schopnosť implementovať a prevádzkovať vybrané riešenia.
Nižšie uvedený príklad na základe GCP ukazuje, ako funguje výber jednej alebo druhej technológie na prácu s údajmi v závislosti od jej štruktúry:
Upozorňujeme, že PostgreSQL nie je zahrnutý v schéme, a to preto, že je skrytý pod terminológiou CloudSQL. A keď sa dostaneme ku cloudovému SQL, musíme sa znova rozhodnúť:
Je potrebné poznamenať, že táto voľba nie je vždy jasná, takže vývojári aplikácií sa často riadia intuíciou.
Celkom:
- Čím ďalej, tým naliehavejšia je otázka výberu. A aj keď sa pozriete iba na GCP, spravované služby a SaaS, potom sa zmienka o RDBMS objaví až v 4. kroku (a tam je Spanner). Navyše sa v 5. kroku objaví výber PostgreSQL a vedľa neho sú aj MySQL a SQL Server, tzn. všetkého je veľa, ale treba si vybrať.
- Nesmieme zabudnúť na obmedzenia na pozadí pokušení. Spanner chce v podstate každý, ale je drahý. Výsledkom je, že typická požiadavka vyzerá asi takto: "Urobte z nás Spanner, ale za cenu Cloud SQL ste profesionáli!"
Čo by sme mali urobiť?
Bez toho, aby sme tvrdili, že je to konečná pravda, povedzme nasledovné:
Musíme zmeniť náš prístup k učeniu:
- nemá zmysel učiť tak, ako sa DBA vyučovali predtým;
- znalosť jedného produktu už nestačí;
- ale poznať desiatky na úrovni jedného je nemožné.
Musíte vedieť nielen a nie koľko je produkt, ale:
- prípad použitia jeho aplikácie;
- rôzne spôsoby nasadenia;
- výhody a nevýhody každej metódy;
- podobné a alternatívne produkty, aby ste urobili informovaný a optimálny výber a nie vždy v prospech známeho produktu.
Musíte byť tiež schopní migrovať údaje a pochopiť základné princípy integrácie s ETL.
Skutočný prípad
V nedávnej minulosti bolo potrebné vytvoriť backend pre mobilnú aplikáciu. V čase, keď sa na ňom začalo pracovať, bol backend už vyvinutý a pripravený na implementáciu a vývojový tím strávil na tomto projekte približne dva roky. Boli stanovené tieto úlohy:
- zostaviť CI/CD;
- preskúmať architektúru;
- uviesť to všetko do prevádzky.
Samotná aplikácia bola mikroslužbami a kód Python/Django bol vyvinutý od nuly a priamo v GCP. Čo sa týka cieľového publika, predpokladalo sa, že budú dva regióny – USA a EÚ a návštevnosť bola distribuovaná cez Global Load balancer. Všetky pracovné a výpočtové úlohy bežali na Google Kubernetes Engine.
Pokiaľ ide o údaje, existovali 3 štruktúry:
- Cloud-ové úložisko;
- Uloženie údajov;
- Cloud SQL (PostgreSQL).
Niekto by sa mohol čudovať, prečo bol vybraný Cloud SQL? Pravdupovediac, takáto otázka spôsobila v posledných rokoch akúsi trápnu pauzu – existuje pocit, že ľudia sa začali hanbiť za relačné databázy, no napriek tomu ich naďalej aktívne využívajú ;-).
Pokiaľ ide o náš prípad, Cloud SQL bol vybraný z nasledujúcich dôvodov:
- Ako už bolo spomenuté, aplikácia bola vyvinutá pomocou Django a má model na mapovanie perzistentných údajov z databázy SQL na objekty Python (Django ORM).
- Samotný rámec podporoval pomerne obmedzený zoznam DBMS:
- PostgreSQL;
- MariaDB;
- MySQL;
- orakuly;
- SQLite.
V súlade s tým bol PostgreSQL vybraný z tohto zoznamu skôr intuitívne (no, nie je to Oracle, aby si vybral, naozaj).
Čo chýbalo:
- aplikácia bola nasadená len v 2 regiónoch a 3. sa objavil v plánoch (Ázia);
- Databáza bola umiestnená v regióne Severnej Ameriky (Iowa);
- zo strany zákazníka boli obavy z možného prístupové oneskorenia z Európy a Ázie a prerušenia v prevádzke v prípade výpadku DBMS.
Napriek tomu, že samotné Django dokáže pracovať s viacerými databázami paralelne a rozdeliť ich na čítanie a zápis, v aplikácii sa až tak veľa nepísalo (viac ako 90 % tvorí čítanie). A vo všeobecnosti a vo všeobecnosti, ak to bolo možné čítaná replika hlavnej základne v Európe a Ázii, bolo by to kompromisné riešenie. No a čo je na tom zložité?
Problém bol v tom, že zákazník sa nechcel vzdať používania riadených služieb a Cloud SQL. A možnosti Cloud SQL sú v súčasnosti obmedzené. Cloud SQL podporuje vysokú dostupnosť (HA) a čítaciu repliku (RR), ale rovnaké RR je podporované iba v jednej oblasti. Po vytvorení databázy v americkom regióne nemôžete vytvoriť repliku na čítanie v európskom regióne pomocou Cloud SQL, hoci samotný Postgres vám v tom nebráni. Korešpondencia so zamestnancami Google nikam neviedla a skončila sľubmi v štýle „známe problém a pracujeme na ňom, raz sa problém vyrieši“.
Ak stručne vymenujeme možnosti Cloud SQL, bude to vyzerať asi takto:
1. Vysoká dostupnosť (HA):
- v rámci jedného regiónu;
- prostredníctvom replikácie disku;
- PostgreSQL motory sa nepoužívajú;
- možnosť automatického a manuálneho ovládania - failover/failback;
- Pri prepnutí je DBMS niekoľko minút nedostupný.
2. Prečítajte si repliku (RR):
- v rámci jedného regiónu;
- horúci pohotovostný režim;
- PostgreSQL streamingová replikácia.
Navyše, ako to už býva zvykom, pri výbere technológie vás vždy čaká nejaká obmedzenia:
- zákazník nechcel vytvárať entity a používať IaaS, s výnimkou GKE;
- zákazník by nechcel nasadiť samoobslužný PostgreSQL/MySQL;
- Všeobecne platí, že Google Spanner by bol celkom vhodný, keby to nebolo pre jeho cenu, ale Django ORM s ním nemôže pracovať, ale je to dobrá vec.
Vzhľadom na situáciu dostal zákazník doplňujúcu otázku: "Môžete urobiť niečo podobné, aby to bolo ako Google Spanner, ale fungovalo to aj s Django ORM?"
Možnosť riešenia č.0
Prvá vec, ktorá ma napadla:
- zostať v CloudSQL;
- medzi regiónmi nebude v žiadnej forme zabudovaná replikácia;
- pokúsiť sa pripojiť repliku k existujúcemu cloud SQL prostredníctvom PostgreSQL;
- niekde a nejako spustite inštanciu PostgreSQL, ale aspoň sa nedotýkajte mastera.
Bohužiaľ, ukázalo sa, že to nie je možné, pretože neexistuje žiadny prístup k hostiteľovi (je úplne v inom projekte) - pg_hba atď., A tiež nie je prístup pod superuserom.
Možnosť riešenia č.1
Po ďalšej úvahe a zohľadnení predchádzajúcich okolností sa myšlienkový pochod trochu zmenil:
- Stále sa snažíme zostať v rámci CloudSQL, ale prechádzame na MySQL, pretože Cloud SQL by MySQL má externého hlavného servera, ktorý:
— je proxy pre externé MySQL;
- vyzerá ako inštancia MySQL;
- vynájdený na migráciu údajov z iných cloudov alebo miestnych zariadení.
Keďže nastavenie replikácie MySQL nevyžaduje prístup k hostiteľovi, v princípe všetko fungovalo, ale bolo to veľmi nestabilné a nepohodlné. A keď sme išli ďalej, stalo sa to úplne strašidelné, pretože sme nasadili celú štruktúru s terraformom a zrazu sa ukázalo, že externý majster nie je podporovaný terraformom. Áno, Google má CLI, ale z nejakého dôvodu tu všetko občas fungovalo - niekedy je vytvorené, niekedy nie je vytvorené. Možno preto, že CLI bolo vynájdené na externú migráciu dát a nie na repliky.
V skutočnosti sa v tomto bode ukázalo, že Cloud SQL nie je vôbec vhodný. Ako sa hovorí, urobili sme všetko, čo sme mohli.
Možnosť riešenia č.2
Keďže nebolo možné zostať v rámci Cloud SQL frameworku, pokúsili sme sa sformulovať požiadavky na kompromisné riešenie. Ukázalo sa, že požiadavky boli nasledovné:
- práca v Kubernetes, maximálne využitie zdrojov a možností Kubernetes (DCS, ...) a GCP (LB, ...);
- nedostatok balastu z kopy nepotrebných vecí v cloude ako HA proxy;
- schopnosť spúšťať PostgreSQL alebo MySQL v hlavnom HA regióne; v iných regiónoch - HA z RR hlavného regiónu plus jeho kópia (kvôli spoľahlivosti);
- multi master (nechcel som ho kontaktovať, ale nebolo to veľmi dôležité)
.
V dôsledku týchto požiadaviek pvhodné DBMS a možnosti viazania:
- MySQL Galera;
- švábDB;
- PostgreSQL nástroje
:
- pgpool-II;
— Patroni.
MySQL Galera
Technológia MySQL Galera bola vyvinutá spoločnosťou Codership a je doplnkom pre InnoDB. Zvláštnosti:
- multi master;
- synchrónna replikácia;
- čítanie z ľubovoľného uzla;
- nahrávanie do akéhokoľvek uzla;
- vstavaný mechanizmus HA;
- Existuje graf Helm od Bitnami.
ŠvábDB
Podľa popisu je vec úplne bombová a ide o open source projekt napísaný v Go. Hlavným účastníkom je Cockroach Labs (založené ľuďmi z Google). Tento relačný DBMS bol pôvodne navrhnutý tak, aby bol distribuovaný (s horizontálnym škálovaním hneď po vybalení) a odolný voči chybám. Jeho autori zo spoločnosti načrtli cieľ „spojiť bohatosť funkcií SQL s horizontálnou dostupnosťou známou riešeniam NoSQL“.
Príjemným bonusom je podpora protokolu post-gress pripojenia.
pgpool
Toto je doplnok k PostgreSQL, v skutočnosti nová entita, ktorá preberá všetky pripojenia a spracováva ich. Má vlastný nástroj na vyvažovanie zaťaženia a syntaktický analyzátor, licencovaný pod licenciou BSD. Poskytuje dostatok príležitostí, ale vyzerá trochu strašidelne, pretože prítomnosť novej entity by sa mohla stať zdrojom niektorých ďalších dobrodružstiev.
Patroni
Toto je posledná vec, na ktorú mi padol zrak, a ako sa ukázalo, nie nadarmo. Patroni je nástroj s otvoreným zdrojovým kódom, ktorý je v podstate démonom Pythonu, ktorý vám umožňuje automaticky udržiavať klastre PostgreSQL s rôznymi typmi replikácie a automatickým prepínaním rolí. Táto vec sa ukázala ako veľmi zaujímavá, pretože sa dobre integruje s kockou a nezavádza žiadne nové entity.
Čo ste si nakoniec vybrali?
Výber nebol jednoduchý:
- ŠvábDB - oheň, ale temný;
- MySQL Galera - tiež to nie je zlé, používa sa na mnohých miestach, ale MySQL;
- pgpool — veľa nepotrebných entít, taká integrácia s cloudom a K8;
- Patroni - výborná integrácia s K8, žiadne zbytočné entity, dobre sa integruje s GCP LB.
Voľba teda padla na Patroniho.
Závery
Je čas to stručne zhrnúť. Áno, svet IT infraštruktúry sa výrazne zmenil a toto je len začiatok. A ak predtým boli mraky len iným typom infraštruktúry, teraz je všetko inak. Inovácie v cloude sa navyše neustále objavujú, budú objavovať a možno sa objavia iba v cloude a až potom sa úsilím startupov prenesú do On-premises.
Pokiaľ ide o SQL, SQL bude žiť. To znamená, že musíte poznať PostgreSQL a MySQL a vedieť s nimi pracovať, no ešte dôležitejšie je vedieť ich správne používať.
Zdroj: hab.com