Typy NoSQL databází

Proč NoSQL a jaké typy dnes dominují

NoSQL označuje rodinu databázových systémů navržených pro horizontální škálování, vysokou dostupnost a flexibilitu schématu. Zatímco relační databáze (SQL) kladou důraz na pevná schémata a silnou konzistenci, NoSQL přináší alternativní modely dat a kompromisy (CAP) vhodné pro moderní distribuované aplikace. Tento článek se zaměřuje na tři nejrozšířenější kategorie: dokumentové, klíč–hodnota a grafové databáze.

CAP teorie a typické konzistenční profily

• CAP: V prostředí s možnou partiční poruchou nelze současně maximalizovat konzistenci (C) i dostupnost (A). Systémy volí mezi CP (preferují konzistenci) a AP (preferují dostupnost) dle domény použití.
• Konzistence: silná (linearizovatelná), eventual, causal; některé systémy umožňují per-operaci volit úroveň čtení/zápisu.
• ACID vs. BASE: NoSQL často nabízí lokální ACID (na dokument/klíč/partici) a BASE (eventual consistency) napříč clusterem. Mnohé platformy již podporují i více-dokumentové transakce s omezeními.

Modelování dat v NoSQL: obecné principy

• Denormalizace a agregáty: Data se často modelují kolem agregátů (např. objednávka se všemi položkami), aby se minimalizovaly cross-entity operace.
• Přístupové vzory > schéma: Návrh tabulek/kolekcí/klíčů začíná od dotazů a SLA (latence, propustnost), nikoli od ER diagramu.
• Particionování: Volba distribučního klíče je kritická pro rovnoměrné rozdělení zátěže a minimalizaci hotspotů.

Dokumentové databáze: definice a charakteristiky

Dokumentové systémy ukládají data jako samostatné dokumenty (JSON, BSON, podobné formáty) s flexibilním schématem. Dokument typicky reprezentuje agregát s vnořenými strukturami.

• Datový model: hierarchický (objekty, pole, vnoření), možnost heterogenních schémat v jedné kolekci.
• Dotazy: bohaté dotazovací jazyky (filtry, projekce, agregace, pipelines); geospatial, textové vyhledávání, sekundární indexy.
• Transakce: běžně atomické operace na dokument; moderní systémy často podporují multi-dokumentové transakce v rámci jedné partitce/šardů.
• Škálování: horizontální (sharding) podle klíče (např. userId, tenantId); replikace s failoverem.
• Use-cases: obsahové systémy, katalogy, e-commerce košíky a objednávky, event logy s bohatým dotazováním, mobilní/IoT backendy.

Příklad dokumentu a indexace

{ "orderId": "A-10293", "customer": {"id": "C-77", "name": "Novák"}, "items": [ {"sku": "P-1", "qty": 2, "price": 199.0}, {"sku": "P-9", "qty": 1, "price": 499.0} ], "status": "shipped", "createdAt": "2025-10-01T10:22:15Z" } 

• Indexy: kompozitní (např. status, createdAt), TTL indexy pro expirační data, textové/geospatial indexy.
• Agregace: pipeline (match → group → sort → project) pro analytiku nad operativními daty.

Typická technologická volba pro dokumentové DB

• Silné stránky: flexibilita schématu, bohaté dotazy a indexace, dobrý kompromis mezi OLTP a lehkou analýzou.
• Limity: dražší cross-document joiny, nutnost pečlivé volby shard klíče, velikost dokumentů a atomických limitů.

Databáze klíč–hodnota: definice a charakteristiky

Key–Value ukládá nestrukturované nebo binární hodnoty adresované jednoznačným klíčem. Důraz je na extrémně nízkou latenci a jednoduchost operací.

• Datový model: asociativní pole (mapa) distribuované napříč uzly; hodnota může být binární blob nebo strukturovaný objekt serializovaný aplikací.
• Dotazy: typicky pouze operace podle klíče (GET/PUT/DELETE), případně prefix/interval u některých systémů.
• Datové struktury: in-memory (s perzistencí do logu/snapshotu) nebo on-disk s LSM-tree; podpora struktur jako hash, list, set, sorted set (u některých systémů).
• Škálování: horizontální přes consistent hashing; velmi vysoká propustnost (miliony RPS) s malou latencí.
• Use-cases: cache, session store, rate-limiting, fronty, leaderboards, feature flagemeny, quick-lookup pro mikroservisy.

Příklad schématu klíčů a vzory

user:123:profile -> JSON profil user:123:sessions -> set tokenů order:2025-10:seq -> čítač (INCR) rate:ip:1.2.3.4 -> sliding window token bucket 

• Vzory: Write-through/Write-behind cache, cache-aside, distributed locks (při vědomí limitů), počítadla, pub/sub.
• Limity: složitější dotazy vyžadují sekundární indexaci (externí) nebo jiný systém; správa TTL a evikcí je klíčová pro předvídatelné chování.

Grafové databáze: definice a charakteristiky

Grafové DB reprezentují data jako uzly (vrcholy) a hrany s vlastnostmi. Optimalizují traverzy vztahů a dotazy, kde je struktura a hloubka spojů zásadní.

• Model: property-graph (uzly/edge s key–value vlastnostmi) nebo RDF (trojice subjekt–predikát–objekt).
• Dotazovací jazyky: Gremlin, Cypher, GQL (konsolidující standard), SPARQL (pro RDF).
• Indexy: na vlastnosti uzlů/hran; klíčová je adjacency list reprezentace pro rychlé skoky mezi vrcholy.
• Škálování: komplexní; sharding grafu je obtížný (edge-cut vs. vertex-cut). Pro masivní grafy se volí partition-aware dotazy a replicace subgrafů.
• Use-cases: doporučování (friends-of-friends), znalostní grafy, detekce podvodů (spoluúčast), síťové/IT topologie, master data se silnými vztahy.

Příklad dotazu v grafové DB (Cypher)

MATCH (u:User {id: "U-1"})-[:BOUGHT]->(:Product)<-[:BOUGHT]-(peer:User) MATCH (peer)-[:BOUGHT]->(rec:Product) WHERE NOT (u)-[:BOUGHT]->(rec) RETURN rec, count(*) AS score ORDER BY score DESC LIMIT 10; 

• Výhoda: přirozený výraz pro vícestupňové vztahy a vzory.
• Limity: náročnější horizontální škálování a složitější operace agregace oproti sloupcovým analytickým engineům.

Srovnávací tabulka: dokumentové vs. klíč–hodnota vs. grafové

Konzistence a transakce napříč typy

• Dokumentové: atomika na dokument; multi-dokumentové transakce často s omezeními (např. v rámci kolekce/šardu).
• Klíč–hodnota: per-klíč linearizovatelnost; cross-key transakce obvykle chybí nebo jsou nákladné.
• Grafové: ACID v rámci jedné instance/repliky; v distribuovaném grafu obtížné udržet globální serializaci.

Indexace, dotazovací optimalizace a výkon

• Dokumentové: B-stromy, hash, text, geo; covered queries, agregace na sloupcově uložených statistikách (u některých).
• Klíč–hodnota: primární index = klíč; sekundární indexy řeší aplikace nebo doprovodné služby.
• Grafové: indexy pro vstupní uzly; výkon následně závisí na hustotě hran a selektivitě vzoru.

Škálování a dostupnost: replikace a sharding

• Replikace: leader–followers s failoverem, případně multi-leader pro geo; grafy někdy replikují sub-grafy pro rychlé lokální čtení.
• Sharding: dokumentové a key–value: přirozené; grafové: náročné (minimalizovat edge-cuts, používat komunitní detekci pro partitioning).

Bezpečnost a governance

• Autentizace/Autorizace: RBAC, šifrování v přenosu (TLS) i v klidu (TDE), audit přístupů.
• Více-tenantní provoz: oddělení tenantů schématy/namespace, limity prostředků, kvóty, rate-limits.
• Data lifecycle: TTL/archivace, retenční politiky pro logy/eventy.

Návrhové vzory pro každou kategorii

• Dokumentové: one-to-few embed, one-to-many reference (přes cizí klíče), bucket pattern pro časové série, subset pattern pro „hot“ pole.
• Klíč–hodnota: composite keys (prefix + ID), time-bucketed keys, idempotent writes pro opakované pokusy, distributed counters s shardingem.
• Grafové: modelování typů uzlů a hran (labely), směrování hran, vlastnosti s indexy, denormalizace derivovaných vztahů pro časté dotazy.

Anti-patterns a časté chyby

• Dokumentové: přerůstající dokumenty (megadokumenty), hotspot sharding klíče (např. monotónní timestamp), bezhlavé využití transakcí napříč shardami.
• Klíč–hodnota: používání KV jako databáze pro ad-hoc dotazy (bez indexů), nekontrolované TTL a evikce, reliance na distribuované zámky bez pochopení failure módů.
• Grafové: dotazy s vysokou šířkou expanze bez hloubkových/selektivních omezení, náhodné rozdělení grafu bez ohledu na komunitní struktury.

Volba technologie podle use-case

• Rychlé lookupy a cache → klíč–hodnota (in-memory s perzistencí).
• Operativní data s bohatými dotazy → dokumentová DB.
• Komplexní vztahy a cesty → grafová DB.
• Hybridní přístup: kombinace (polyglot persistence): např. Kafka + KV pro rychlé stavy, dokumentová pro agregáty, graf pro doporučování.

Provozní aspekty: monitoring, zálohy, migrace

• Monitoring: latence p50/p95/p99, throughput, velikost a fragmentace indexů, lag replikací, GC/heap u JVM systémů.
• Zálohy/obnova: snapshoty na úrovni úložiště, point-in-time (pokud podporováno), testy obnovy (DR cvičení).
• Migrace schémat: v dokumentových DB schema-on-read, postupná migrace dokumentů při přístupu; u grafů migrovat postupně části grafu.

Závěr: jak přistupovat k návrhu NoSQL řešení

Úspěch nasazení NoSQL závisí na správném sladění datového modelu s přístupovými vzory, na promyšleném particionování a volbě konzistenčního profilu. Dokumentové databáze excelují v práci s agregáty a bohatými dotazy, klíč–hodnota doručuje extrémní výkon pro jednoduché operace a grafové databáze umožňují přirozené modelování a rychlé dotazy nad vztahy. V praxi se často uplatňuje polyglot persistence, kde každá technologie řeší tu část problému, pro kterou je navržena. Důraz na observabilitu, správu indexů a testování škálování je klíčem k dlouhodobě udržitelnému provozu.