NoSQL databáze: typy, výhody a výběr řešení (MongoDB, Cassandra)

Co jsou NoSQL databáze a proč vznikly

NoSQL databáze představují širokou rodinu úložišť navržených pro horizontální škálování, vysokou dostupnost a flexibilní modelování dat mimo striktní relační schéma. Vznikly jako reakce na potřeby webových gigantů (objemy dat, proměnlivá schémata, latence v milisekundách) a na omezení tradičních RDBMS v distribuovaných prostředích. NoSQL neznamená „bez SQL“ ve smyslu absence dotazovacího jazyka, ale spíše „Not Only SQL“ – důraz na alternativní datové modely a kompromisy mezi konzistencí, dostupností a latencí.

Typy NoSQL databází a jejich datové modely

Key–Value (K/V): nejjednodušší model (klíč → hodnota). Vhodné pro cache, ukládání relací, konfigurace. Typicky extrémně rychlé operace O(1), dobré horizontální dělení (sharding).
Document store: ukládá dokumenty (JSON/BSON) s flexibilním schématem. Přirozeně mapuje aplikační objekty, podporuje pokročilé dotazy, indexy a agregace. Vhodné pro obsahové systémy, katalogy, event logy.
Wide-column (column-family): data organizovaná do rodin sloupců, inspirovaná Bigtable. Optimální pro časové řady, analytické dotazy nad rozsáhlými datasety a sekvenční zápisy.
Grafové databáze: reprezentují entity (vrcholy) a vztahy (hrany) s atributy, optimalizované pro traversály (např. doporučování, hledání nejkratších cest, závislostní grafy).
Time-series databáze: optimalizované pro ingest metrik, kompresi a downsampling; podporují okénkové agregace, retence a TTL politiky.
Search engine / inverted index: specializované na fulltextové vyhledávání, relevantnost, tokenizaci, facety a geospatial dotazy; často používány jako doplněk k primárnímu úložišti.

CAP a PACELC: teorie kompromisů v praxi

CAP tvrdí, že v přítomnosti síťového rozdělení nelze současně plně zajistit konzistenci (Consistency) a dostupnost (Availability); systémy volí mezi CA, CP nebo AP podle priorit. PACELC rozšiřuje tento pohled: Při partition (network partition) volíme mezi A vs. C, ELSE (bez partition) se rozhodujeme mezi latencí a konzistencí. Prakticky to znamená, že systémy balancují mezi silnou, kauzální či eventual konzistencí a mezi liniovou a subliniovou latencí.

Konzistenční modely

Silná konzistence: čtení po zápisu ihned zobrazí poslední hodnotu. Typicky znamená vyšší latenci a menší toleranci k poruchám.
Eventual consistency: systém se postupně sbíhá do konzistentního stavu; nízká latence, vysoká dostupnost, avšak s nutností počítat s dočasnými rozporuplnostmi.
Kauzální konzistence: zachovává příčinné vztahy mezi operacemi, což je dobrý kompromis pro distribuované aplikace a uživatelské feedy.
Per-partition/Per-key linearizovatelnost: silná konzistence v rámci jednotlivých partíc či klíčů, slabší napříč celým clusterem.

Škálování: horizontální dělení, replikace a topologie

Sharding (partitioning): dělení datasetu podle hash klíče, rozsahu nebo vlastních pravidel; klíčové je vyhnout se hotspotům a zajistit rovnoměrnou distribuci dat.
Replikace: synchronní vs. asynchronní; multi-leader, single-leader nebo leaderless konfigurace. Volba ovlivňuje latenci, dostupnost a riziko ztráty dat při havárii.
Topologie: regionální, multi-region a multi-cloud řešení – důraz na latenci vůči uživatelům a legislativní požadavky na geografické umístění dat.

Indexace a dotazování

NoSQL databáze nabízejí různé indexační mechanismy: B-stromy, LSM-trees, inverzní indexy, geospatial indexy, sekundární indexy na vybraných polích dokumentů či sloupcích. Volba indexu výrazně ovlivňuje rychlost ingestování dat, latenci dotazů i nároky na úložný prostor. U document store je nutné pečlivě volit klíčové pole (shard key) a indexy pro nejčastější vzory dotazů (filtry, řazení, projekce).

Transakce a izolace

Atomické operace nad jediným klíčem jsou běžné, kvůli jednoduchosti a výkonu.
Více-dokumentové transakce existují v některých dokumentových a grafových systémech, často s omezeními v latenci a propustnosti; jsou vhodné spíše pro kritické případy použití.
Izolační úrovně: od read-committed po snapshot isolation; v distribuovaných prostředích je třeba počítat s write skew a implementovat aplikační zábrany (např. optimistic concurrency control).

Modelování dat: od anti-normalizace k agregátům

Na rozdíl od RDBMS je běžné denormalizovat a ukládat agregáty dat pro typické čtecí vzory. Cílem je minimalizovat počet I/O operací a síťových přenosů při dotazech. Doporučení:

Začněte od pracovní zátěže (top dotazy, latence SLO, velikost dokumentů/záznamů).
Navrhujte granularitu dokumentů tak, aby většina dotazů načítala 1–2 položky.
Pečlivě vybírejte shard key (kardinalita, rovnoměrnost, vzory dotazů, prevence hotspotů).
Pro scénáře s převahou čtení zvažte materializované pohledy nebo předagregované kolekce.

Typické use-cases a volba typu databáze

Cache, session, omezování rychlosti: Key–Value model pro extrémní propustnost a nízkou latenci.
CMS, katalogy, uživatelské profily: Document store vzhledem k flexibilnímu schématu a bohatým dotazům.
Telemetrie, IoT, monitoring: Time-series nebo wide-column databáze s efektivním append-only ingestem a downsamplingem.
Doporučování, znalostní grafy, síťové analýzy: Grafové databáze optimalizované pro traversály.
Fulltextové vyhledávání: Search engine se schématem pro relevanci a facety, často doplňující primární úložiště.

Výkonnostní charakteristiky a benchmarky

Důležité metriky: p99/p999 latence, propustnost (ops/s), write amplification (v LSM), režie úložiště, efektivita komprese, velikost SSTable/segmentů, read amplification. Benchmarky by měly pokrývat realistické rozložení dat (Zipf, hotspoty), mix operací (poměr čtení/zápisu), velikost payloadu a testovat chování při reshardingu, failoveru a obnově indexů.

Spolehlivost, odolnost a disaster recovery

RPO/RTO: definujte cílové hodnoty a přizpůsobte jim replikaci a zálohování.
Zálohy: snapshoty na úrovni shardů, inkrementální zálohy, pravidelné testy obnovy (restore drills).
Chaos testing: simulace výpadků uzlů, latencí, split-brain situací; ověřujte auto-failover a rebalance klastru.

Bezpečnost a compliance

Šifrování dat na disku (TDE) i v přenosu (TLS), správa klíčů (KMS, HSM).
Řízení přístupu: role-based access control, princip minimálních práv, auditní logy.
Správa dat (data governance): retence, anonymizace/pseudonymizace, právo na výmaz; sledování genealogie dat (lineage).

Provoz a observabilita

Monitoring: CPU, I/O, garbage collection, latence p50–p999, počet otevřených spojení, hloubka fronty, velikost memtable/commit logu.
Alerting: porušení SLA, zpoždění replikace (replication lag), zaplnění disku, zvýšená chybovost klientů.
Plánování kapacity (capacity planning): růst dat, TTL a retence, kompakce a efekt komprese, náklady na datový přenos mezi regiony.

Cloudové služby a provozní modely

Managed služby: snižují provozní režii (patchování, auto-scaling, automatické zálohy), ale vyžadují porozumění limitům (kvóty, šum multi-tenant prostředí).
Self-managed: plná kontrola nad nastavením, často levnější při velkém měřítku; vyšší nároky na odborné znalosti a kapacity SRE.
Hybridní/multi-cloud: snižuje vendor lock-in, ale komplikuje síťovou infra strukturu, konzistenci a provozní postupy.

Migrační strategie z RDBMS

Identifikace domén, kde NoSQL přináší hodnotu (objem, variabilita schématu, latence, škálování).
Event storming a domain modeling → volba datového modelu a klíčových dotazů.
Dual-write / Change Data Capture pro bezvýpadkový přechod, validace datové parity.
Postupná dekompozice: začít read-only workloady, poté kritické zápisy, nakonec vypnutí staré cesty.

Polyglot persistence a architektonické vzory

Polyglot persistence: kombinace více databází podle účelu (např. dokumentová + vyhledávací + time-series).
CQRS: oddělení čtecí a zapisovací vrstvy, read modely v NoSQL pro rychlé UI a analytiku.
Event sourcing: ukládání zdrojových událostí v append-only store, projekce do materializovaných pohledů.

Optimalizace výkonu: praktické taktiky

Volba velikosti dokumentu/záznamu: příliš velké zvyšují latenci a paměťovou zátěž, příliš malé navyšují režii indexů.
TTL a retence: omezení objemu dat a nákladů, plánování kompakcí mimo špičku.
Batchování a idempotence: minimalizujte overhead na požadavek, navrhujte bezpečné opakování při chybách sítě.
Cache vrstvy: umístěte in-memory cache před NoSQL pro hot keys; snižte tlak na primární úložiště.

Časté anti-patterny

„Lift-and-shift“ schéma z RDBMS bez úpravy dotazovacích vzorů → špatný výkon.
Nevhodný shard key → hotspoty, nevyvážené partitiony, nákladné reshardingy.
Přehnaná denormalizace bez strategie aktualizací → nekonzistence a složitý kód.
Ignorování konzistence v kritických procesech (finanční platby, objednávky) → nevyhnutelné transakční zábrany nebo jiný model.

Náklady a TCO

Náklady ovlivňuje datová velikost (po kompresi), replikační faktor, I/O profil (náhodný vs. sekvenční), síťové přenosy mezi regiony, správa záloh a logů, typ úložiště (SSD vs. HDD) a režie kompakcí. V cloudu je třeba sledovat limity propustnosti (RU/ops), typ výpočetní instance a replikaci mezi regiony.

Testování a kvalita

Contract testy pro serializaci/deserializaci dokumentů a evoluci schématu.
Load testy s realistickými daty a distribucí klíčů.
Chaos testy pro ověření zotavení po výpadcích a chování při síťovém partition.

Výběrová kritéria při volbě NoSQL platformy

Datový model vs. workload (dotazy, agregace, transakce, TTL).
Škálování a latence (jednoregionální vs. multiregionální, replikace, nastavitelné konzistenční modely).
Operabilita (monitoring, backup/restore, evoluce schématu, nástroje).
Ekosystém (ovladače, konektory, CDC, integrace se streamingem a ETL).
Bezpečnost a compliance (šifrování, RBAC, audit, lokalita dat).
Náklady (licence, managed vs. self-hosted, datový egress, rezervované kapacity).

Závěr

NoSQL databáze rozšiřují možnosti práce s daty tam, kde tradiční relační přístup naráží na limity škálování a flexibility. Úspěch implementace závisí méně na „značce“ a více na porozumění datovému modelu, pracovním vzorům, požadavkům na konzistenci a provozním aspektům. Správně zvolený typ (dokumentová, key–value, wide-column, grafová či time-series) a pečlivý návrh shardingu, indexace a observability přináší vysoký výkon, dostupnost a dlouhodobě udržitelnou architekturu.