Typy databází NoSQL: dokumentové, klíč–hodnota a grafové modely

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 flexibilní schéma. Zatímco relační databáze (SQL) kladou důraz na pevná schémata a silnou konzistenci, NoSQL nabízí alternativní datové modely 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.

Teorie CAP a typické profily konzistence

• CAP: V prostředí, kde může dojít k rozdělení sítě, nelze současně maximalizovat konzistenci (C) i dostupnost (A). Systémy volí mezi CP (upřednostňují konzistenci) a AP (upřednostňují dostupnost) podle oblasti použití.
• Konzistence: silná (linearizovatelná), eventualní, kauzální; některé systémy umožňují zvolit úroveň čtení/zápisu pro každou operaci.
• ACID vs. BASE: NoSQL často nabízí lokální ACID (na úrovni dokumentu/klíče/partice) a BASE (eventual consistency) napříč clusterem. Mnohé platformy již podporují také vícedokumentové transakce s určitými 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 operace napříč entitami.
• Přístupové vzory > schéma: Návrh tabulek/kolekcí/klíčů vychází z dotazů a SLA (latence, propustnost), nikoli z ER diagramu.
• Particionování: Volba distribučního klíče je zásadní pro rovnoměrné rozložení zátěže a minimalizaci přetížených uzlů.

Dokumentové databáze: definice a charakteristiky

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

• Datový model: hierarchický (objekty, pole, vnořené struktury), s možností používat v jedné kolekci různá schémata.
• Dotazy: pokročilé dotazovací jazyky (filtry, projekce, agregace, pipelines); geolokační a textové vyhledávání, sekundární indexy.
• Transakce: operace nad jedním dokumentem jsou obvykle atomické; moderní systémy často podporují vícedokumentové transakce v rámci jedné partice/šardu.
• Škálování: horizontální (sharding) podle klíče (např. userId, tenantId); replikace s automatickým přepnutím při výpadku.
• Případy použití: systémy pro správu obsahu, katalogy, e-commerce košíky a objednávky, protokoly událostí s pokročilým dotazováním, mobilní a 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: složené (např. status, createdAt), TTL indexy pro data s omezenou životností, textové/geolokační indexy.
• Agregace: pipeline (match → group → sort → project) pro analytiku nad provozními daty.

Typická volba technologií pro dokumentové databáze

• Silné stránky: flexibilní schéma, pokročilé dotazování a indexace, dobrý kompromis mezi OLTP a jednodušší analýzou.
• Limity: nákladnější spojování dokumentů, nutnost pečlivě zvolit shard klíč, omezení velikosti dokumentů a atomických operací.

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

Databáze klíč–hodnota ukládají nestrukturované nebo binární hodnoty, k nimž se přistupuje prostřednictvím jedinečného klíče. Důraz kladou 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ě vyhledávání podle prefixu či v intervalu u některých systémů.
• Datové struktury: uložené v paměti (s perzistencí do protokolu/snímku) nebo na disku s LSM-tree; některé systémy podporují struktury jako hash, list, set a sorted set.
• Škálování: horizontální pomocí konzistentního hashování; velmi vysoká propustnost (miliony požadavků za sekundu) při nízké latenci.
• Případy použití: cache, úložiště relací, omezování rychlosti požadavků, fronty, žebříčky, příznaky funkcí, rychlé vyhledávání pro mikroslužby.

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

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: cache write-through/write-behind, cache-aside, distributed locks (s vědomím jejich omezení), počítadla, pub/sub.
• Limity: složitější dotazy vyžadují sekundární indexaci (externí) nebo jiný systém; správa TTL a vytěsňování položek je klíčová pro předvídatelné chování.

Grafové databáze: definice a charakteristiky

Grafové databáze reprezentují data jako uzly (vrcholy) a hrany s vlastnostmi. Optimalizují procházení vztahů a dotazy, u nichž jsou struktura a hloubka propojení zásadní.

• Model: property graph (uzly/hrany s vlastnostmi klíč–hodnota) nebo RDF (trojice subjekt–predikát–objekt).
• Dotazovací jazyky: Gremlin, Cypher, GQL (sjednocující standard), SPARQL (pro RDF).
• Indexy: indexy vlastností uzlů/hran; klíčová je reprezentace pomocí seznamu sousedů pro rychlé přechody mezi vrcholy.
• Škálování: složité; dělení grafu na shardy je obtížné (edge-cut vs. vertex-cut). U rozsáhlých grafů se volí dotazy zohledňující rozdělení na oddíly (partition-aware) a replikace podgrafů.
• Případy použití: doporučování (přátelé přátel), znalostní grafy, odhalování podvodů (spoluúčast), síťové/IT topologie, kmenová data se silnými vzájemnými vztahy.

Příklad dotazu v grafové databázi (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ý zápis vícestupňových vztahů a vzorů.
• Limity: náročnější horizontální škálování a složitější agregace než u sloupcových analytických systémů.

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

Konzistence a transakce napříč typy

• Dokumentové: atomické operace na úrovni dokumentu; vícedokumentové transakce často s omezeními (např. v rámci kolekce/šardu).
• Klíč–hodnota: linearizovatelnost na úrovni klíče; transakce napříč klíči obvykle nejsou podporovány nebo jsou nákladné.
• Grafové: ACID v rámci jedné instance/repliky; v distribuovaném grafu je obtížné zachovat globální serializaci.

Indexace, optimalizace dotazů a výkon

• Dokumentové: B-stromy, hash, text, geo; dotazy pokryté indexem, agregace nad statistikami uloženými po sloupcích (u některých systémů).
• Klíč–hodnota: primárním indexem je klíč; sekundární indexy zajišťuje aplikace nebo doprovodné služby.
• Grafové: indexy pro výchozí uzly; následný výkon závisí na hustotě hran a selektivitě vzoru.

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

• Replikace: architektura leader–followers s automatickým přepnutím při výpadku, případně více leaderů pro geograficky distribuované nasazení; grafové databáze někdy replikují podgrafy pro rychlé lokální čtení.
• Sharding: u dokumentových databází a databází klíč–hodnota je přirozený; u grafových je náročný (minimalizace rozdělení hran, využití detekce komunit pro dělení na oddíly).

Bezpečnost a správa

• Autentizace/autorizace: RBAC, šifrování při přenosu (TLS) i v klidu (TDE), audit přístupů.
• Víceklientský provoz: oddělení klientů pomocí schémat/namespace, limity prostředků, kvóty, omezení rychlosti požadavků.
• Životní cyklus dat: TTL/archivace, retenční zásady pro protokoly/události.

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é řady, subset pattern pro často používaná pole.
• Klíč–hodnota: složené klíče (prefix + ID), klíče rozdělené do časových intervalů, idempotentní zápisy pro opakované pokusy, distribuovaná počítadla s dělením na shardy.
• Grafové: modelování typů uzlů a hran (štítky), směrování hran, vlastnosti s indexy, denormalizace odvozených vztahů pro časté dotazy.

Antivzory a časté chyby

• Dokumentové: přerostlé dokumenty (megadokumenty), přetížený shard klíč (např. monotónní časové razítko), bezhlavé používání transakcí napříč shardy.
• Klíč–hodnota: používání databáze klíč–hodnota pro ad hoc dotazy (bez indexů), nekontrolované TTL a vytěsňování položek, spoléhání na distribuované zámky bez pochopení způsobů selhání.
• Grafové: dotazy s velkým rozsahem expanze bez omezení hloubky či selektivity, náhodné dělení grafu bez ohledu na strukturu komunit.

Volba technologie podle případu použití

• Rychlé vyhledávání a cache → databáze klíč–hodnota (uložená v paměti s perzistencí).
• Provozní data s pokročilým dotazováním → dokumentová databáze.
• Komplexní vztahy a cesty → grafová databáze.
• Hybridní přístup: kombinace technologií (polyglot persistence): např. Kafka + databáze klíč–hodnota pro rychle dostupné stavy, dokumentová databáze pro agregáty, grafová databáze pro doporučování.

Provozní aspekty: monitoring, zálohování, migrace

• Monitoring: latence p50/p95/p99, propustnost, velikost a fragmentace indexů, zpoždění replikace, GC/heap u systémů JVM.
• Zálohování/obnova: snímky na úrovni úložiště, obnova k určitému okamžiku (pokud je podporována), testy obnovy (cvičení pro zotavení po havárii).
• Migrace schémat: v dokumentových databázích přístup schema-on-read, postupná migrace dokumentů při přístupu; u grafových databází postupná migrace částí grafu.

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

Úspěch nasazení NoSQL závisí na správném sladění datového modelu s přístupovými vzory, promyšleném particionování a volbě profilu konzistence. Dokumentové databáze vynikají při práci s agregáty a pokročilými dotazy, databáze klíč–hodnota poskytují extrémní výkon při jednoduchých operacích a grafové databáze umožňují přirozené modelování vztahů a rychlé dotazy nad nimi. V praxi se často uplatňuje polyglot persistence, kdy 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.