MongoDB, Cassandra a Redis: přehled NoSQL nástrojů a jejich využití

NoSQL databáze
Peter Kráľ
MongoDB, Cassandra a Redis: Přehled a využití NoSQL nástrojů

Proč NoSQL a kdy po nich sáhnout

MongoDB, Apache Cassandra a Redis patří mezi nejrozšířenější NoSQL databáze, které pomáhají překonávat limity 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 filozofii škálování: MongoDB jako document store, Cassandra jako wide-column store s důrazem na horizontální škálování a dostupnost a Redis jako in-memory key–value engine s bohatými datovými strukturami a extrémně nízkou latencí. Volba závisí na prioritách v takzvaném CAP trojúhelníku (konzistence, dostupnost, odolnost vůči rozdělení sítě), na přístupu k modelování dat, SLA i provozních omezeních.

Datové modely a schémata

  • MongoDB (Document): Dokumenty podobné JSON (BSON) s flexibilním schématem. Vhodné pro hierarchická data, vnořené poddokumenty a rychlý vývoj schémat bez rozsáhlých migrací.
  • Cassandra (Wide-column): tabulky a partition key se sloupci clustering. Datový model vychází z přístupu „modeluj podle dotazů“ – data se denormalizují a materializují podle vzorců čtení.
  • Redis (In-memory key–value): klíče a různé typy hodnot (strings, lists, sets, sorted sets, hashes, streams, bitmaps, hyperloglog). Od Redis 6+ rozšiřují možnosti per-key modules a data types (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 nad více dokumenty a ACID v rámci kolekcí a replikových sad.
  • Cassandra: CQL (Cassandra Query Language) připomínající SQL, ale bez joins a ad hoc agregací napříč partition. Důraz se klade 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 dotazy nad JSON.

Indexace a vyhledávání

  • MongoDB: single-field, compound, multikey (pro pole), TTL, partial a sparse indexy; podpora covered queries a hint. S Atlas Search (Lucene) nabízí také bohaté fulltextové, geografické a sémantické vyhledávání.
  • Cassandra: primárně se spoléhá na primary key a pořadí clustering sloupců. Sekundární indexy mají omezené využití (hodí se pro nízkou kardinalitu). Pro fulltextové vyhledávání a analytiku se často integruje Elastic/Trino/Spark.
  • Redis: základní operace mají podle typu složitost O(1)/O(log n); RedisSearch (součást Redis Stack) přináší invertované indexy, fulltextové vyhledávání a agregace.

Transakce, konzistence a CAP

  • MongoDB: v replikové sadě jsou výchozí hodnoty readConcern/writeConcern nastavitelné; lze použít také majority. Podporuje vícedokumentové transakce (ACID) – vhodné pro scénáře podobné OLTP.
  • Cassandra: orientace na AP (dostupnost + odolnost vůči rozdělení sítě). Tunable consistency (ONE, QUORUM, ALL…) pro čtení i zápis. Transakce napříč partition nejsou k dispozici; lightweight transactions (CAS) umožňují podmíněný zápis za cenu režie Paxos.
  • Redis: atomicita jednotlivých příkazů; transactions (MULTI/EXEC) bez izolace mezi klienty; LUA skripty pro atomické složené operace. Redis Cluster používá asynchronní replikaci (eventual consistency mezi shardy).

Škálování, sharding a replikace

  • MongoDB: replica set (primary + secondaries) zajišťuje vysokou dostupnost; horizontální škálování umožňuje sharded cluster (shard key, balancer, range/hash sharding). Čtení lze přesměrovat na sekundární uzly s odpovídající úrovní konzistence.
  • Cassandra: architektura masterless, peer-to-peer s konzistentním hashováním a bez jediného bodu selhání. Snadné scale-out přidáváním uzlů, automatické vyvažování replik v keyspace s definovaným replication factor.
  • Redis: Redis Cluster (hash sloty) umožňuje horizontální škálování, replicas zajišťují vysokou dostupnost. Pro velmi vysokou odolnost a perzistenci se kombinuje s AOF/RDB a sentinel pro převzetí služeb při selhání.

Perzistence, odolnost a zotavení

  • MongoDB: journaling, write-ahead logging, zálohy k určitému časovému bodu (oplog), change streams pro CDC. Silná perzistence na disk.
  • Cassandra: commit log + SSTables (LSM-tree), memtable flush, kompakce. Přirozeně odolná vůči výpadkům uzlů; nastavitelná konzistence minimalizuje RPO.
  • Redis: primárně in-memory; volitelná perzistence prostřednictvím RDB snapshotů a AOF (append-only log) s různými zásadami fsync. Při přísných požadavcích na RPO/RTO je nutná pečlivá konfigurace a replikace.

Latence a propustnost: výkonové profily

  • Redis: submilisekundová latence a miliony RPS při přístupu k datům v paměti; ideální pro cache, úložiště relací, žebříčky v reálném čase, pub/sub a proudy dat (Streams).
  • MongoDB: nízká až střední latence při bohatých možnostech dotazování; vhodné pro backendy API, katalogy, uživatelské profily a úložiště událostí s agregacemi.
  • Cassandra: stabilní latence při zátěži a lineární škálování pro rozsáhlé zápisy a čtení s předvídatelným vzorem přístupu (telemetrie, časové řady, IoT).

Typické případy použití

  • MongoDB: aplikace založené na mikroslužbách, systémy pro správu obsahu, mobilní backendy, geolokace, event sourcing s change streams, rychlý vývoj schématu.
  • Cassandra: logování a metriky v petabajtovém měřítku, časové řady, messaging s nízkým RTO, retailový clickstream s požadavkem na dostupnost ve více regionech.
  • Redis: vrstvy cache, rate limiting, fronty a leaderboards, notifikace v reálném čase, feature flags, fulltextové vyhledávání a JSON (Redis Stack), pokud je potřeba nízká latence.

Modelování dat: principy a anti-patterny

  • MongoDB: vnořovat, nebo referencovat – malé, často čtené podstruktury vnořujte (embed), velké a sdílené entity propojujte pomocí referencí. Vyhýbejte se neomezenému růstu dokumentu (document growth) a neefektivním unbounded arrays.
  • Cassandra: nejprve specifikujte dotazy, teprve potom navrhujte tabulky. Vyhýbejte se „horkým“ partition (skew) – volte složené klíče a bucketing podle času.
  • Redis: vybírejte datový typ podle operací (počítadla → INCR, žebříčky → ZSET, dokumenty → JSON). Nastavujte TTL a eviction policy; bez dělení na části se vyhněte příliš velkým klíčům (big values).

Transakční požadavky a konzistence v praxi

Pokud je nutná silná konzistence ACID a transakce zahrnující více entit, má navrch MongoDB (případně zvažte relační databázi). Cassandra řeší konzistenci per-request pomocí kvór a hodí se tam, kde mírná eventualita není problém. Redis poskytuje atomickou sekvenci operací (script/transaction) v rámci jednoho uzlu; v clusteru je třeba brát v úvahu omezení key-slot a operace cross-slot.

Observabilita, provoz a údržba

  • MongoDB: profiler, explain plans, telemetrie FTDC; monitorujte oplog lag, blokace, velikost pracovních sad a indexů.
  • Cassandra: nodetool, metriky JMX, chování při compaction/GC, latenci čtení a zápisu, stav replikace; pečlivě laďte kompaktaci (STCS/LCS/TWCS) a velikost memtable.
  • Redis: metriky INFO, latency monitor, slowlog, stav sentinel/cluster; sledujte využití paměti, fragmentaci, I/O operací RDB/AOF a zpoždění replikace.

Bezpečnost a governance

  • Autentizace/Autorizace: všechny tři systémy podporují ACL; MongoDB nabízí řízení přístupu na základě rolí, Cassandra role management a Redis ACL pro jednotlivé příkazy a vzory klíčů.
  • Šifrování: TLS při přenosu; šifrování na disku (TDE/dm-crypt) podle distribuce; správa klíčů prostřednictvím cloudového KMS.
  • Audit: MongoDB nabízí podrobné auditní protokoly; u Cassandry a Redis se často využívá externí centralizace (SIEM) prostřednictvím exportu metrik a protokolů.

Cloudové služby a ekosystém

  • MongoDB Atlas: spravovaná multicloudová služba, serverless, Atlas Search, Triggers, Data Federation, konektory pro BI/ETL.
  • Managed Cassandra: DataStax Astra, Amazon Keyspaces (CQL), Azure Managed Instance for Cassandra; 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 a kompresi; velké soubory ukládejte přes GridFS pouze v případě potřeby. Sledujte náklady na IO/Storage v cloudu.
  • Cassandra: lineární škálování přidáváním uzlů; náklady určují především počet strojů a IO. Důležitá je správná velikost SSTable, kompaktace a ladění GC v JVM.
  • Redis: paměť je drahá – využívejte kompresi (u JSON), expiraci, LFU/LRU a oddělování „hot“/„warm“ dat (přesun do diskových vrstev, pokud to produkt umožňuje).

Migrace a polyglot persistence

Často dává smysl polyglotní přístup: Redis jako cache a messaging, MongoDB jako primární úložiště aplikačních dat a Cassandra pro časové řady a události v masivním měřítku. Při migracích definujte kontrakty schémat, dual-write/change data capture a ověřujte konzistenci pomocí vzorkování. Zohledněte idempotentní opakované zpracování a backfill historických dat.

Testování, benchmarking a SLO

  • Simulujte reálnou zátěž: kombinaci čtení a zápisů, rozložení klíčů, velikosti dokumentů/řádků a hotspoty.
  • Měřte latence p50/p95/p99 a jejich variabilitu; dejte pozor na pauzy GC (Cassandra), page faulty (MongoDB) a fsync AOF (Redis).
  • Definujte SLO: latenci, throughput, RPO/RTO a dostupnost; nastavte pravidla pro upozorňování a automatické škálování.

Rozhodovací matice: rychlý výběr podle kritérií

  • Potřeba bohatých dotazů a flexibilního schématu → MongoDB.
  • Masivní škálování napříč datovými centry s vysokou dostupností → Cassandra.
  • Extrémně nízká latence (sub-ms), cachování, fronty, analytika v reálném čase → Redis (Redis Stack pro JSON/Search).
  • Silné ACID transakce napříč více entitami → spíše MongoDB (nebo relační DB).
  • Jednoduché operace nad klíči a datovými strukturami → Redis.

Časté chyby a doporučení

  • MongoDB: chybějící vhodný shard key, nadměrné používání $lookup namísto promyšleného modelu, neomezené pole.
  • Cassandra: nesprávně zvolený partition key → nevyvážený cluster; nevhodná kompaktace → vyšší latence a tlak na disk.
  • Redis: chybějící expirace, přetěžování jediného 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 vzorců přístupu; ověření na reálných scénářích.
  • Strategie škálování (replication factor, shard key, topologie clusteru, více regionů).
  • Strategie indexace a observabilita (pomalé dotazy, horké partition, poměr zásahů cache).
  • Bezpečnost (TLS, ACL/role, šifrování v klidu) a zálohování/DR (RPO/RTO).
  • Optimalizace nákladů (tiering, komprese, TTL, automatické škálování) a testy odolnosti.

Závěr: správný nástroj pro správnou práci

MongoDB, Cassandra a Redis nejsou zaměnitelné – každá technologie řeší jinou třídu problémů. Úspěch spočívá v realistickém posouzení požadavků, disciplinovaném modelování, dobře navržené topologii škálování a pečlivé observabilitě. V praxi se osvědčuje polyglot persistence – využít Redis pro rychlou vrstvu a messaging, MongoDB pro flexibilní aplikační datové modely a Cassandru pro lineárně škálovatelné časové řady a události. Tím získáte robustní, výkonné a nákladově předvídatelné řešení pro prostředí moderních distribuovaných systémů.