Proč NoSQL a kdy je použít
MongoDB, Apache Cassandra a Redis patří mezi nejrozšířenější NoSQL databáze, které překonávají limity tradičních relačních systémů při zpracování velkých objemů dat, vysoké propustnosti a proměnlivých schémat. Každý nástroj reprezentuje odlišný datový model a škálovací filozofii: MongoDB jako document store, Cassandra jako wide-column store s důrazem na horizontální škálování a vysokou dostupnost, a Redis jako in-memory key-value engine s bohatými datovými strukturami pro extrémně nízkou latenci. Výběr závisí na prioritách v rámci tzv. CAP trojúhelníku (konzistence, dostupnost, odolnost vůči výpadkům sítě), na přístupu k datovému modelování, SLA i provozních omezeních.
Datové modely a schémata
- MongoDB (Document): JSON-like dokumenty (BSON) s flexibilním schématem. Vhodné pro hierarchická data, vložené poddokumenty a rychlou evoluci schémat bez rozsáhlých migrací.
- Cassandra (Wide-column): tabulky s partition key a clustering columns. Datový model reflektuje přístup „modeluj podle dotazů“ – denormalizace a materializace dat přizpůsobená čtecím vzorům.
- Redis (In-memory key–value): klíče a různé typy hodnot (řetězce, seznamy, množiny, seřazené množiny, haše, proudy, bitmapy, hyperloglogy). Od verze Redis 6+ umožňuje per-key moduly a rozšířené datové typy (RedisJSON, RedisSearch, RedisGraph – dnes Redis Stack).
Dotazovací jazyky a API
- MongoDB: bohaté dotazovací DSL (find/aggregate pipeline), sekundární indexy, textové a geoprostorové dotazy, transakce přes více dokumentů a ACID konzistence v rámci kolekcí a replikových sad.
- Cassandra: CQL (Cassandra Query Language) podobný SQL, avšak bez joinů a ad-hoc agregací napříč partition. Klade důraz na pevně definované primární klíče a pořadí clustering sloupců.
- Redis: příkazové API specifické pro datový typ (GET/SET, HGETALL, ZRANGE, XREAD/XADD a další). Redis Stack přidává full-textové vyhledávání a JSON dotazy.
Indexace a vyhledávání
- MongoDB: indexy na jedno pole, složené, multikey (pole), TTL, partial a sparse indexy; podpora covered queries a hint. S Atlas Search (postaveným na Lucene) nabízí i pokročilé full-textové, geografické a sémantické dotazy.
- Cassandra: primárně spoléhá na primární klíč a pořadí clustering sloupců. Sekundární indexy jsou omezené a využitelné zejména při nízké kardinalitě. Pro full-textové vyhledávání a analytiku se často integruje Elastic, Trino nebo Spark.
- Redis: základní operace mají složitost O(1) nebo O(log n) v závislosti na typu. RedisSearch (součást Redis Stack) přidává invertované indexy, full-textové vyhledávání a agregace.
Transakce, konzistence a CAP
- MongoDB: v replikové sadě výchozí nastavení readConcern a writeConcern s možností majority. Podpora multi-dokumentových transakcí (ACID), vhodné pro OLTP-like scénáře.
- Cassandra: orientace na AP (dostupnost a partition tolerance). Tunable consistency (ONE, QUORUM, ALL atd.) pro čtení i zápis. Transakce přes partition nejsou podporované, místo toho jsou k dispozici lightweight transactions (CAS) s Paxos overheadem pro podmíněné zápisy.
- Redis: atomicita operací na úrovni jednotlivých příkazů; transakce (MULTI/EXEC) bez izolace mezi klienty; LUA skripty pro atomické kombinace příkazů. Redis Cluster používá asynchronní replikaci, což znamená eventual konzistenci mezi shardovanými uzly.
Škálování, sharding a replikace
- MongoDB: replica set (primární + sekundární uzly) pro vysokou dostupnost; horizontální škálování prostřednictvím sharded clusteru (shard key, balancer, range nebo hash sharding). Čtecí operace lze směrovat na sekundární uzly s nastavitelnou konzistencí.
- Cassandra: masterless architektura, peer-to-peer s konzistentním hashováním a bez jediného bodu selhání. Škálování přidáním uzlů s automatickým přeskládáním replik v rámci keyspace definovaným pomocí replication factor.
- Redis: Redis Cluster využívá hash sloty pro horizontální škálování a repliky pro vysokou dostupnost. Pro maximální odolnost a perzistenci se kombinuje s AOF/RDB a Sentinel pro failover.
Perzistence, odolnost a zotavení
- MongoDB: journaling, write-ahead logging, bodové zálohy (oplog), change streams pro Change Data Capture. Silná perzistence na disk.
- Cassandra: commit log + SSTables (LSM-tree), zápis do paměťové tabulky (memtable flush), kompakce dat. Přirozená odolnost vůči výpadkům uzlů; nastavitelná konzistence minimalizuje ztrátu dat (RPO).
- Redis: primárně in-memory; perzistence volitelně realizována RDB snapshoty a AOF (append-only file) s různými režimy fsync. Při požadavcích na přísně nízké RPO a RTO je nezbytná pečlivá konfigurace a replikace.
Latence a propustnost: výkonové profily
- Redis: submilisekundové latence a miliony operací za sekundu při in-memory přístupu; ideální pro cache, uchování session, realtime pořadníky, publish/subscribe a proudy (Streams).
- MongoDB: nízké až střední latence s rozsáhlou funkcionalitou dotazů; vhodné pro API backendy, katalogy, uživatelské profily, event storage s agregacemi.
- Cassandra: stabilní latence i pod zátěží a lineární škálování pro masivní zápisy a čtení se strukturovanými přístupovými vzory (telemetrie, časové řady, IoT).
Typické případy použití
- MongoDB: mikroservisní aplikace, obsahové systémy, mobilní backendy, geolokační aplikace, event sourcing s change streams, rychlá iterace schématu.
- Cassandra: logování a metriky v petabytové škále, časové řady, messaging s nízkým RTO, retail clickstream s požadavkem na vysokou dostupnost v multi-regionálním nasazení.
- Redis: caching vrstvy, rate limiting, fronty a žebříčky (leaderboards), realtime notifikace, feature flags, full-text a JSON (Redis Stack) při potřebě extrémně nízké latence.
Modelování dat: principy a anti-patterny
- MongoDB: vkládat versus referencovat – malé, často čtené podstruktury embedovat, rozsáhlé a sdílené entity referencovat. Vyhnout se nekontrolovanému růstu dokumentu (document growth) a neefektivním nespočitatelným polím (unbounded arrays).
- Cassandra: nejdříve definujte dotazy, až poté navrhujte tabulky. Vyvarujte se „horkých“ partition (skew) – používejte složené klíče a bucketing podle času.
- Redis: volba datového typu podle požadovaných operací (počítadla → INCR, pořadníky → ZSET, dokumenty → JSON). Nastavujte TTL a eviction policy; vyhněte se příliš velkým hodnotám (big values) bez segmentace.
Transakční požadavky a konzistence v praxi
Pokud je vyžadována silná ACID konzistence a transakce přes více entit, vychází lépe MongoDB (nebo zvážit relační databáze). Cassandra řeší konzistenci per-request použitím kvór a je vhodná tam, kde mírná eventualita nevadí. Redis poskytuje atomickou sekvenci operací (skripty/transakce) v rámci jednoho uzlu; v clusteru je třeba brát v potaz omezení key-slot a cross-slot operace.
Observabilita, provoz a údržba
- MongoDB: profiler, explain plány, FTDC telemetrie; monitorování oplog lag, zablokování, velikosti working setu a indexů.
- Cassandra: nodetool, JMX metriky, chování kompakcí/GC, latence čtení a zápisu, stav replikace; pečlivé ladění kompakcí (STCS/LCS/TWCS) a velikosti memtable.
- Redis: INFO metriky, latency monitor, slowlog, stav sentinel/clusteru; sledování paměti, fragmentace, I/O RDB/AOF a lag replikace.
Bezpečnost a governance
- Autentizace/Autorizace: všechny tři podporují ACL; MongoDB nabízí role-based přístup, Cassandra role management, Redis ACL na úrovni příkazů a vzorů klíčů.
- Šifrování: TLS pro přenos dat; šifrování dat na disku (TDE/dm-crypt) dle distribuce; správa klíčů přes cloudové KMS.
- Audit: MongoDB disponuje detailními audit logy; u Cassandry a Redis se často využívá externí centralizace (SIEM) přes export metrik a logů.
Cloudové služby a ekosystém
- MongoDB Atlas: spravovaný multi-cloud, serverless režim, Atlas Search, Triggers, Data Federation, konektory na BI a ETL nástroje.
- Managed Cassandra: DataStax Astra, Amazon Keyspaces (CQL), Azure Managed Instance pro Cassandru; integrace s Spark a Trino.
- Redis (Managed): Redis Enterprise Cloud, Amazon ElastiCache / MemoryDB, Azure Cache for Redis; Redis Stack pro JSON a full-textové vyhledávání.
Výkon a náklady: provozní strategie
- MongoDB: optimalizujte indexy, covered queries, kompresi a využití GridFS pro uložení velkých souborů jen podle potřeby. Sledujte náklady na I/O a úložiště v cloudu.
- Cassandra: lineární škálování přidáváním uzlů; náklady převládají v počtu strojů a I/O. Klíčová je správná velikost SSTable, kompakce a ladění JVM GC.
- Redis: paměť je nákladná – využívejte kompresi (zejména u JSON), expiraci, LFU/LRU politiku a oddělení „hot“ a „warm“ dat (tiering na diskové vrstvy, pokud je to možné).
Migrace a polyglot persistence
Často je vhodný polyglot přístup: Redis jako cache a messaging vrstva, MongoDB jako primární úložiště aplikačních dat a Cassandra pro time-series a eventy ve velkém měřítku. Při migracích definujte kontrakty schémat, realizujte dual-write a change data capture a validujte konzistenci na vzorcích dat. Zohledněte bezstavovost přehrávání (idempotentní replay) a doplňování starších dat (backfill).
Testování, benchmarking a SLO
- Simulujte reálné zatížení: kombinaci čtení a zápisů, rozložení klíčů, velikost dokumentů/řádků a „hotspoty“.
- Měřte latence p50/p95/p99 a jejich variabilitu; sledujte vliv GC pauz (Cassandra), page-faultů (MongoDB) a AOF fsync (Redis).
- Definujte SLO: latence, propustnost, RPO/RTO a dostupnost; nastavte alerty a pravidla pro autoscaling.
Rozhodovací matice: rychlý výběr podle kritérií
- Potřeba rozsáhlých dotazů a flexibilního schématu → MongoDB.
- Masivní škálovatelnost napříč datovými centry s vysokou dostupností → Cassandra.
- Extrémně nízká latence (sub-ms), caching, fronty, realtime analytika → Redis (Redis Stack pro JSON/Search).
- Silné ACID transakce přes více entit → spíše MongoDB (nebo relační databáze).
- Jednoduché operace nad klíči a datovými strukturami → Redis.
Časté chyby a doporučení
- MongoDB: nevhodný výběr shard key, nadměrné používání $lookup místo dobře promyšleného datového modelu, nekontrolované a příliš velké pole.
- Cassandra: špatně zvolený partition key vedoucí k nevyváženému clusteru, nevhodná kompakce způsobující zvýšenou latenci a zatížení disku.
