NoSQL databáze – Európska ekonomika

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, session store, konfigurace. Typicky extrémně rychlé operace O(1), dobré horizontální dělení (sharding).
Document store: ukládá dokumenty (JSON/BSON) s pružným schématem. Přirozeně mapuje aplikační objekty, podporuje bohaté dotazy, indexy, agregace. Vhodné pro obsahové systémy, katalogy, event logy.
Wide-column (column-family): data organizovaná do rodin sloupců, inspirováno Bigtable. Optimální pro časové řady, analytické dotazy nad masivními datasetty a sekvenční zápisy.
Grafové databáze: reprezentují entity (vrcholy) a vztahy (hrany) s vlastnostmi, optimalizované pro traversaly (např. doporučování, zjišťová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 fulltext, relevanci, tokenizaci, facety a geospatial dotazy; často používány vedle primárního úložiště.

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í CA, CP, nebo AP podle priorit. PACELC rozšiřuje pohled: Při partition volíme A vs. C, ELSE (bez partition) volíme Latency vs. Consistency. Prakticky: systémy se rozhodují mezi silnou, kauzální či eventual konzistencí a mezi liniovou a subliniovou latencí.

Konzistenční modely

Silná konzistence: čtení po zápisu okamžitě vidí poslední hodnotu. Typicky vyšší latence a menší tolerance k poruchám.
Eventual consistency: systém se postupně sbíhá; nízká latence, vysoká dostupnost, nutnost počítat s dočasnými nekonzistencemi.
Kauzální konzistence: zachovává příčinné vztahy mezi operacemi, dobrý kompromis pro distribuované aplikace a uživatelské feedy.
Per-partition/Per-key linearizovatelnost: silná konzistence v rámci vybrané domény (partice/klíče) a slabší napříč celým clusterem.

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

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

Indexace a dotazování

NoSQL databáze poskytují 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 zásadně ovlivňuje ingest rychlost, latenci dotazů i nároky na storage. U document store je nutné pečlivě volit klíčové pole (shard key) a indexy pro nejčastější query patterns (filtry, sort, projekce).

Transakce a izolace

Jednoklíčové atomické operace 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 (latence, throughput) a vhodné spíše pro kritické use-cases.
Izolační úrovně: od read-committed po snapshot isolation; v distribuovaných nastaveních je třeba počítat s write skew a potřebou aplikačních zábran (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 a síťových hopů na dotaz. Doporučení:

Začněte od workloadu (top dotazy, latency SLO, velikost dokumentů/záznamů).
Navrhujte granularitu dokumentů tak, aby většina dotazů četla 1–2 položky.
Pečlivě volte shard key (kardinalita, rovnoměrnost, dotazovací vzory, prevence hotspotů).
Pro read-heavy scénáře zvažte materializované pohledy nebo předagregované kolekce.

Typické use-cases a volba typu databáze

Cache, session, rate limiting: Key–Value pro extrémní propustnost a nízkou latenci.
CMS, katalogy, uživatelské profily: Document store kvůli flexibilnímu schématu a bohatým dotazům.
Telemetry, IoT, monitoring: Time-series nebo wide-column s efektivním append-only ingestem a downsamplingem.
Doporučování, znalostní grafy, síťové analýzy: Grafové databáze optimalizované na traversaly.
Fulltext a vyhledávání: Search engine se schématem pro relevance a facety, často vedle primárního úložiště.

Výkonnostní charakteristiky a benchmarky

Důležité metriky: p99/p999 latence, throughput (ops/s), write amplification (u LSM), storage overhead, efektivita komprese, velikost SSTable/segmentů, read amplification. Benchmarky by měly pokrývat realistické datové rozložení (Zipf, hotspoty), mix operací (R/W ratio), velikosti payloadu a chování při reshardingu, failoveru a rebuild indexů.

Spolehlivost, odolnost a disaster recovery

RPO/RTO: definujte cílové ukazatele a přizpůsobte jim replikaci a zálohování.
Zálohy: snapshoty na úrovni shardů, inkrementální backupy, test obnovy (regular restore drills).
Chaos testing: simulace výpadků uzlů, latence, split-brain; ověření auto-failoveru a rebalance.

Bezpečnost a compliance

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

Provoz a observabilita

Monitoring: CPU, I/O, GC, latence p50–p999, počet otevřených spojení, queue depth, velikost memtable/commit logu.
Alerting: SLA porušení, replikace zaostává (replication lag), zaplnění disku, zvýšená chybovost klientů.
Capacity planning: růst dat, TTL a retence, kompakce a efekt komprese, náklady na egress mezi regiony.

Cloudové služby a provozní modely

Managed služby: snižují provozní režii (patching, auto-scaling, auto-backup), ale vyžadují porozumění limitům (kvóty, multi-tenant šum).
Self-managed: plná kontrola nad nastavením, často levnější při velkém měřítku; vyšší nároky na expertízu a SRE kapacity.
Hybrid/multi-cloud: snižuje vendor lock-in, ale komplikuje síť, 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: kombinace více databází dle účelu (např. dokumentová + vyhledávací + time-series).
CQRS: oddělení čtecí a zapisovací části, read modely v NoSQL pro rychlá UI a analytiku.
Event sourcing: uložení zdrojových událostí v append-only store, projekce do materiálovaných pohledů.

Optimalizace výkonu: praktické taktiky

Volba velikosti dokumentu/záznamu: příliš velké zvyšují latenci a paměťové tlaky, příliš malé zvyšují režii indexů.
TTL a retence: omezte objem dat a náklady, plánujte kompakce mimo špičku.
Batchování a idempotence: minimalizujte overhead per-request, navrhujte bezpečné opakování při chybách sítě.
Cache vrstvy: před NoSQL vložte in-memory cache pro hot keys; snižte tlak na primární úložiště.

Časté anti-patterny

„Lift-and-shift“ schématu z RDBMS bez změny dotazovacích vzorů → špatný výkon.
Nevhodný shard key → hotspoty, nevyvážené partitiony, drahé reshardingy.
Přehnaná denormalizace bez strategií aktualizací → nekonzistence a složitý kód.
Ignorování konzistence v kritických tocích (peníze, objednávky) → potřebné transakční zábrany či jiný model.

Náklady a TCO

Náklady ovlivňuje datová velikost (po kompresi), replikační faktor, I/O profil (random vs. sekvenční), síťové egressy mezi regiony, správa záloh a logů, typ storage (SSD vs. HDD) a režie kompakcí. V cloudu sledujte limity throughputu (RU/ops), výpočetní třídy a cross-region replikaci.

Testování a kvalita

Contract testy pro serializaci/deserializaci dokumentů a evoluci schématu.
Load testy s realistickými daty a distribucí klíčů.
Jecha testy (chaos) pro ověření zotavení po pádech a behavioru při partition.

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

Datový model vs. workload (dotazy, agregace, transakce, TTL).
Škálování a latence (single vs. multi region, replikace, consistency tunables).
Operabilita (monitoring, backup/restore, schema evolution, tooling).
Ekosystém (ovladače, konektory, CDC, integrace s streamy a ETL).
Bezpečnost a compliance (šifrování, RBAC, audit, lokalita dat).
Náklady (licence, managed vs. self-hosted, 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.