Dobrý den, obyvatelé Chabrovska. Dnes začíná výuka v první skupině kurzu . V této souvislosti bychom vám rádi přiblížili, jak probíhal otevřený webinář k tomuto kurzu.
В mluvili jsme o výzvách, kterým čelí databáze SQL v éře cloudů a Kubernetes. Zároveň jsme se podívali na to, jak se SQL databáze přizpůsobují a mutují pod vlivem těchto výzev.
Webinář se konal , Google Cloud Practice Delivery Manager ve společnosti EPAM Systems.
Když byly stromy malé...
Nejprve si připomeňme, jak začal výběr DBMS na konci minulého století. To však nebude těžké, protože výběr DBMS v té době začínal a končil Věštec.
Koncem 90. let a začátkem 2. století v podstatě neexistovala žádná volba, pokud jde o průmyslové škálovatelné databáze. Ano, existovaly databáze IBM DBXNUMX, Sybase a některé další databáze, které přicházely a odcházely, ale obecně nebyly na pozadí Oracle tak nápadné. V souladu s tím byly schopnosti inženýrů té doby nějak svázány s jedinou možností, která existovala.
Oracle DBA musel být schopen:
- nainstalovat Oracle Server z distribuční sady;
- konfigurace serveru Oracle:
- init.ora;
- posluchač.ora;
- vytvořit:
- tabulkové prostory;
- systémy;
- uživatelé;
— provádět zálohování a obnovení;
— provádět monitorování;
— zabývat se neoptimálními požadavky.
Současně neexistoval žádný zvláštní požadavek ze strany Oracle DBA:
- umět zvolit optimální DBMS nebo jinou technologii pro ukládání a zpracování dat;
- poskytovat vysokou dostupnost a horizontální škálovatelnost (ne vždy to byl problém DBA);
- dobrá znalost oboru, infrastruktury, aplikační architektury, OS;
- načítání a vyjímání dat, migrace dat mezi různými DBMS.
Obecně, pokud mluvíme o výběru v té době, připomíná výběr v sovětském obchodě na konci 80.
Náš čas
Od té doby samozřejmě stromy vyrostly, svět se změnil a stalo se něco takového:
Trh DBMS se také změnil, jak je jasně vidět z poslední zprávy od Gartner:
A zde je třeba poznamenat, že mraky, jejichž popularita roste, obsadily své místo. Pokud si přečteme stejnou zprávu Gartner, uvidíme následující závěry:
- Mnoho zákazníků je na cestě k přesunu aplikací do cloudu.
- Nové technologie se poprvé objevují v cloudu a není skutečností, že se někdy přesunou do necloudové infrastruktury.
- Průběžný cenový model se stal běžným. Každý chce platit jen za to, co používá, a to ani není trend, ale prostě konstatování faktu.
Co teď?
Dnes jsme všichni v cloudu. A otázky, které nám vyvstávají, jsou otázkami volby. A ta je obrovská, i když se bavíme pouze o výběru technologií DBMS ve formátu On-premises. Máme také řízené služby a SaaS. Výběr je tak rok od roku obtížnější.
Spolu s otázkami volby existují také limitující faktory:
- cena. Mnoho technologií stále stojí peníze;
- dovednosti. Pokud mluvíme o svobodném softwaru, pak vyvstává otázka dovedností, protože svobodný software vyžaduje dostatečné kompetence od lidí, kteří jej nasazují a provozují;
- funkční. Ne všechny služby, které jsou dostupné v cloudu a postavené, řekněme, dokonce na stejném Postgresu, mají stejné funkce jako Postgres On-premises. To je zásadní faktor, který je třeba znát a pochopit. Navíc se tento faktor stává důležitějším než znalost některých skrytých schopností jednoho DBMS.
Co se nyní očekává od DA/DE:
- dobrá znalost předmětu a aplikační architektury;
- schopnost správně vybrat vhodnou technologii DBMS s ohledem na daný úkol;
- schopnost vybrat optimální metodu implementace zvolené technologie v kontextu existujících omezení;
- schopnost provádět přenos a migraci dat;
- schopnost implementovat a provozovat vybraná řešení.
Níže uvedený příklad založené na GCP ukazuje, jak funguje výběr té či oné technologie pro práci s daty v závislosti na jejich struktuře:
Vezměte prosím na vědomí, že PostgreSQL není součástí schématu, a to proto, že je skrytý pod terminologií CloudSQL. A když se dostaneme ke Cloud SQL, musíme si znovu vybrat:
Je třeba poznamenat, že tato volba není vždy jasná, takže vývojáři aplikací se často řídí intuicí.
Celkem:
- Čím dále, tím naléhavější je otázka volby. A i když se podíváte pouze na GCP, spravované služby a SaaS, pak se nějaká zmínka o RDBMS objeví až ve 4. kroku (a tam je Spanner poblíž). Navíc se v 5. kroku objeví výběr PostgreSQL a vedle něj jsou také MySQL a SQL Server, tzn. všeho je hodně, ale musíte si vybrat.
- Nesmíme zapomínat na omezení na pozadí pokušení. Spanner chce v podstatě každý, ale je drahý. Výsledkem je, že typický požadavek vypadá asi takto: "Udělejte nám prosím Spanner, ale za cenu Cloud SQL jste profesionálové!"
Ale co dělat?
Aniž bychom tvrdili, že je to konečná pravda, řekněme následující:
Musíme změnit náš přístup k učení:
- nemá smysl učit tak, jak se dříve vyučovali DBA;
- znalost jednoho produktu již nestačí;
- ale znát desítky na úrovni jedné je nemožné.
Musíte vědět nejen a ne kolik produkt stojí, ale:
- případ použití jeho aplikace;
- různé způsoby nasazení;
- výhody a nevýhody jednotlivých metod;
- podobné a alternativní produkty, aby bylo možné učinit informovanou a optimální volbu a ne vždy ve prospěch známého produktu.
Musíte také umět migrovat data a rozumět základním principům integrace s ETL.
skutečný případ
V nedávné minulosti bylo nutné vytvořit backend pro mobilní aplikaci. V době, kdy se na něm začalo pracovat, byl backend již vyvinutý a připravený k implementaci a vývojový tým strávil na tomto projektu zhruba dva roky. Byly stanoveny tyto úkoly:
- sestavení CI/CD;
- přezkoumat architekturu;
- vše uvést do provozu.
Samotná aplikace byla mikroslužba a kód Python/Django byl vyvinut od nuly a přímo v GCP. Co se týče cílové skupiny, předpokládalo se, že budou dva regiony – USA a EU a provoz byl distribuován přes Global Load balancer. Všechny pracovní a výpočetní úlohy běžely na Google Kubernetes Engine.
Pokud jde o data, byly to 3 struktury:
- Cloudové úložiště;
- Úložiště dat;
- Cloud SQL (PostgreSQL).
Někdo by se mohl divit, proč byl vybrán Cloud SQL? Abych řekl pravdu, taková otázka způsobila v posledních letech jakousi nepěknou pauzu - existuje pocit, že se lidé za relační databáze stydí, ale přesto je nadále aktivně využívají ;-).
V našem případě byl Cloud SQL vybrán z následujících důvodů:
- Jak již bylo zmíněno, aplikace byla vyvinuta pomocí Django a má model pro mapování perzistentních dat z SQL databáze na objekty Pythonu (Django ORM).
- Samotný rámec podporoval poměrně konečný seznam DBMS:
- PostgreSQL;
- MariaDB;
- MySQL
- Věštec;
- SQLite.
V souladu s tím byl PostgreSQL vybrán z tohoto seznamu spíše intuitivně (no, není to Oracle, aby si vybral, opravdu).
Co chybělo:
- aplikace byla nasazena pouze ve 2 regionech a 3. se objevil v plánech (Asie);
- Databáze byla umístěna v regionu Severní Ameriky (Iowa);
- ze strany zákazníka byly obavy z možného přístupová zpoždění z Evropy a Asie a přerušení ve službě v případě výpadku DBMS.
I přesto, že samotné Django umí pracovat s více databázemi paralelně a rozdělit je na čtení a zápis, v aplikaci se tolik nepsalo (více než 90 % je čtení). A obecně a obecně, pokud to bylo možné udělat čtená replika hlavní základny v Evropě a Asii, bylo by to kompromisní řešení. No, co je na tom tak složitého?
Potíž byla v tom, že se zákazník nechtěl vzdát používání řízených služeb a Cloud SQL. A možnosti Cloud SQL jsou v současnosti omezené. Cloud SQL podporuje vysokou dostupnost (HA) a Read Replica (RR), ale stejné RR je podporováno pouze v jedné oblasti. Po vytvoření databáze v americkém regionu nemůžete vytvořit repliku pro čtení v evropském regionu pomocí Cloud SQL, ačkoli samotný Postgres vám v tom nebrání. Korespondence se zaměstnanci Googlu nikam nevedla a skončila sliby ve stylu „známe problém a pracujeme na něm, jednou bude problém vyřešen“.
Pokud stručně vyjmenujeme možnosti Cloud SQL, bude to vypadat asi takto:
1. Vysoká dostupnost (HA):
- v rámci jednoho regionu;
- prostřednictvím replikace disku;
- PostgreSQL motory se nepoužívají;
- možné automatické i ruční ovládání - failover/failback;
- Při přepnutí je DBMS několik minut nedostupný.
2. Přečtěte si repliku (RR):
- v rámci jednoho regionu;
- horký pohotovostní režim;
- PostgreSQL streamovací replikace.
Navíc, jak už to bývá zvykem, při výběru technologie se vždy potýkáte s nějakou omezení:
- zákazník nechtěl vytvářet entity a používat IaaS, s výjimkou GKE;
- zákazník by nechtěl nasadit samoobslužný PostgreSQL/MySQL;
- Obecně platí, že Google Spanner by byl docela vhodný, nebýt jeho ceny, nicméně Django ORM s ním neumí pracovat, ale je to dobrá věc.
Vzhledem k situaci dostal zákazník doplňující otázku: "Můžete udělat něco podobného, aby to bylo jako Google Spanner, ale fungovalo to také s Django ORM?"
Možnost řešení č. 0
První, co mě napadlo:
- zůstat v CloudSQL;
- mezi regiony nebude žádná vestavěná replikace v jakékoli formě;
- pokuste se připojit repliku k existujícímu Cloud SQL prostřednictvím PostgreSQL;
- spusťte někde a nějak instanci PostgreSQL, ale alespoň se nedotýkejte master.
Bohužel se ukázalo, že to nelze udělat, protože neexistuje žádný přístup k hostiteli (je to úplně v jiném projektu) - pg_hba a tak dále, a také neexistuje přístup pod superuživatelem.
Možnost řešení č. 1
Po další reflexi a s přihlédnutím k předchozím okolnostem se tok myšlenek poněkud změnil:
- Stále se snažíme zůstat v CloudSQL, ale přecházíme na MySQL, protože Cloud SQL by MySQL má externí master, který:
— je proxy pro externí MySQL;
- vypadá jako instance MySQL;
- Vynalezeno pro migraci dat z jiných cloudů nebo On-premises.
Vzhledem k tomu, že nastavení replikace MySQL nevyžaduje přístup k hostiteli, v zásadě vše fungovalo, ale bylo to velmi nestabilní a nepohodlné. A když jsme šli dál, začalo to být úplně děsivé, protože jsme nasadili celou konstrukci s terraformem a najednou se ukázalo, že externí master nebyl terraformem podporován. Ano, Google má CLI, ale z nějakého důvodu tu vše občas fungovalo – někdy je vytvořeno, někdy není vytvořeno. Možná proto, že rozhraní CLI bylo vynalezeno pro externí migraci dat a ne pro repliky.
Ve skutečnosti se v tuto chvíli ukázalo, že Cloud SQL není vůbec vhodný. Jak se říká, dělali jsme, co jsme mohli.
Možnost řešení č. 2
Protože nebylo možné zůstat v rámci Cloud SQL frameworku, pokusili jsme se formulovat požadavky na kompromisní řešení. Ukázalo se, že požadavky byly následující:
- práce v Kubernetes, maximální využití zdrojů a možností Kubernetes (DCS, ...) a GCP (LB, ...);
- nedostatek balastu z hromady nepotřebných věcí v cloudu, jako je HA proxy;
- schopnost spouštět PostgreSQL nebo MySQL v hlavní oblasti HA; v ostatních regionech - HA z RR hlavního regionu plus jeho kopie (pro spolehlivost);
- multi master (nechtěl jsem ho kontaktovat, ale nebylo to moc důležité)
.
V důsledku těchto požadavků pvhodné DBMS a možnosti vazby:
- MySQL Galera;
- ŠvábDB;
- Nástroje PostgreSQL
:
- pgpool-II;
— Patroni.
MySQL Galera
Technologie MySQL Galera byla vyvinuta společností Codership a jde o plugin pro InnoDB. Zvláštnosti:
- multi master;
- synchronní replikace;
- čtení z libovolného uzlu;
- nahrávání do libovolného uzlu;
- vestavěný HA mechanismus;
- Existuje graf Helm od Bitnami.
Šváb
Věc je podle popisu naprosto bombová a jde o open source projekt napsaný v Go. Hlavním účastníkem je Cockroach Labs (založené lidmi z Googlu). Tento relační DBMS byl původně navržen tak, aby byl distribuovaný (s horizontálním škálováním hned po vybalení) a odolný proti chybám. Jeho autoři ze společnosti nastínili cíl „kombinovat bohatost funkcí SQL s horizontální dostupností známou řešení NoSQL“.
Příjemným bonusem je podpora protokolu post-gress připojení.
Pgpool
Jedná se o doplněk PostgreSQL, vlastně o novou entitu, která přebírá všechna připojení a zpracovává je. Má svůj vlastní load balancer a parser, licencovaný pod licencí BSD. Poskytuje dostatek příležitostí, ale vypadá poněkud děsivě, protože přítomnost nové entity by se mohla stát zdrojem některých dalších dobrodružství.
Patroni
To je to poslední, na co mi padl zrak, a jak se ukázalo, ne nadarmo. Patroni je nástroj s otevřeným zdrojovým kódem, což je v podstatě démon Python, který vám umožňuje automaticky udržovat clustery PostgreSQL s různými typy replikace a automatickým přepínáním rolí. Tato věc se ukázala jako velmi zajímavá, protože se dobře integruje s krychlí a nezavádí žádné nové entity.
Co jste si nakonec vybrali?
Volba nebyla jednoduchá:
- Šváb - oheň, ale temný;
- MySQL Galera - také to není špatné, používá se na mnoha místech, ale MySQL;
- Pgpool — spousta zbytečných entit, taková integrace s cloudem a K8;
- Patroni - výborná integrace s K8s, žádné zbytečné entity, dobře se integruje s GCP LB.
Volba tedy padla na Patroniho.
Závěry
Je čas to stručně shrnout. Ano, svět IT infrastruktury se výrazně změnil, a to je jen začátek. A pokud dříve byly mraky jen jiným typem infrastruktury, nyní je všechno jinak. Inovace v cloudu se navíc neustále objevují, budou objevovat a možná se budou objevovat pouze v cloudech a teprve poté se snahou startupů přenést do On-premises.
Pokud jde o SQL, SQL bude žít. To znamená, že musíte znát PostgreSQL a MySQL a umět s nimi pracovat, ale ještě důležitější je umět je správně používat.
Zdroj: www.habr.com