Abstrakt: Před dvaceti lety se výběr databáze omezoval na volbu mezi několika relačními systémy. Dnešní podniky stojí před desítkami specializovaných technologií, z nichž každá je optimalizovaná pro odlišné využití. Tento článek shrnuje praktická kritéria pro výběr databáze podle typu dat, přístupových vzorů, požadavků na škálování a konzistenci. Zaměřuje se na rozdíly mezi relačními databázemi, dokumentovými, klíč-hodnotovými a sloupcovými úložišti i na novou generaci distribuovaných SQL systémů. Důraz je kladen na pragmatický přístup, který upřednostňuje obchodní požadavky před technologickými trendy.
1. Od jediného systému k polyglot persistence
V minulosti byly relační databáze nasazovány na všechny typy úloh: transakční zpracování, reporty, vyrovnávací paměť, fronty, dokonce i ukládání binárních souborů. Licenční náklady byly vysoké, výkon často nedostatečný, zato volba byla bezpečná.
Současné podnikové architektury kombinují více specializovaných úložišť. Typická konfigurace zahrnuje relační databázi pro transakce, vyrovnávací paměť pro rychlý přístup k datům, fulltextový vyhledávač, analytické úložiště pro reporty, objektové úložiště pro soubory a streamovací platformu pro asynchronní zpracování. Tento přístup, označovaný jako polyglot persistence, není technologickým excesem, ale pragmatickou volbou. Použití správného nástroje pro konkrétní úlohu zvyšuje výkon a snižuje provozní náklady.
Vývoj databázového myšlení
Mezi roky 1980 a 2000 dominovaly relační systémy. Normalizace dat a uložené procedury byly považovány za samozřejmost. Po roce 2000 narazily velké webové firmy na hranice tradičních databází a do popředí vstoupil teorém CAP. Mezi roky 2010 a 2020 následovala vlna NoSQL systémů, často přijímaných bez ohledu na skutečné potřeby. Po roce 2020 nastupuje pragmatická syntéza: SQL se vrací v podobě distribuovaných systémů (NewSQL), NoSQL technologie dospěly a volba se opět řídí požadavky aplikace.
2. Relační databáze jako základ transakčních systémů
PostgreSQL
PostgreSQL představuje univerzální volbu pro většinu podnikových aplikací. Podpora datového typu JSONB umožňuje kombinovat relační a dokumentový přístup. Systém nabízí rozsáhlou sadu rozšíření, mezi nimi PostGIS pro geoprostorová data nebo TimescaleDB pro časové řady. Optimalizátor dotazů patří k nejvyspělejším a celý systém je dostupný pod open-source licencí.
MySQL
MySQL zůstává silnou volbou pro jednoduché aplikace s převahou čtení a pro ekosystémy CMS. Replikace je ověřená v produkci, optimalizátor dotazů ovšem zaostává u složitějších spojení tabulek. Vlastnické vazby na Oracle vedou některé organizace k preferenci alternativ.
Komerční systémy
Oracle Database a Microsoft SQL Server zůstávají relevantní v prostředích s legacy aplikacemi, specifickými enterprise funkcemi (Oracle RAC, SSIS) a tam, kde je dodavatelská podpora kritická. Náklady na licence a provoz jsou ovšem výrazně vyšší než u open-source alternativ.
3. NoSQL: Když relační model nestačí
Dokumentová úložiště
MongoDB nabízí flexibilní schéma a od verze 4.0 podporu transakcí. Pro aplikace vyžadující současně flexibilitu schématu i ACID vlastnosti je často vhodnější PostgreSQL s JSONB. Amazon DocumentDB poskytuje kompatibilní rozhraní v rámci ekosystému AWS.
Klíč-hodnotová úložiště
Redis se uplatňuje jako vyrovnávací paměť, úložiště relací, real-time žebříčků a jako prostředek pro publikování zpráv mezi službami. DynamoDB je výchozí volbou pro aplikace na AWS s požadavkem na nízkou latenci a automatické škálování.
Sloupcové databáze
Apache Cassandra vyniká u úloh s vysokou intenzitou zápisů, mezi které patří sběr telemetrie, logování a IoT scénáře. Disponuje lineárním škálováním a podporou replikace mezi datovými centry. HBase má smysl tam, kde už je nasazený ekosystém Hadoop.
Grafové databáze
Neo4j a podobné systémy řeší úlohy se silným důrazem na vztahy: sociální sítě, doporučovací systémy a detekci podvodů. Dotazy, které by v relačním modelu vyžadovaly rekurzivní spojení, se v grafové databázi vyjadřují přirozeně a běží řádově rychleji.
4. NewSQL a distribuované relační systémy
CockroachDB poskytuje protokol kompatibilní s PostgreSQL, automatickou distribuci dat a odolnost vůči výpadku celého datového centra. Hodí se pro globální nasazení s požadavkem na silnou konzistenci. Google Spanner cílí na aplikace planetárního měřítka, kde je akceptovatelný vendor lock-in na Google Cloud. TiDB nabízí kompatibilitu s MySQL, horizontální škálování a podporu smíšených OLTP a OLAP úloh.
5. Teorém CAP v praxi
Distribuovaný systém může současně garantovat pouze dvě ze tří vlastností: konzistenci, dostupnost a odolnost vůči výpadku sítě. Bankovní transakční systémy upřednostňují konzistenci. Sociální sítě tolerují krátkodobé nepřesnosti a kladou důraz na dostupnost. E-commerce platformy často kombinují oba přístupy: nákupní košík preferuje dostupnost, zatímco platba a uzavření objednávky vyžadují silnou konzistenci.
6. Rámec pro výběr databáze
Při volbě databáze je vhodné zodpovědět čtyři otázky. Jakou má povaha dat strukturu a vztahy? Jaké jsou typické přístupové vzory aplikace? Jaký objem dat a transakční zátěž lze očekávat v horizontu let? Jaké jsou požadavky na konzistenci?
| Typ úlohy | První volba | Alternativa | |-----------|-------------|-------------| | Webová aplikace | PostgreSQL | MySQL | | Analytika v reálném čase | ClickHouse | Apache Druid | | Vyrovnávací paměť | Redis | Memcached | | Fulltextové vyhledávání | Elasticsearch | Apache Solr | | Grafová data | Neo4j | Amazon Neptune | | Časové řady | TimescaleDB | InfluxDB | | Streamování zpráv | Apache Kafka | AWS Kinesis |
7. Časté chyby v rozhodování
První chybou je univerzální nasazení jediné technologie pro všechny úlohy bez ohledu na vhodnost. Druhou je ignorování teorému CAP a očekávání garancí, které distribuované systémy fyzikálně nemohou poskytnout. Třetí chybou je předčasná optimalizace v podobě nasazení komplexních distribuovaných systémů pro malou zátěž. Čtvrtou je závislost na proprietárních funkcích cloudu bez zohlednění budoucí migrace.
8. Migrace mezi databázemi
Osvědčenou strategií je dvojí zápis. Aplikace zapisuje do staré i nové databáze, historická data jsou doplněna postupně, konzistence je verifikována a čtecí provoz se přepíná po etapách. Alternativní přístup vychází z event sourcingu, kdy jsou změny zachycovány jako události a přehrávány do nového úložiště. Mezi užitečné nástroje patří AWS Database Migration Service, Debezium pro change data capture a Apache NiFi pro tvorbu datových toků.
9. Celkové náklady
Licenční poplatky tvoří jen část celkových nákladů. Patří k nim rovněž provozní režie, mzdové náklady na specialisty, zálohování, monitoring a investice do migrace. Cloudové spravované služby snižují provozní zátěž, ale zvyšují jednotkové náklady a vytvářejí závislost na dodavateli. Vyplatí se zejména u proměnlivé zátěže, při nedostatku interních DBA kapacit a u projektů s krátkým časem na uvedení.
10. Trendy
Mezi výrazné trendy patří bezserverové databáze s platbou podle počtu dotazů, samoobslužná optimalizace pomocí strojového učení, multi-modelové databáze podporující více paradigmat současně a edge databáze pro lokální zpracování dat blízko zdroje.
Závěr
Neexistuje univerzální databáze. Konzervativní volba v podobě PostgreSQL nebo MySQL zvládne podstatně více scénářů, než se obecně předpokládá. Specializovaná řešení mají smysl tam, kde standardní systémy narážejí na limity. Klíčem je pravidelné měření na reálných datech, plánování s ohledem na budoucí migraci a přiznání kompromisů, které každá technologie přináší. Nejlepší databáze není ta nejnovější ani nejvýkonnější v benchmarcích, ale ta, která řeší konkrétní obchodní problém a zapadá do týmových schopností i rozpočtu.
Doporučené zdroje:
- Use The Index, Luke – příručka výkonu SQL dotazů
- DB-Engines Ranking – přehled databázových systémů
- Martin Kleppmann: Designing Data-Intensive Applications
- High Scalability – architektury reálných systémů
