Jak vybrat tu správnou cloudovou databázi

V tomto článku se soustředíme na transakční pracovní zátěže běžící v cloudu a cloudové datové sklady necháme na jindy.

Některé databáze jsou k dispozici i pro vlastní infrastrukturu, jiné mají podporu specializovanou na cloud, ale jsou kompatibilní s databázemi ve vlastní infrastruktuře, a jiné jsou „cloudově nativní“, což znamená, že jsou k dispozici jen u poskytovatele cloudu.

Stanovení požadavků na databáze

Databáze není téměř nikdy samostatná záležitost. Databáze je obecně backendová či úložná vrstva pro aplikaci.

CAP teorém (Brewer a kol.) uvádí, že jakýkoli distribuovaný systém dat může mít maximálně dvě ze tří požadovaných vlastností:

• Konzistenci (C – Consistence) – ekvivalent existence jedné aktuální kopie dat
• Dostupnost (A – Availability) těchto dat (pro aktualizace)
• Toleranci pro dočasnou nedostupnost části sítě (P – Partitions tolerance).

Ideální vlastnosti databáze jsou určeny potřebami aplikace, které slouží. Pokud aplikace zobrazuje katalog, potom jsou důležité rychlost čtení a latence databáze, může být ideální dokumentová databáze, ale relační databáze a databáze se širokými sloupci lze použít také.

Pokud aplikace zpracovává finanční transakce, jsou důležité databázové vlastnosti ACID (A-atomicita, C-konzistence, I-izolace a D-odolnost) a ideální může být relační databáze.

Jak bylo vysvětlené v návazném dokumentu v roce 2012, dvě ze tří formulací se ukázaly jako příliš zjednodušující. V moderních distribuovaných databázových architekturách se selhání uzlů a nedostupnost částí sítě řeší pomocí konsensuálních skupin pomocí algoritmů Paxos nebo Raft.

V podstatě jde o to, že když jeden z uzlů clusteru vypadne, pokračuje cluster v práci, dokud má kvorum. Nedostupnost částí sítě bývá navíc vzácná v privátních sítích, které používají hlavní poskytovatelé cloudu, kteří mají redundantní optické spoje mezi datovými centry a nepřenášejí interní komunikaci přes veřejný internet.

To znamená, že zatímco žádná databáze nemůže technicky obejít teorém CAP, v praxi nabízejí nejlepší cloudové databáze lepší než pětidevítkovou (99,999 %) dostupnost. Tyto databáze tedy dokážou obejít teorém CAP v důsledku a mohou být konzistentní i dostupné.

Pokud je aplikací např. celosvětově dostupná videohra pro více hráčů, potom jsou důležitá latence při čtení i při zápisu a databáze pravděpodobně musí být distribuovaná, přestože nemusí nutně být relační a nemusí nutně nabízet silnou konzistenci – ideální by mohla být databáze klíč-hodnota.

Pokud aplikace zaznamenává a sleduje výstupy senzorů ventilů, měla by její databáze dokázat rychle zapisovat velké objemy časových řad.

Kolik dat budete generovat? A jak rychle?

Malá množství dat, měřeno v gigabajtech nebo méně, lze zpracovat téměř v jakékoli cloudové databázi – a některé dokážou tato data udržet v paměti. Mnoho cloudových databází zvládne terabajty (tisíce gigabajtů), ale jen několik dokáže ukládat petabajty (miliony gigabajtů).

Rychlost, s jakou přicházejí data, může zdůraznit další metriky, jako je rychlost zápisu databáze a kapacita sítě.

Pokud dorazí hodně dat najednou, může databáze nebo program rozhraní potřebovat odložit je do paměti RAM, než je zapíše do trvalého úložiště, aby nedošlo ke ztrátě dat. K zachycení objemové špičky záplavy dat pro další databáze se často vyžívá Redis.

Znáte své schéma předem?

Pokud je vaše databázové schéma (struktura dat) předem dáno a je nepravděpodobné, že se časem výrazně změní, a chcete, aby většina polí měla konzistentní typy pro jednotlivé záznamy, mohou být pro vás dobrou variantou databáze SQL. V ostatních případech mohou být pro vaši databázi lepší databáze NoSQL, z nichž některé ani nepodporují schémata.

Existují však výjimky. Například Rockset, provozní databáze, umožňuje dotazy SQL bez použití pevného schématu a konzistentních typů dat při importu.

Jaká podoba se přirozeně hodí pro vaše data?

Relační SQL databáze, jako je Microsoft SQL Server, PostgreSQL nebo MySQL, ukládají silně typovaná data do pravoúhlých tabulek s řádky a sloupci. Využívají definované vztahy mezi tabulkami, používají indexy k urychlení vybraných dotazů a používají syntaxi JOINS pro dotazy vůči více tabulkám najednou. Mnoho moderních relačních databází, včetně Oracle Database, také podporuje i další podoby.

Dokumentové databáze, jako je MongoDB a Couchbase, typicky ukládají slabě typované dokumenty JSON (text nebo binární), které mohou obsahovat pole a vnořené dokumenty.

Grafové databáze buď ukládají vrcholy a hrany s vlastnostmi, například Neo4j, nebo triplestore RDF (Resource Description Framework) – třeba AllegroGraph.

Bez ohledu na implementaci kladou grafové databáze důraz na spojení mezi entitami. Do ostatních kategorií databází NoSQL patří klíč-hodnota (např. RocksDB) a sloupcová úložiště (např. Cassandra).

Někdy jsou data zachycena do podoby, kterou lze použít i pro analýzy, a někdy ne, takže je nutná transformace. Někdy je postaven jeden druh databáze na druhém. Například úložiště klíč-hodnota může být základem téměř jakéhokoli typu databáze.

Jaké jsou vaše požadavky na latenci?

Latence se týká doby odezvy databáze a doby kompletní odezvy aplikace. V ideálním případě bude mít každá akce uživatele dobu odezvy menší než 1 sekunda, což se často interpretuje jako potřeba reakce databáze do 100 milisekund pro každou jednoduchou transakci.

Analytické dotazy mohou často trvat několik sekund či minut. Aplikace se mohou snažit zachovat dobu odezvy spouštěním komplikovaných dotazů na pozadí.

Provoz databáze v cloudu komplikuje měření latence. Působí zde více faktorů. Nejjednodušší úvaha je, že se latence mezi klientem a databází přičítá k latenci vznikající v důsledku odezvy databáze na dotaz.

Komplikovanější úvaha je, že provádění transakcí v distribuované databázi může zahrnovat čekání na zápisy v geograficky distribuovaných regionech, zejména pokud databáze udržuje silnou konzistenci.

Potřebujete clusterovanou databázi?

Clusterované databáze mohou nabídnout ve srovnání s jednouzlovými databázemi několik výhod při vyšších nákladech a složitosti. Kromě dalších výhod mohou clustery vykazovat vyšší dostupnost, vyšší propustnost a v některých případech také nižší latenci.

V případě takového clusteru, kde má každý uzel kopii celé databáze, získáte významnou redundanci a vyšší dostupnost. V závislosti na zásadách může být pro čtení potřebný jeden uzel, nebo kvorum uzlů v clusteru, které bude souhlasit s hodnotou, která má být vrácená.

Použití clusteru s více uzly zvyšuje procesorový výkon dostupný pro databázi, což zvyšuje propustnost a může to zvýšit rychlost transakcí.

Při použití zásad, které umožňují, aby hodnotu zaslal nejbližší uzel, se latence čtení typicky snižuje. Na druhou stranu zásady pro zápis či transakce, které musí počkat na všechny uzly při realizaci, mohou latenci zápisu naopak někdy zvýšit.

Použití konsensuálních skupin pomáhá latenci snížit. Pokud máte tříuzlový cluster a jeden uzel je vyřazen, zbylé dva uzly mohou transakci potvrdit na základě shody a zaktualizovat třetí uzel, až začne být k dispozici.

Sharding (rozdělování) je způsob, jak zpracovat více dat rozdělením databáze. Přestože může být ruční sharding časově náročná dřina, mnoho databází to dokáže provádět automaticky.

Potřebujete distribuovanou databázi?

Clustering není konečným způsobem, jak zvětšovat databáze – je to naopak první krok. Dalším krokem je distribuovaná databáze, což obvykle znamená, že existují clustery ve více regionech.

Některé databáze nabízejí možnost použít distribuované repliky pro čtení a hlavní instanci nebo cluster pro čtení a zápis. Jiné zase umožňují distribuované instance či clustery pro čtení a zápis a mají synchronizační mechanismy.

Distribuované databáze mohou často zajišťovat nižší latenci a vyšší propustnost pro vzdálené uživatele. Například uživatelé v Tokiu mohou vidět 260 milisekundové latence pro server v Barceloně, ale pokud by byla k dispozici lokální kopie databáze v Japonsku, byla by jejich průměrná latence čtení jen 10 milisekund.

Důsledky pro zápisy a transakce závisí na požadavcích konzistence databáze a na způsobu konfigurace vzdálených clusterů.

Původní distribuované databáze byly databáze NoSQL s výslednou konzistencí. Výsledná konzistence znamená, že čtení uskutečněné po zápisu ve vzdálené lokalitě nezaručuje vrácení aktuální informace ihned, ale časem k aktualizaci dojde. Výsledná konzistence uvolňuje požadavky na dokončení zápisů a transakcí, což přináší nižší latenci.

Nedávno několik distribuovaných databází implementovalo silnou konzistenci podporovanou datovými strukturami, konsensuálními skupinami a časem synchronizace. Patří mezi ně např. Google Cloud Spanner a CockroachDB.

Jaký máte rozpočet pro databázi?

Přestože většina databází nabízí komunitní či vývojářskou/testovací verzi zdarma, může vám v takovém případě chybět podpora nad rámec on-line fóra komunity.

Komunitní a open source verze mohou také postrádat některé optimalizace výkonu nabízené v komerčních verzích. Pokud bude vaše společnost záviset na databázi, měli byste spíše investovat do licence a podpory.

Pokud využíváte databázi v cloudu, budete platit minimálně za využívané cloudové prostředky. V případě komerční databáze budete také potřebovat databázovou licenci, která může být buď dlouhodobá od dodavatele, nebo s průběžnou platbou za využívání přes poskytovatele cloudu.

Příklady cloudových databází

Mezi cloudové databáze, které byste měli při výběru zohlednit, patří například CockroachDB, Couchbase Server, DataStax Enterprise, MongoDB Atlas, MySQL, MariaDB, Vitess, PlanetScale, SkySQL (to jsou modifikace MySQL), Neo4j, Oracle Database či Redis.

Ve svých cloudech nabízejí databáze i největší cloudoví provideři jako Amazon Web Services (nejméně 15 variant), Google Cloud (více než 12 databází) IBM (deset databází) nebo Microsoft Azure (osm cloudových transakčních databází).

Také Oracle je v cloudu poměrně aktivní, nabízí v něm celou řadu typů databází či databázových služeb včetně podpory analytiky a data warehousingu, dále správní databázové nástroje či řešení datové integrace.