Kdy použít NoSQL

Proč vůbec uvažovat NoSQL ve velkých datech

NoSQL databáze vznikly jako odpověď na potřebu horizontálně škálovat, pracovat s polostrukturovanými a nestrukturovanými daty a obsluhovat nízkolatenční dotazy při masivní zátěži. V projektech Big Data mohou přinést pružnost schématu, vysokou propustnost zápisu, geo-distribuci a odolnost vůči výpadkům. Nejsou však univerzálním řešením – volba NoSQL dává smysl tam, kde omezení relačních systémů (ACID v plné síle, rigidní schéma, vertikální škálování) brzdí dosažení obchodních SLA.

Klasifikace NoSQL a typické silné stránky

• Key-value (např. in-memory cache, distribuované KV úložiště): extrémní rychlost v O(1), TTL, jednoduché datové struktury, vhodné pro sezení, rate-limity, idempotentní tokeny.
• Dokumentové (JSON/BSON): schéma řízené aplikací, bohaté indexy, agregace; ideální pro katalogy, profily, telemetry s proměnnou strukturou.
• Široko-sloupcové (column-family): zápisy s vysokou propustností, časové řady, „append-heavy“ logy; lineární škálování a predikovatelné latence.
• Grafové: traversaly, centrality, vzory vztahů; fraud detection, doporučování, znalostní grafy.
• Time-series: komprese, downsampling, retention, okna; observabilita, IoT, průmyslové telemetry.
• Vyhledávací (full-text, inverted index): relevanční skóre, facety, fuzzy matching; katalogy, log-search, analytika textu.

Kdy NoSQL zvažovat: rozhodovací kritéria

• Horizontální škálování: potřebujete lineárně přidávat uzly a držet latenci sub-10 ms při milionech RPS.
• Variabilní schéma: doména se vyvíjí (atributy produktů, události), rigidní tabulky by vedly k častým migracím.
• Write-heavy zátěž: proudy událostí, logy, IoT metriky > 100k zapisů/s; NoSQL lépe absorbuje „burstiness“.
• Globální distribuce: multi-region, low latency pro uživatele po světě, geo-replikace s lokálním zápisem.
• Datové modely mimo 3NF: přirozeně denormalizovaná data, přístupové vzory známé předem.
• Ekonomika: náklady za TB a R/W operace vs. licence a vertikální HW u RDBMS.

Kdy NoSQL nepoužívat

• Silné ACID a ad-hoc JOINy: komplexní transakce napříč tabulkami, uzávěrky a odvodzování přes JOINy patří do RDBMS.
• Neznámé přístupové vzory: NoSQL se modeluje od dotazů; pokud je analytika převážně ad-hoc, uvažte DWH/lakehouse.
• Silná referenční integrita: enforce na úrovni DB (FK, CHECK) často chybí či je omezená.
• Nutnost standardního SQL: pokud je investice do SQL ekosystému zásadní, volte kompatibilní systémy (NewSQL/HTAP).

CAP a PACELC: jak chápat konzistenci a latenci

V distribuovaných systémech nelze v přítomnosti síťové partition současně zaručit silnou konzistenci a dostupnost (CAP). Model PACELC doplňuje, že mimo partition volíme mezi latencí a konzistencí. NoSQL často poskytuje eventual nebo tunables (např. read/write quorum). Klíčem je sladění s obchodním SLA: kolik stale čtení je akceptovatelných a jaká je tolerovaná latence při zápisu?

Modelování v NoSQL: přístupové vzory před schématem

• Dotaz-první návrh: definujte top 10 dotazů (PK, sort, filtry, rozsahy), podle nich vytvořte klíče a materiálizované pohledy.
• Denormalizace: ukládání redundance (vyžaduje „fan-out on write“ nebo asynchronní projekce).
• Kompozitní klíče: prefixy pro sharding a time-bucket pro time-series; vyhněte se hotspotům.
• TTL a retence: automatický lifecycle – mazání starých dokumentů/měření.
• Indexy: používat střídmě; každý sekundární index je skrytá write-daň.

Workloady, kde NoSQL typicky exceluje

• Telemetrie a logy: stovky tisíc eventů/s, časové okno, downsampling, roll-ups.
• Real-time personalizace: profily, session store, feature flags, doporučení s latencí < 10 ms.
• E-commerce katalog: dokumentové modely s bohatými filtry a full-textem vedle sebe.
• Gaming a IoT: vysoký objem krátkých zápisů, geodistribuce, offline-first synchronizace.
• Grafové analýzy: detekce komunit, podvody, K-hop traversaly.

Transakce v NoSQL: co reálně dostanete

• Jemnozrnné ACID: často na úrovni single-key/single-partition (atomický zápis dokumentu/řádku).
• Vícedokumentové transakce: bývají k dispozici, ale s omezeními (výkon, velikost, pouze v rámci shardu nebo s vyšší latencí).
• Idempotence a at-least-once: aplikace musí počítat s opakováním a kompenzacemi (ságy) v distribuovaných scénářích.

Škálování a datová distribuce

• Sharding: hash/ range / composite; pečlivě volte klíč, aby nevznikaly hotspoty (např. přidáním saltingu nebo bucketů).
• Replikace: leader-follower, multi-leader, CRDTs pro konflikt-free datastruktury; volba ovlivňuje konzistenci i SLA.
• Multi-region: latency-based routing, lokální zápis s eventual konzistencí vs. globální quorum s vyšší latencí.

Observabilita a provoz

• Metriky: p99 latence, write amplification, hit-rate cache, compaction/GC, velikost SSTable/segmentů.
• Optimalizace: správná velikost partičních souborů, limit malých souborů, backpressure na konzumentech.
• Zálohy a obnova: snapshoty per shard, point-in-time recovery, testy DR (failovery, region cut-over).

Bezpečnost, governance a compliance

• IAM: RBAC/ABAC, jemné scope per kolekce/klíčový prostor.
• Šifrování: v klidu i na drátě, rotace klíčů, audit přístupů, pole-level encryption u citlivých atributů.
• Datová kvalita: validační schémata (JSON Schema), write-time validační pravidla, retenční a právní mazání.

Ekonomika provozu a FinOps

• Model nákladů: platby za kapacitu (vCPU/RAM/IOPS) vs. request-unit/operaci; sledování píků a průměrů.
• Tiering: hot vs. warm vs. cold storage, komprese, object storage jako sekundární archiv.
• Optimalizace dotazů: omezit scan, využít projekce, materializované pohledy, precalculated agregace.

Hybridní přístupy: polyglot persistence a HTAP

Jedna databáze zpravidla nevyřeší vše. Polyglot persistence kombinuje NoSQL pro OLTP (nízká latence, škálování) s relačním DWH/jezerem pro analytiku a s vyhledávacím enginem pro full-text. HTAP systémy či „NewSQL“ přinášejí distribuované ACID s SQL rozhraním; mohou být vhodné tam, kde je nutná transakční konzistence i horizontální škálování.

Migrace z RDBMS na NoSQL: postup a pasti

1. Kartografie dotazů: zjistit top N dotazů a přístupových vzorů, definovat SLA.
2. Doménové agregáty: identifikovat hranice konzistence (aggregate root) a přemapovat tabulky na dokumenty/partice.
3. Event-driven synchronizace: CDC z RDBMS → fronta → projekce do NoSQL; obousměrné konflikty řešit CRDT/ságami.
4. Backfill a validace: re-index, kontrolní součty, sampling, shadow traffic před cut-overem.

Anti-patterny při nasazení NoSQL

• „Lift-and-shift“ tabulek do dokumentů bez změny modelu – skončíte s JOINy v aplikaci a výkonem pod očekáváním.
• Univerzální sekundární indexy – degradace zápisů a compaction; indexujte jen dotazy, které skutečně potřebujete.
• Monolitický partition key – hotspoty, throttling, nerovnoměrný sharding.
• Nerespektování limitů velikosti dokumentu/řádku – useknuté zápisy, neefektivní přenosy; split/attachment pattern.

Checklist pro rozhodnutí „je NoSQL vhodné?“

• Máte jasně definované přístupové vzory (klíče, rozsahy, filtry) a SLA (p95/p99, RPS)?
• Je datový model přirozeně denormalizovaný a snáší eventual konzistenci nebo tunable quora?
• Potřebujete multi-region zápis/čtení a automatický failover bez zásahu?
• Je workload převážně write-heavy nebo vysoce proměnlivý (burst)?
• Máte plán na validaci schémat, governance a bezpečnost (PII, retenční pravidla)?
• Existuje strategie záloh, PITR a testované DR scénáře?
• Je spočtená TCO a je výhodnější než RDBMS + škálování?

Modelové scénáře

Minimální provozní standardy pro NoSQL v produkci

• Automatizované provisioning a schema rules (kolekce/klíčové prostory jako kód).
• Monitoring p99, saturace CPU/IO, heap/GC, velikost partition, zdržené replikace.
• SLA pro repair/compaction, rotace klíčů, testy chaos engineering (výpadek regionu/uzlu).
• Politiky TTL/retence a automatické tiering do objektového úložiště.

Závěr: NoSQL jako cílený nástroj, nikoli dogma

NoSQL dává smysl, když doména vyžaduje elasticitu, škálování a variabilní schéma, přístupové vzory jsou dobře známé a aplikace unese tunable/eventual konzistenci. Správná implementace začíná návrhem od dotazů, pečlivou volbou klíčů a indexů, observabilitou a provozní disciplínou. V kombinaci s relačními a analytickými technologiemi umožní stavět systémy, které zvládnou objem, rychlost i rozmanitost dat bez kompromisů v uživatelském zážitku.