Nový způsob správy databází s otevřeným zdrojovým kódem

Není to tak dávno, co se databázový průmysl skládal z hrstky prodejců. Databáze byly převážně relační a běžely na jednotlivých strojích. Vysoká dostupnost byla implementována prostřednictvím „klastrů“ v aktivním pohotovostním režimu. U vertikálního modelu „scale-up“ šlo většinou o sdílené úložiště (SAN nebo DRBD) nebo asynchronní replikaci protokolů pro synchronizaci stavu do pohotovostního uzlu. V roce 2001, když jsem začal pracovat s NDB Clusterem (z čehož se později stal MySQL Cluster), byl koncept držení celé databáze v hlavní paměti divný – „co když vypnete server?“. Distribuce databáze na více serverů byla znepokojivá – „tu a tam máte kousky dat“. A celá myšlenka databáze s otevřeným zdrojovým kódem pro kritická pracovní zatížení byla směšná.

Rychle vpřed 15 let a nyní máme na trhu desítky prodejců databází – většinou open source, různé modely (hodnota klíče, dokument, graf, …) a distribuované ve výchozím nastavení. Data rezidentní v paměti jsou v podstatě normou pro dosažení vysokého výkonu a nízké latence. Tři z 5 nejoblíbenějších databází (podle hodnocení db-engines) jsou open source (MySQL, PostgreSQL a MongoDB). V dnešní době je pravděpodobnější, že budete spravovat flotilu databázových serverů distribuovaných v různých datových centrech. Některé ze svých databází můžete dokonce spravovat poskytovatelem cloudu třetí strany.

Jaké to tedy je spravovat databáze v roce 2018?

AUTOMATIZACE

S tolika úkoly, které je třeba spravovat, a pouze tolika hodinami za den by se člověk zbláznil dělat věci ručně.

Automatizace je skvělý způsob, jak věci dělat. Když jsme měli málo databází ke správě, provozování databáze by bylo velmi praktické, přičemž některé úlohy byly napsány v něčem jako bash nebo perl – např. skript pro zálohování databáze, jiný pro přesun záložních souborů na nějaké místo. Přepnutí při selhání by bylo manuální a dokonce bychom diskutovali o tom, zda by mělo být automatické nebo ne.

V dnešní době je automatizace samozřejmostí. Existuje řada systémů pro automatizaci IT nebo správu konfigurace, které lze využít – Puppet, Chef, Ansible a Salt nabízejí univerzální rámce, které lze použít k vytvoření automatizace pro různé topologie databází. Mezi software pro správu clusterů napsaný speciálně pro správu nastavení databáze patří MongoDB Ops Manager a ClusterControl. Umožňují operačním týmům spravovat své clustery pomocí něčeho, co je běžně dostupné. Vybudování systému správy clusteru od nuly pomocí systému správy konfigurace není žádná maličkost. Vyžaduje značnou odbornost v automatizačním nástroji a také porozumění operacím správy, jako je plánování a ověřování zálohování, automatické převzetí služeb při selhání s následnou rekonfigurací systémů, zavádění změn konfigurace, záplatování, upgrade nebo downgrade verze atd.

A samozřejmě existuje vzestup platforem služeb DBaaS, kde je nasazení, stav, převzetí služeb při selhání, zálohování atd. řízeno softwarem. Poskytovatelé cloudu jsou skutečně velmi dobří v automatizaci. Amazon RDS je skvělým příkladem automatizace databází ve velkém měřítku – automatizuje nasazení, aktualizace oprav, zálohování, obnovení v určitém okamžiku, škálování replik a vysokou dostupnost/přepnutí při selhání.

MAZLÍČKA vs. SKOT

V 90. letech a až do boomu a krachu dotcom vydělaly Sun Microsystems a Oracle jmění prodejem škálovatelných databází na velkém hardwaru SMTP. Vložte nějaké úložiště SAN a software pro převzetí služeb při selhání Veritas a získali byste nejmodernější cluster s podporou převzetí služeb při selhání v aktivním pohotovostním režimu pro vysokou dostupnost. Databázových serverů bylo relativně málo, ale výkonné, protože rostly vertikálně. Dostali jména (stejně jako vy pojmenováváte své mazlíčky!) a starali se o ně DBA.

V dnešní době jsou databáze levné a dobře běží na komoditním hardwaru. Je jich spousta a my jim dáváme čísla – stejně jako dobytek. Pokud se jeden rozbije, můžeme si pořídit nový.

Je to také nové plemeno skotu - skot s otevřeným zdrojovým kódem! Tři z pěti nejlepších databází jsou podle db-engines všechny open source – pomalu, ale jistě ukrajují z tržního podílu dvou proprietárních prodejců. Open source je nový standard datových center nejen pro operační systém, ale také pro databáze.

Takže co to pro vás znamená? V budoucnu je pravděpodobnější, že budete spravovat databázi s otevřeným zdrojovým kódem – nebo dokonce více databází pro aplikace využívající heterogenní kolekce dat. Ve světě polyglotní persistence a mikroslužeb je nyní základní úložiště dat diktováno povahou dat. Z architektonického hlediska ustupují databáze s jednou instancí s diskovým HA clusterům, které jsou potenciálně distribuovány napříč více datovými centry.

Potřebujeme DBA?

Role DBA je specializovaná – stát se jí vyžaduje roky zkušeností. V minulosti, kdy bylo na výběr pouze několik proprietárních prodejců databází, jste měli specializované správce databází se specifickou sadou dovedností a zkušeností. Bylo to také vyžadováno – databáze jako Oracle nebo SQL Server mají obrovské sady funkcí, budované po desetiletí. Není snadné je spravovat. Obvykle byly nasazeny jako jediná databáze pro aplikaci a bylo potřeba je monitorovat, zálohovat data a řešit jakékoli problémy, které se objevily. Tyto úkoly byly přesně tím, na co se zde DBA zaměřili.

V posledním desetiletí se však objevil zcela nový databázový průmysl – s desítkami a desítkami databází s otevřeným zdrojovým kódem a také cloudovými databázovými službami. Jak jsme viděli dříve, není neobvyklé, že aplikace používá několik různých datových úložišť. Společnosti však zřídka mají DBA pro tato datová úložiště, která používají. Kde najdete MongoDB nebo Cassandru nebo DBA s více než 5letými zkušenostmi s výrobou? Někdo může namítnout, že nová generace NoSQL databází je mnohem jednodušší než jejich předchůdci s uzavřeným zdrojovým kódem, a proto by nezaznamenala stejnou křivku učení.

Jejich správa by byla jen dalším úkolem přidaným do seznamu úkolů týmu SysAdmin nebo DevOps nebo Site Reliability Engineering (SRE). A dnes vidíme, že mnoho společností nemá DBA na plný úvazek. Odpovědnost je místo toho rozdělena mezi týmy, přičemž automatizační nástroje se stále častěji používají k péči o rutinní každodenní úkoly. U databází, které se přesunuly do cloudu, jsou provozní aspekty ukládání dat zcela outsourcovány poskytovatelem cloudu. Takže místo práce na tom, jak data ukládat, se nyní operační tým může soustředit na využití dat.

Životní cyklus databáze

Průměrný životní cyklus databáze býval mnohem delší než dnes. Jakmile jste si vybrali databázovou platformu, bylo to. Rozhodnutí by bylo učiněno mezi dvěma nebo třemi relačními databázemi, obvykle DBA nebo někým vyšším v organizaci. Společnost by našla peníze na nákup trvalých licencí. Jakmile bylo rozhodnutí přijato, museli jste s ním nyní žít dalších 10+ let. Databáze byly monolitické a aplikace obvykle používaly jedinou sdílenou databázi.

Dnes, ve světě kontejnerů, cloudu, mikroslužeb a kanálů CI/CD, není neobvyklé, že si vývojáři volí technologii – zvláště pokud se jedná o open source databázi, kterou lze snadno stáhnout nebo nabídnout jako službu, aniž byste museli mluvit s obchodním zástupcem nebo museli hledat rozpočet od vedení. Organizace čelí výzvě, aby rychleji tvořily hodnotu, takže tempo změn infrastruktury/aplikací dramaticky vzrostlo. Monolitické databáze jsou nyní rozděleny do několika malých databází, přičemž každá databáze spravuje doménová data pro jednotlivou mikroslužbu. Díky rozmanitosti databázových produktů, které jsou dnes v open source ekosystému k dispozici, mají týmy možnost a svobodu přejít na lepší datové úložiště. Jak jsou služby uváděny do provozu a vyřazovány z provozu, následují také databáze – ačkoli samotná data mohou být archivována nebo přesunuta do datového jezera. V prostředí infrastruktury, které je dnes mnohem dynamičtější, zjišťujeme, že naše databáze žijí kratší dobu.

ROLE DBA

DBA, tradičně jak strážce, tak správce databáze, by obsluhoval databázové potřeby různých aplikačních/infrastrukturních týmů v organizaci. Jakékoli změny vyžadující přístup nebo změny v databázi by vyžadovaly služby DBA. Protichůdné priority a nedostatečná dostupnost DBA by však mohly znamenat, že projekt bude zablokován/zpožděn a bude následovat nevyhnutelné tření.

Vysoké náklady na spolupráci a rychlá inovace/krátká doba uvedení na trh nejdou dobře dohromady. Jak jsme viděli dříve, mikroslužby jsou příkladem toho, jak jsou infrastrukturní a aplikační služby nyní navrženy tak, aby se co nejvíce oddělily. Databáze jsou stále více automatizovány a kontrola nad databází se přesouvá na vývojáře nebo projektové týmy. Dokonce i věci jako změny schémat nejsou tak těžké, jak bývaly. Byly mnohem těžší v kontextu centrální databáze pro monolitické aplikace. Vzhledem k tomu, že data jsou sdílena mezi různými komponentami, změny schématu by musely být koordinovány a pečlivě naplánovány – obvykle měsíce předem. DBA měli klíčovou roli v pochopení a provádění změn. Dynamika je dnes jiná, kde je tempo změn mnohem rychlejší. Není neobvyklé, že vývojové týmy prosazují změny kódu ve výrobě na týdenní nebo denní bázi – nebo dokonce několikrát za den! Databáze potřebují neustálé aktualizace, aby udržely krok se změnami aplikací, a ty provádějí vývojáři. Některé z novějších databází, jako je MongoDB, to dokonce velmi zjednodušují tím, že mají model bez schématu. V podstatě to znamená, že se schéma databáze přesouvá do kódu aplikace.

Takže pokud budou všechny běžné základní úkoly automatizovány, co se stane s rolí DBA v budoucnu? Místo toho, aby se zaměřoval na administrativní úkoly, bude DBA fungovat spíše jako mentor pro ostatní týmy v organizaci. Organizace musí rozumět tomu, jaká data mají a jak je lze využít. Data jsou totiž nejcennější, když jsou sdílena a kombinována s jinými zdroji, nejen uložena. Schemaless zní skvěle, ale stále musíme sledovat svá data – buď v databázi, nebo v kódu. Bezpečnost je výzvou a narušení dat se stále zhoršuje. Máme-li tedy data opět vylepšit, musí se DBA přesunout do role horizontálního poradce/zmocněnce, která se bude týkat napříč týmy. Z hlediska kompetencí musí moderní DBA rozumět tomu, jak navrhovat distribuované systémy s vysokou dostupností, a zavádět účinné automatizační systémy, které se postarají o všední úkoly. Jak společnosti nasazují infrastrukturu napříč cloudovými nebo dokonce kontejnerovými prostředími, pochopení toho, jak na těchto platformách budovat vysoce dostupné a škálovatelné databáze, zajistí přežití DBA.

Shrnutí

Nacházíme se na fascinující křižovatce v historii databázového průmyslu, který za poslední 2 desetiletí prošel masivní transformací. Níže uvedená tabulka se to pokouší shrnout.

Zajímalo by mě, co si myslíte o správě open source databází a zda jste viděli stejné trendy? Jak vypadaly vaše boje nebo úspěchy s OSDB v posledních letech? A co předpokládáte, že se stane příští rok?

My ve společnosti Somenines budeme samozřejmě i nadále usilovat o pomoc při usnadňování správy a automatizace vašich databází s otevřeným zdrojovým kódem do příštího roku a dále. Takže zůstaňte naladěni na aktualizace od příštího ledna.

Ale mezitím mi dejte vědět, co si myslíte, a uvidíme se v roce 2019!

Fotografie od SoRad (Shutterstock) &The Simpsons; ostatní fotografie jsou od jejich příslušných vlastníků.