Abstrakt NoSQL databáze představují odklon od univerzálního přístupu relačních systémů ke specializovaným úložištím optimalizovaným pro konkrétní třídy úloh. Článek shrnuje hlavní rodiny NoSQL databází – dokumentové, klíč-hodnota, sloupcové a grafové – jejich teoretické základy včetně CAP a PACELC teorémů, typické scénáře nasazení i provozní úskalí. Text je určen technickým ředitelům a architektům, kteří zvažují polyglotní persistenci v podnikovém prostředí.
1. Proč vznikly NoSQL systémy
Relační databáze dominují čtyři dekády díky ACID vlastnostem a matematicky precizní algebře. Web, mobilní aplikace a IoT však přinesly požadavky, které se s monolitickým modelem RDBMS těžko slučují: horizontální škálování přes komoditní hardware, flexibilní schéma pro rychlou iteraci produktu, dostupnost na úrovni 99,99 % a globální distribuce s nízkou latencí.
Typický monolitický RDBMS narazí na strop kolem 10 až 20 tisíc zápisů za sekundu na jeden uzel. Moderní e-commerce platforma v období Black Friday vyžaduje řádově půl milionu čtení a 50 tisíc zápisů za sekundu. Replikační zpoždění mezi master a slave uzly v rozmezí 100 až 500 ms zvyšuje aplikační složitost a nutí vývojáře řešit nekonzistence ručně.
NoSQL přístup tento problém neřeší zázračnou škálovatelností, ale výměnou některých záruk – typicky striktní konzistence – za propustnost a dostupnost.
2. Teoretické základy: CAP a PACELC
CAP teorém Erica Brewera říká, že distribuovaný systém nemůže současně garantovat konzistenci (C), dostupnost (A) a odolnost vůči rozdělení sítě (P). Při výpadku síťového spojení se musí volit mezi C a A. Většina relačních systémů upřednostňuje konzistenci, zatímco klasické NoSQL databáze typu Cassandra nebo DynamoDB volí dostupnost.
PACELC teorém Daniela Abadiho rozšiřuje úvahu o stav bez výpadku: i tehdy systém volí mezi latencí (L) a konzistencí (C). MongoDB v defaultní konfiguraci preferuje konzistenci za cenu vyšší latence; Cassandra naopak nabízí ladění úrovně konzistence per dotaz pomocí parametrů ONE, QUORUM a ALL.
Pro architektonické rozhodování platí jednoduché pravidlo: definujte si SLA pro latenci a maximální tolerovanou nekonzistenci dříve, než vyberete technologii. Bez těchto čísel je výběr databáze marketingová úloha, nikoli inženýrská.
3. Dokumentové databáze
Dokumentové systémy ukládají data ve formátu JSON nebo BSON. Reprezentanti: MongoDB, Couchbase, Amazon DocumentDB. Vhodné pro katalogy s proměnlivými atributy, obsahové platformy, profilové stránky a uživatelská nastavení.
Hlavní výhodou je flexibilní schéma: nový atribut produktu se přidá bez ALTER TABLE. Indexace funguje na vnořených polích, což umožňuje efektivní dotazy přes embedded struktury. MongoDB od verze 5.0 podporuje multi-document ACID transakce, čímž stírá historický rozdíl oproti RDBMS pro řadu use cases.
Anti-pattern: ukládání silně relačních dat. Pokud aplikace dělá více než dvě úrovně manuálních „joinů“ na straně klienta, je to signál, že doménový model patří do relační databáze. Druhý častý problém je neomezený růst polí v dokumentu – limit 16 MB na dokument v MongoDB se v reálu vyčerpá rychleji, než se očekává.
V produkci doporučujeme použít replica set se třemi uzly, automatický failover a sharding podle hash klíče s rovnoměrnou distribucí. Pro analytické dotazy používejte read preference secondary nebo dedikovanou analytickou repliku.
4. Key-value úložiště
Key-value databáze nabízejí nejjednodušší datový model: klíč mapuje na neprůhlednou hodnotu. Reprezentanti: Redis, Amazon DynamoDB, Aerospike. Typické nasazení: cache, session store, fronty, distributed locks, leaderboards a feature flags.
Redis v in-memory režimu doručuje sub-milisekundovou latenci a milion operací za sekundu na jednom uzlu. Pro perzistenci nabízí RDB snapshoty, AOF log nebo jejich kombinaci. Redis Cluster zajišťuje horizontální škálování přes hash sloty.
DynamoDB jako spravovaná služba AWS poskytuje předvídatelnou latenci pod 10 ms, automatické škálování propustnosti a globální tabulky s multi-region replikací. Cenový model on-demand je vhodný pro nepředvídatelnou zátěž; provisioned capacity s auto-scalingem se vyplatí u stabilních workloadů.
Klíčové úskalí: návrh klíče determinuje výkon i náklady. Hot partition – nadměrná zátěž jednoho klíče – degraduje propustnost celého shardu. Řešením je composite key, write sharding s náhodným sufixem nebo aplikační cache před databází.
5. Sloupcové databáze
Wide-column systémy jako Apache Cassandra, ScyllaDB nebo HBase organizují data do tabulek s dynamickými sloupci optimalizovaných pro zápisově náročné úlohy. Architektura masterless ringu s konzistentním hashingem umožňuje lineární škálování přidáváním uzlů a toleranci výpadků bez SPOF.
Cassandra excelujev time-series datech, IoT telemetrii a audit logech. Propustnost přesahuje 100 tisíc zápisů za sekundu na uzel. Cena za výkon je rigidní datový model – schéma musí kopírovat přístupový vzor. Změna primárního klíče po nasazení znamená migraci dat.
Vyhněte se Cassandře pro malé objemy dat (do desítek GB), pro silně transakční scénáře a pro dotazy ad-hoc. Operační složitost vyžaduje tým s expertízou v ladění JVM, garbage collectoru a kompakčních strategií.
6. Grafové databáze
Grafové systémy jako Neo4j, Amazon Neptune nebo TigerGraph modelují data jako uzly a hrany s atributy. Doménami nasazení jsou sociální sítě, doporučovací enginy, fraud detection, knowledge graphs a network impact analysis.
Síla grafu spočívá v rychlosti procházení relací. Dotaz „najdi všechny zákazníky v okruhu tří hran od podezřelé transakce“ je v Cypheru triviální a vykoná se v desítkách milisekund i nad miliardami hran. Stejný dotaz v relační databázi vyžaduje rekurzivní CTE nebo aplikační iteraci s katastrofálním výkonem.
Grafové databáze nejsou náhradou primárního úložiště. Typický pattern je provozovat je jako sekundární systém synchronizovaný z OLTP databáze přes change data capture. Plnotextové vyhledávání ani agregace nad miliardami záznamů nejsou jejich silnou stránkou.
7. Polyglot persistence v praxi
Žádný NoSQL systém neřeší všechny úlohy. Reálná architektura kombinuje několik specializovaných úložišť: PostgreSQL pro transakční jádro, Redis pro cache a session, Elasticsearch pro fulltext, Cassandra pro telemetrii, Neo4j pro doporučení. Náklady na provoz a integraci rostou, ale celkové TCO klesá oproti pokusu o monolitické řešení.
Klíčové komponenty pro polyglot architekturu:
- Change data capture (Debezium, Kafka Connect) pro propagaci změn mezi systémy
- API gateway abstrahující backendovou heterogenitu před klienty
- Centralizovaný observability stack – metriky, distribuované tracing, log agregace
- Schema registry pro evolution datových kontraktů mezi službami
8. Provozní zralost a migrace
Nasazení NoSQL systému do produkce není instalace, ale program. Doporučená sekvence: proof of concept na izolovaném use case, zátěžové testy s reálnými objemy a vzorci, definice runbook pro typické incidenty, nastavení backup a restore postupu, validace disaster recovery, teprve poté migrace produkce.
Migrace z RDBMS probíhá zpravidla ve čtyřech fázích: dual-write s rekonsiliací, postupné přesměrování čtení, validace shody dat, vyřazení původního zdroje. Plná migrace zahrnuje kromě dat i aplikační kód, monitoring, alerting a školení provozního týmu. Plánujte šest až dvanáct měsíců pro kritické systémy.
9. Závěr
NoSQL nepředstavuje univerzální alternativu k relačním databázím, ale nástroj pro úlohy, na které RDBMS není stavěné. Volba mezi dokumentem, klíč-hodnotou, sloupcem a grafem se odvíjí od přístupového vzoru, požadavků na konzistenci a očekávaného objemu dat. Polyglotní persistence dnes patří k profesionálnímu standardu architektury distribuovaných systémů; klíčem k úspěchu je inženýrská kázeň při definici SLA a měření, nikoli volba konkrétního produktu.
Reference
- Brewer, E. (2000): Towards Robust Distributed Systems. PODC
- Abadi, D. (2012): Consistency Tradeoffs in Modern Distributed Database System Design. IEEE Computer
- Sadalage, P. & Fowler, M. (2012): NoSQL Distilled. Addison-Wesley
- Kleppmann, M. (2017): Designing Data-Intensive Applications. O'Reilly
- DB-Engines Ranking: https://db-engines.com/en/ranking
