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

Co jsou databáze NoSQL a proč vznikly

Databáze NoSQL 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 systémů 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 databází NoSQL a jejich datové modely

Key–Value (K/V): nejjednodušší model (klíč → hodnota). Vhodný pro cache, úložiště relací a konfigurace. Typicky nabízí extrémně rychlé operace O(1) a dobře se horizontálně dělí (sharding).
Úložiště dokumentů: ukládá dokumenty (JSON/BSON) s flexibilním schématem. Přirozeně mapuje aplikační objekty a podporuje pokročilé dotazy, indexy i agregace. Vhodné pro systémy pro správu obsahu, katalogy a protokoly událostí.
Širokosloupcové databáze (column-family): data jsou organizována do rodin sloupců, což je přístup inspirovaný systémem Bigtable. Jsou optimální pro časové řady, analytické dotazy nad rozsáhlými datovými sadami a sekvenční zápisy.
Grafové databáze: reprezentují entity (vrcholy) a vztahy (hrany) s vlastnostmi a jsou optimalizované pro průchody grafem (např. doporučování, hledání nejkratších cest a grafy závislostí).
Databáze časových řad: jsou optimalizované pro příjem metrik, kompresi a zmenšování rozlišení dat; podporují agregace v časových oknech, uchovávání dat a zásady TTL.
Vyhledávací stroj / invertovaný index: specializuje se na fulltextové vyhledávání, relevanci, tokenizaci, fasety a geoprostorové dotazy; často se používá vedle primárního úložiště.

CAP a PACELC: teorie kompromisů v praxi

CAP tvrdí, že v případě 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 tento pohled rozšiřuje: Při rozdělení sítě volíme mezi A a C, jinak (bez rozdělení) volíme mezi latencí a konzistencí. V praxi se systémy rozhodují mezi silnou, kauzální či eventual konzistencí a mezi lineární a sublineární latencí.

Konzistenční modely

Silná konzistence: čtení po zápisu okamžitě vrátí poslední hodnotu. Typicky znamená vyšší latenci a menší toleranci k poruchám.
Eventual consistency: systém se postupně sjednocuje; nabízí nízkou latenci a vysokou dostupnost, ale je nutné počítat s dočasnými nekonzistencemi.
Kauzální konzistence: zachovává příčinné vztahy mezi operacemi a představuje dobrý kompromis pro distribuované aplikace a uživatelské kanály příspěvků.
Linearizovatelnost pro jednotlivé oddíly/klíče: silná konzistence v rámci vybrané domény (oddílu/klíče) a slabší konzistence napříč celým clusterem.

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

Sharding (dělení na oddíly): dělení datové sady podle hashovacího klíče, rozsahu nebo vlastních pravidel; zásadní je vyhnout se úzkým místům a zajistit rovnoměrné rozložení dat.
Replikace: synchronní vs. asynchronní; s více vedoucími uzly, jedním vedoucím uzlem nebo bez vedoucího uzlu. Volba ovlivňuje latenci, dostupnost a riziko ztráty dat při havárii.
Topologie: regionální, více regionů a více cloudů – důraz na latenci pro uživatele a legislativní požadavky na umístění dat.

Indexování a dotazování

Databáze NoSQL nabízejí různé mechanismy indexování: B-stromy, LSM-stromy, invertované indexy, geoprostorové indexy a sekundární indexy nad vybranými poli dokumentů či sloupci. Volba indexu zásadně ovlivňuje rychlost příjmu dat, latenci dotazů i nároky na úložiště. U úložišť dokumentů je nutné pečlivě zvolit klíčové pole (klíč oddílu) a indexy pro nejčastější vzory dotazů (filtry, řazení, projekce).

Transakce a izolace

Atomické operace s jedním klíčem jsou běžné (kvůli jednoduchosti a výkonu).
Transakce zahrnující více dokumentů existují v některých dokumentových a grafových systémech, často s omezeními (latence, propustnost), a hodí se spíše pro kritické případy použití.
Úrovně izolace: od read-committed po izolaci snímku; v distribuovaných prostředích je třeba počítat s anomálií write skew a s potřebou aplikačních ochranných mechanismů (optimistická kontrola souběžnosti).

Modelování dat: od denormalizace k agregátům

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

Začněte od pracovní zátěže (nejčastější dotazy, SLO latence, velikost dokumentů/záznamů).
Navrhujte granularitu dokumentů tak, aby většina dotazů načítala 1–2 položky.
Pečlivě volte klíč oddílu (kardinalita, rovnoměrnost, vzory dotazů, prevence úzkých míst).
U scénářů náročných na čtení zvažte materializované pohledy nebo předagregované kolekce.

Typické případy použití a volba typu databáze

Cache, relace, omezení rychlosti požadavků: úložiště Key–Value pro extrémní propustnost a nízkou latenci.
CMS, katalogy, uživatelské profily: úložiště dokumentů díky flexibilnímu schématu a pokročilým dotazům.
Telemetrie, IoT, monitoring: databáze časových řad nebo širokosloupcové databáze s efektivním příjmem dat pouze pro zápis a zmenšováním rozlišení.
Doporučování, znalostní grafy, síťové analýzy: grafové databáze optimalizované pro průchody grafem.
Fulltextové vyhledávání: vyhledávací stroj se schématem pro relevanci a fasety, často vedle primárního úložiště.

Výkonnostní charakteristiky a benchmarky

Důležité metriky: latence p99/p999, propustnost (operace/s), zesílení zápisu (u LSM), režie úložiště, účinnost komprese, velikost SSTable/segmentů a zesílení čtení. Benchmarky by měly pokrývat realistické rozložení dat (Zipfovo rozložení, úzká místa), směs operací (poměr čtení a zápisů), velikosti datových částí a chování při změně rozdělení dat mezi uzly, přepnutí při selhání a opětovném sestavení indexů.

Spolehlivost, odolnost a obnova po havárii

RPO/RTO: definujte cílové hodnoty a přizpůsobte jim replikaci a zálohování.
Zálohy: snímky na úrovni oddílů, přírůstkové zálohy a testování obnovy (pravidelné zkoušky obnovy).
Testování odolnosti: simulace výpadků uzlů, latence a rozdělení sítě; ověřování automatického přepnutí při selhání a změny rozložení dat.

Bezpečnost a soulad s předpisy

Šifrování na disku (TDE) i při přenosu (TLS), správa klíčů (KMS, HSM).
Řízení přístupu: řízení přístupu na základě rolí, princip nejmenších oprávnění a protokoly auditu.
Správa dat: doba uchovávání, anonymizace/pseudonymizace, právo na výmaz; sledování původu dat (lineage).

Provoz a pozorovatelnost

Monitoring: CPU, I/O, GC, latence p50–p999, počet otevřených spojení, hloubka fronty, velikost memtable/protokolu potvrzení transakcí.
Upozorňování: porušení SLA, zpoždění replikace, zaplnění disku a zvýšená chybovost klientů.
Plánování kapacity: růst objemu dat, TTL a doba uchovávání, kompakce a efekt komprese, náklady na výstup dat mezi regiony.

Cloudové služby a provozní modely

Spravované služby: snižují provozní režii (instalace oprav, automatické škálování, automatické zálohování), ale vyžadují pochopení limitů (kvóty, nežádoucí vliv ostatních tenantů).
Vlastní správa: nabízí plnou kontrolu nad nastavením a při velkém měřítku bývá často levnější; klade vyšší nároky na odbornost a kapacity SRE.
Hybridní prostředí / více cloudů: snižuje závislost na dodavateli, ale komplikuje síť, konzistenci a provozní postupy.

Migrační strategie ze systémů RDBMS

Identifikace domén, v nichž NoSQL přináší hodnotu (objem, variabilita schématu, latence, škálování).
Mapování událostí a doménové modelování → volba datového modelu a klíčových dotazů.
Duální zápis / zachytávání změn dat pro přechod bez výpadku, ověření shody dat.
Postupný rozklad: začít úlohami pouze pro čtení, poté přejít ke kritickým zápisům a nakonec vypnout starou cestu.

Polyglotní perzistence a architektonické vzory

Polyglotní perzistence: kombinace více databází podle účelu (např. dokumentové, vyhledávací a časových řad).
CQRS: oddělení čtecí a zapisovací části, čtecí modely v NoSQL pro rychlá uživatelská rozhraní a analytiku.
Event sourcing: ukládání zdrojových událostí do úložiště pouze pro zápis, vytváření projekcí do materializovaných pohledů.

Optimalizace výkonu: praktické postupy

Volba velikosti dokumentu/záznamu: příliš velké dokumenty zvyšují latenci a zatěžují paměť, příliš malé zvyšují režii indexů.
TTL a doba uchovávání: omezte objem dat a náklady, kompakci plánujte mimo špičku.
Dávkové zpracování a idempotence: minimalizujte režii jednotlivých požadavků a navrhujte bezpečné opakování při chybách sítě.
Vrstvy cache: před databázi NoSQL vložte mezipaměť v paměti pro často používané klíče; snížíte tak zátěž primárního úložiště.

Časté anti-patterny

„Lift-and-shift“ schématu ze systému RDBMS bez změny vzorů dotazování → špatný výkon.
Nevhodný klíč oddílu → úzká místa, nevyvážené oddíly a nákladné změny rozdělení dat mezi uzly.
Přehnaná denormalizace bez strategií aktualizace → nekonzistence a složitý kód.
Ignorování konzistence v kritických tocích (peníze, objednávky) → nutnost transakčních ochranných mechanismů či jiného modelu.

Náklady a celkové náklady na vlastnictví (TCO)

Náklady ovlivňuje velikost dat (po kompresi), replikační faktor, profil I/O (náhodný vs. sekvenční), výstup dat mezi regiony, správa záloh a protokolů, typ úložiště (SSD vs. HDD) a režie kompakce. V cloudu sledujte limity propustnosti (RU/operace), výpočetní třídy a replikaci mezi regiony.

Testování a kvalita

Kontraktní testy serializace/deserializace dokumentů a evoluce schématu.
Zátěžové testy s realistickými daty a rozložením klíčů.
Testy odolnosti (chaos) pro ověření zotavení po pádech a chování při rozdělení sítě.

Kritéria výběru platformy NoSQL

Datový model vs. pracovní zátěž (dotazy, agregace, transakce, TTL).
Škálování a latence (jeden region vs. více regionů, replikace, nastavitelné parametry konzistence).
Provozovatelnost (monitoring, zálohování/obnova, evoluce schématu, nástroje).
Ekosystém (ovladače, konektory, CDC, integrace s datovými proudy a ETL).
Bezpečnost a soulad s předpisy (šifrování, RBAC, audit, umístění dat).
Náklady (licence, spravované služby vs. vlastní provoz, výstup dat, rezervovaná kapacita).

Závěr

Databáze NoSQL 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, širokosloupcová, grafová či časových řad) a pečlivý návrh shardingu, indexování a pozorovatelnosti přinášejí vysoký výkon, dostupnost a dlouhodobě udržitelnou architekturu.