Proč NoSQL a kdy po nich sáhnout
MongoDB, Apache Cassandra a Redis patří mezi nejrozšířenější NoSQL databáze, které řeší omezení klasických relačních systémů při práci s velkým objemem dat, vysokou propustností a proměnlivými schématy. Každý nástroj představuje odlišný datový model a škálovací filozofii: MongoDB jako document store, Cassandra jako wide-column store kladoucí důraz na horizontální škálování a dostupnost, a Redis jako in-memory key–value engine s bohatými datovými strukturami pro extrémně nízké latence. Výběr závisí na prioritách v tzv. CAP trojúhelníku (konzistence, dostupnost, odolnost vůči particím), 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, vnořené subdokumenty 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 pro čtecí vzory.
- Redis (In-memory key–value): klíče a různé typy hodnot (strings, lists, sets, sorted sets, hashes, streams, bitmaps, hyperloglog). Od verze Redis 6+ per-key modules a datatype rozšiřují možnosti (RedisJSON, RedisSearch, RedisGraph – dnes Redis Stack).
Dotazovací jazyky a API
- MongoDB: bohatá dotazovací DSL (find/aggregate pipeline), sekundární indexy, textové a geospatial dotazy, transakce přes více dokumentů a ACID v rámci kolekcí a replikových sad.
- Cassandra: CQL (Cassandra Query Language), který připomíná SQL, ale bez joins a ad-hoc agregací napříč partition. Důraz na předem navržené primární klíče a pořadí clustering sloupců.
- Redis: příkazové API pro jednotlivé datové typy (GET/SET, HGETALL, ZRANGE, XREAD/XADD…) Redis Stack přidává full-text vyhledávání a JSON dotazy.
Indexace a vyhledávání
- MongoDB: single field, compound, multikey (pole), TTL, partial a sparse indexy; podpora covered queries a hint. S Atlas Search (Lucene) také komplexní full-text/geo/semantic dotazy.
- Cassandra: primárně spoléhá na primary key a pořadí clustering sloupců. Sekundární indexy jsou omezené (vhodné pro nízkou kardinální hodnotu). Pro full-text/analytics se často integruje Elastic/Trino/Spark.
- Redis: základní operace mají složitost O(1)/O(log n) podle typu; RedisSearch (v Redis Stack) přináší invertované indexy, full-text a agregace.
Transakce, konzistence a CAP
- MongoDB: v replikové sadě výchozí readConcern/writeConcern s možností majority. Podpora multi-dokumentových transakcí (ACID) – vhodné pro OLTP-like scénáře.
- Cassandra: orientace na AP (dostupnost + partition tolerance). Tunable consistency (ONE, QUORUM, ALL…) pro čtení i zápis. Transakce napříč partition neexistují, lightweight transactions (CAS) pro podmíněné zápisy s režijním nákladem Paxos protokolu.
- Redis: atomická provedení per příkaz; transakce (MULTI/EXEC) bez izolace mezi klienty; LUA skripty umožňují atomické kompozity. Redis Cluster má asynchronní replikaci (eventual consistency mezi shardů).
Škálování, sharding a replikace
- MongoDB: replica set (primary + secondaries) pro vysokou dostupnost; horizontální škálování pomocí sharded clusteru (shard key, balancer, range/hash sharding). Čtení lze směrovat na sekundární uzly s příslušnou konzistencí.
- Cassandra: masterless architektura, peer-to-peer s konzistentním hashováním, bez jediného bodu selhání. Snadné scale-out přidáním uzlů, automatické přerozdělení replik v keyspace s definovaným replication factor.
- Redis: Redis Cluster (hash sloty) pro horizontální škálování, replicas pro vysokou dostupnost. Pro velmi vysokou odolnost a perzistenci se kombinuje s AOF/RDB a Sentinel pro failover.
Perzistence, odolnost a zotavení
- MongoDB: journaling, write-ahead logging, point-in-time zálohy (oplog), change streams pro CDC. Silná perzistence na disk.
- Cassandra: commit log + SSTables (LSM-tree), memtable flush, kompakce. Přirozeně odolná proti výpadkům uzlů; tunable consistency minimalizuje RPO.
- Redis: primárně in-memory; perzistence volitelně přes RDB snapshoty a AOF (append-only log) s různými politikami fsync. Při přísných RPO/RTO je třeba pečlivá konfigurace a replikace.
Latence a propustnost: výkonové profily
- Redis: submilisekundové latence a miliony RPS při in-memory přístupu; ideální pro cache, session store, realtime žebříčky, pub/sub a proudy (Streams).
- MongoDB: nízké až střední latence s bohatou funkcionalitou dotazů; vhodné pro API back-endy, katalogy, profily uživatelů, event storage s agregacemi.
- Cassandra: stabilní latence pod zátěží a lineární škálování pro masivní zápisy/čtení s předvídatelným přístupovým vzorem (telemetrie, time-series, IoT).
Typické use-casy
- MongoDB: mikroservisní aplikace, obsahové systémy, mobilní backendy, geolokace, event sourcing s change streams, rychlá iterace schématu.
- Cassandra: logování a metriky v petabytovém měřítku, časové řady, messaging s nízkým RTO, retail clickstream s požadavkem na dostupnost v multi-regionu.
- Redis: caching vrstvy, rate limiting, fronty a leaderboards, realtime notifikace, feature flags, full-text a JSON (Redis Stack) při potřebě nízké latence.
Modelování dat: principy a anti-patterny
- MongoDB: embeddovat vs. referencovat – malé, často čtené podstruktury embed, velké a sdílené entity referencovat. Vyhnout se nekontrolovanému růstu dokumentu (document growth) a neefektivním unbounded arrays.
- Cassandra: nejprve specifikujte dotazy, až poté tabulky. Vyhýbejte se „horkým“ partition (skew) – volte kompozitní klíče a bucketing podle času.
- Redis: volba datového typu dle operací (počítadla → INCR, pořadníky → ZSET, dokumenty → JSON). Nastavujte TTL a eviction policy; vyhněte se příliš velkým klíčům (big values) bez chunkování.
Transakční požadavky a konzistence v praxi
Pokud je nutná silná ACID konzistence a víceentitní transakce, je vhodnější MongoDB (resp. zvážit relační databáze). Cassandra řeší konzistenci per-request pomocí kvór a je vhodná tam, kde mírná eventualita není problémem. Redis poskytne atomickou sekvenci operací (skripty/transakce) v rámci jednoho uzlu; v clusteru je třeba brát v úvahu omezení key-slot a cross-slot operace.
Observabilita, provoz a údržba
- MongoDB: profiler, explain plans, FTDC telemetrie; monitorujte oplog lag, blokace, velikost working setů a indexů.
- Cassandra: nodetool, JMX metriky, chování compaction/GC, latence čtení/zápisu, stav replikace; ladit kompakce (STCS/LCS/TWCS) a velikost memtable.
- Redis: INFO metriky, latency monitor, slowlog, Sentinel/cluster stav; sledovat paměť, fragmentaci, RDB/AOF IO a lag replikace.
Bezpečnost a governance
- Autentizace/Autorizace: všechny tři podporují ACL; MongoDB role-based, Cassandra role management, Redis ACL pro jednotlivé příkazy a klíčové vzory.
- Šifrování: TLS v tranzitu; šifrování na disku (TDE/dm-crypt) podle distribuce; správa klíčů přes KMS v cloudu.
- Audit: MongoDB nabízí detailní auditní logy; u Cassandry a Redisu se často používá externí centralizace (SIEM) prostřednictvím exportu metrik a logů.
Cloudové služby a ekosystém
- MongoDB Atlas: spravovaný multi-cloud, serverless, Atlas Search, Triggers, Data Federation, konektory na BI/ETL.
- Managed Cassandra: DataStax Astra, Amazon Keyspaces (CQL), Azure Managed Instance pro Cassandru; integrace se Spark/Trino.
- Redis (Managed): Redis Enterprise Cloud, Amazon ElastiCache / MemoryDB, Azure Cache for Redis; Redis Stack pro JSON/Search.
Výkon a náklady: provozní strategie
- MongoDB: optimalizujte indexy, covered queries, kompresi a ukládání velkých souborů přes GridFS jen pokud je nezbytné. Sledujte náklady na IO/storage v cloudu.
- Cassandra: lineární škálování přidáním uzlů; náklady dominují v počtu strojů a IO. Důležitá je správná velikost SSTable, ladění kompakce a JVM GC.
- Redis: paměť je nákladná – využívejte kompresi (zejména u JSON), expirace, LFU/LRU a rozdělení „hot“/„warm“ dat (tiering na diskové vrstvy, pokud produkt umožňuje).
Migrace a polyglot persistence
Často je efektivní polyglotní přístup: Redis jako cache a messaging, MongoDB jako primární úložiště aplikačních dat a Cassandra pro time-series/eventy ve velkém měřítku. Při migracích definujte kontrakty schémat, dual-write/change data capture a ověřujte konzistenci vzorkováním. Zohledněte idempotentní přehrávání a backfill historických dat.
Testování, benchmarking a SLO
- Simulujte reálné workloady: kombinace čtení/zápisů, rozložení klíčů, velikost dokumentů/řádků a hotspoty.
- Měřte p50/p95/p99 latence a variabilitu; sledujte GC pauzy (Cassandra), page-faulty (MongoDB) a fsync AOF (Redis).
- Definujte SLO: latence, throughput, RPO/RTO a dostupnost; nastavte alerting a pravidla pro autoscaling.
Rozhodovací matice: rychlý výběr podle kritérií
- Potřeba bohatých dotazů a flexibilního schématu → MongoDB.
- Masivní škála 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í DB).
- Jednoduché operace nad klíči a datovými strukturami → Redis.
Časté chyby a doporučení
- MongoDB: nedostatečně promyšlený shard key, nadužívání $lookup místo správného modelu, neomezeně rostoucí pole.
- Cassandra: nevhodně zvolený partition key → nevyvážené clustery; nevhodné kompakce → zvýšené latence a tlak na disk.
- Redis: chybějící expirace, přetížení jednoho uzlu, nepochopení eviction policy a perzistence.
Kontrolní seznam při návrhu NoSQL řešení
- Výběr databáze podle převažujících dotazů a SLO (latence, propustnost, dostupnost).
- Datový model navržený podle dotazů a vzorů přístupu; validace na reálných scénářích.
- Strategie škálování (replication factor, shard key, topologie clusteru, multi-region).
- Indexační strategie a observabilita (slow queries, hot partitions, cache hit ratio).
- Bezpečnost (TLS, ACL/role, šifrování na disku) a zálohování/DR
