Relační vs. nerelační principy

Proč rozlišovat relační a nerelační databáze

Databázové systémy tvoří základ většiny informačních aplikací. Relační databáze (RDBMS) staví na tabulkách, relacích a deklarativním dotazování pomocí SQL, zatímco nerelační databáze (NoSQL) nabízejí alternativní datové modely – klíč–hodnota, dokumentový, sloupcově orientovaný či grafový – s důrazem na horizontální škálování, flexibilní schéma a specifické přístupové vzory. Správná volba ovlivňuje konzistenci dat, výkon, náklady i rychlost vývoje.

Relační model: tabulky, relace a integritní omezení

• Relační schéma – data jsou organizována do tabulek (relací) s pevně definovanými sloupci a datovými typy.
• Klíče – primární klíč (jedinečná identifikace řádku) a cizí klíč (odkaz na jinou tabulku) vynucují referenční integritu.
• Integritní omezení – NOT NULL, UNIQUE, CHECK a TRIGGERY zajišťují konzistenci na úrovni databáze.
• SQL – standardizovaný deklarativní jazyk (DDL/DML/DCL/TCL) pro definici, manipulaci a řízení přístupu i transakcí.

Normalizace a návrh schématu

Cílem normalizace je odstranění redundancí a anomálií při vkládání/aktualizaci/smazání. Běžně používané formy:

• 1NF – atomické hodnoty ve sloupcích, žádné opakující se skupiny.
• 2NF – žádná parciální závislost na části složeného klíče.
• 3NF – žádné tranzitivní závislosti neklíčových atributů.
• BCNF – posílená 3NF, každý determinant je kandidátský klíč.

V praxi se normalizace často kombinuje s denormalizací pro zvýšení výkonu (méně JOIN operací) za cenu řízené redundance.

Transakce, ACID a izolace

• ACID – Atomicita, Konzistence, Izolace, Trvalost (Durability) definují spolehlivé provádění transakcí.
• Úrovně izolace – READ UNCOMMITTED, READ COMMITTED, REPEATABLE READ, SERIALIZABLE; volba ovlivňuje jevy jako dirty read, non-repeatable read či phantom read.
• MVCC – multiverzování řádků (snapshoty) umožňuje vysokou souběžnost s minimem zámků.

Fyzická organizace, indexy a optimalizace dotazů (RDBMS)

• Úložiště – stránky/bloky, heap/clustered organizace tabulek, write-ahead log (WAL) pro crash-recovery.
• Indexy – B-stromy (range dotazy), hash indexy (rovnost), bitmapové indexy (nízká kardinalita), covering indexy, partiční indexy.
• Optimalizátor – volí execution plan (hash join, nested loops, merge join), používá statistiky selektivity a nákladový model.
• Materiálované pohledy – předpočítané agregace/denormalizace pro OLAP; správa obnovy (on commit/on demand).

Nerelační modely: přehled a principy

• Klíč–hodnota – extrémně jednoduchý model pro přímý přístup podle klíče; velmi rychlé PUT/GET, často v paměti.
• Dokumentové – ukládání polostrukturovaných dokumentů (např. JSON) s možností dotazů nad vnořenými strukturami a sekundárními indexy.
• Sloupcově orientované (wide-column) – data organizovaná po sloupcích/rodinách sloupců; efektivní pro velké škálování a časové řady.
• Grafové – uzly a hrany s vlastnostmi pro vztahově bohaté domény (cesty, centralita, vzory podgrafů).
• Time-series – optimalizace na pořadové vkládání, kompresi a downsampling metrik.

BASE a modely konzistence v NoSQL

• BASE – Basically Available, Soft-state, Eventually consistent; preferuje dostupnost a škálování.
• Konzistence – silná, eventual, read-your-writes, monotonic reads, causal; volitelná per-operace/klient.
• Replikace – synchronní vs. asynchronní; leader–followers, leaderless (kvóra R/W), anti-entropy a conflict resolution.

CAP a PACELC: limity distribuovaných databází

CAP naznačuje, že při síťové partici nelze současně garantovat plnou konzistenci a dostupnost. Model PACELC rozšiřuje úvahu i mimo poruchy: Partition → volba C/A; Else (bez poruchy) volba mezi Latency a Consistency. Prakticky jde o ladění kompromisu dle use-casu.

Škálování: vertikální vs. horizontální, partitioning a replikace

• Vertikální škálování – více CPU/RAM/IO; jednoduché, ale s limity a vyšší cenou hardwaru.
• Horizontální škálování – přidávání uzlů; vyžaduje partitioning (sharding: hash, range, list) a strategii rebalancování.
• Replikace – HA a čtenářská škálovatelnost; důraz na členství clusteru, failover, split brain a quorum.

Dotazování a transakce v NoSQL

• Model „query-shapes“ – schéma je často navrhováno dle typických dotazů (přístupových vzorů), nikoli čistě dle entit.
• Indexace – sekundární indexy, sparse indexy, kompozitní klíče; dopad na zápis a údržbu.
• Transakce – některé systémy nabízí multi-document transakce, jiné pouze single-partition atomicitu.

OLTP vs. OLAP a HTAP

• OLTP (operativa) – mnoho krátkých transakcí, nízká latence, vysoká souběžnost, normalizovaná schémata.
• OLAP (analytika) – masivní skeny a agregace, sloupcové formáty, komprese, star/snowflake modely.
• HTAP – hybridní zpracování transakcí i analytiky nad jedním uložištěm; nároky na izolaci a více replik s různou optimalizací.

Bezpečnost, audit a governance

• Řízení přístupu – RBAC/ABAC, row-level a column-level security, maskování a šifrování (TDE, KMS).
• Audit a dohled – logování přístupů, změn schématu, DML; korelace s SIEM.
• Data lifecycle – retence, archivace, time-to-live, právní požadavky a GDPR.

Zálohování, obnova a odolnost

• Zálohy – plné, inkrementální, log-based; test obnovy a point-in-time recovery.
• Georeplikace – DR scénáře s RPO/RTO cíli; aktivní–aktivní vs. aktivní–pasivní topologie.
• Schématické migrace – online změny, rolling upgrady, kompatibilita verzí klientů.

Návrhové vzory v dokumentových a klíč–hodnota databázích

• Agregát jako hranice konzistence – encapsulace dat, která se mění společně.
• Pre-join (denormalizace) – vložení relevantních poddokumentů pro čtení bez JOIN.
• Bucketování a prefixy klíčů – rovnoměrné rozložení shardů, minimalizace hotspotů.
• Event-sourcing/CQRS – oddělení zápisového a čtecího modelu, projekce pro dotazy.

Grafové databáze: traversály a algoritmy

• Dotazy – pattern matching (Cypher, Gremlin), více-krokové traversály s nízkou latencí.
• Algoritmy – nejkratší cesty, PageRank, komunity; vhodné pro doporučování, fraud a síťové analýzy.

Výkonnostní ladění: metriky a bottlenecky

• Metriky – latence p50/p95/p99, propustnost, hit-rate cache, využití IO/CPU, lock waity, délka front.
• Diagnostika – explain plan, profily dotazů, heatmapy indexů, contention na hot particích.
• Optimalizace – správné indexy, batchování, prepared statements, connection pooling, komprese a správné typy.

Ekonomika provozu: licencování a TCO

• Licence – komerční vs. open-source, per-core/per-node/per-feature; cloudové spravované služby s modelem pay-as-you-go.
• TCO – náklady na hardware/IO, provoz (zálohy, monitoring), škálování, repliky a datové přenosy.

Srovnání modelů – shrnutí

Rozhodovací rámec: jak vybrat vhodný přístup

1. Definujte přístupové vzory (čtení vs. zápis, latence, objemy, potřeba JOIN/analytiky).
2. Určete požadavky na konzistenci a transakce (ACID vs. eventual/casual).
3. Zvažte škálování – růst dat a provozu, geodistribuce, více datových center.
4. Vyhodnoťte schéma – stabilita vs. časté změny, polostrukturovaná data.
5. Odhadněte TCO – provoz, správa, kompetence týmu, vendor lock-in.

Časté chyby a jak se jim vyhnout

• Replikace on-prem modelů do distribuce – ignorování latencí a partičních jevů.
• Poddimenzovaná indexace – neoptimalizované dotazy, full-scan přístupy, vysoké IO.
• Nekonzistentní denormalizace – neřízené duplikace dat bez procesů obnovy.
• Přehnané „one-size-fits-all“ – volba jediné technologie pro všechny domény.
• Slabá governance – chybějící standardy typů, názvosloví, přístupů a retence.

Závěr: komplementarita místo ideologie

Relační databáze excelují v transakční integritě, standardizovaném dotazování a složitých agregacích. Nerelační přístupy přinášejí škálování, flexibilitu schématu a optimalizaci pro specifické dotazové vzory. Moderní architektury často kombinují oba světy: relační system of record s integritními garancemi a nerelační úložiště pro read-heavy služby, cache, logy, grafy či analytiku v reálném čase. Klíčem je přesná znalost domény, přístupových vzorů a nedefenzivní práce s kompromisy CAP/PACELC.