Proč srovnávat SQL a NoSQL
Volba mezi SQL (relačními) a NoSQL (nerelačními) databázemi zásadně ovlivňuje architekturu, škálování, vývojové tempo i nákladový model aplikací. SQL databáze využívají tabulkový model se silnou schema-on-write disciplínou a deklarativní dotazování v SQL. NoSQL zahrnuje více modelů (dokumentový, klíč–hodnota, wide-column, graf, time-series) a upřednostňuje schema-on-read, horizontální škálování a optimalizaci pro konkrétní přístupové vzory.
Datový model a schéma
- SQL: tabulky s pevně definovanými sloupci, datovými typy a integritními omezeními. Silná normalizace minimalizuje redundanci.
- NoSQL: flexibilní schéma (JSON dokumenty, páry klíč–hodnota, rodiny sloupců, uzly a hrany). Denormalizace a vnořené struktury snižují potřebu JOIN.
Dotazování a expresivita
- SQL: standardizovaný jazyk (JOIN, GROUP BY, window funkce, poddotazy). Vhodné pro komplexní analytické i transakční dotazy.
- NoSQL: specifické jazyky a API (např. JSON dotazy, map-reduce, pattern matching u grafů). Dotazování bývá optimalizované pro předem známé „query shapes“.
Transakce a konzistence
- SQL: plnohodnotné ACID transakce napříč více řádky/tabulkami, různé úrovně izolace, často MVCC.
- NoSQL: škála od silné konzistence po eventual; mnohé systémy nabízejí atomické operace per klíč/dokument, některé i multi-dokumentové transakce (s omezeními).
Škálování a dostupnost
- SQL: tradičně vertikální škálování (výkonnější uzel), sekundární repliky pro čtení; moderní systémy podporují partitioning/sharding, ale s vyšší komplexitou.
- NoSQL: nativní horizontální škálování přes sharding, elastické přidávání uzlů, geo-replikace; kompromisy dle CAP/PACELC (latence vs. konzistence).
Integrita a referenční vazby
- SQL: cizí klíče, CHECK, UNIQUE a triggery vynucují referenční integritu na úrovni databáze.
- NoSQL: integrita je často na aplikační vrstvě; dokumentové DB preferují agregát jako jednotku konzistence, grafové DB reprezentují vazby explicitně hranami.
Výkonové charakteristiky
- SQL: optimalizátor dotazů, bohatá indexace (B-tree, hash, bitmapové, full-text), materiálované pohledy; exceluje v OLTP s komplexními pravidly a v OLAP (ve sloupcových enginech).
- NoSQL: vysoká propustnost pro specifické vzory (např. key-value GET/PUT, časové řady), sekundární indexy dle platformy; výkon často závisí na správném datovém modelu pro dané dotazy.
Bezpečnost a governance
- SQL: vyzrálé RBAC/ABAC, row/column-level security, transakční audit, bohaté nástroje pro compliance.
- NoSQL: široké spektrum; moderní platformy nabízejí šifrování, role, audit i jemnozrnná oprávnění, ale funkce se liší dle typu a výrobce.
Náklady a provoz (TCO, FinOps)
- SQL: licence (u komerčních), náklady na HA/DR, výkonové škálování „nahoru“. Spravované cloudové služby snižují provozní režii.
- NoSQL: lineární škálování „do šířky“, pay-as-you-go, ale citlivost na egress, velikost dokumentů a sekundární indexy; důležitý rightsizing a životní cyklus dat (TTL).
Rozhodovací tabulka: SQL vs. NoSQL
| Kritérium | SQL databáze | NoSQL databáze |
|---|---|---|
| Schéma | Pevné, schema-on-write | Flexibilní, schema-on-read |
| Transakce | Plné ACID včetně multi-table | Od single-key po omezené multi-document |
| JOIN a relace | Nativní a efektivní (optim. plán) | Obvykle ne; preferována denormalizace |
| Škálování | Primárně vertikální, možnost shardingu | Nativně horizontální (sharding, replikace) |
| Konzistence | Silná ve výchozím stavu | Konfigurovatelná (silná až eventual) |
| Use-casy | ERP, účetnictví, rezervace, OLTP/OLAP | Katalogy, profily, logy, cache, grafy, IoT |
| Čas uvedení | Střední (modelování schématu) | Rychlý start (agilní modelování) |
| Governance | Silná, standardizovaná | Různorodá dle technologie |
Typické scénáře použití
- Preferujte SQL: finanční transakce, objednávkové systémy, reporting s komplexními JOIN, silná referenční integrita.
- Preferujte NoSQL: uživatelské profily a obsah s proměnlivým schématem, vysokopropustné logy/telemetrie, real-time feedy, grafové vztahy (rekomendace).
Migrační a hybridní přístupy
- Polyglot persistence: kombinace SQL pro system of record a NoSQL pro čtecí modely, cache či specifické domény (graf, time-series).
- Refaktoring: postupné přeuspořádání schématu a event-driven replikace (CDC) do dokumentového modelu.
- Federace dat: datová vrstva sjednocující dotazování (např. přes view/virtualizaci) napříč různými úložišti.
Návrhové principy pro úspěch
- Začněte přístupovými vzory (frekvence, latence, objem, konzistence), ne „technologií roku“.
- V SQL udržujte normalizaci pro zápisové modely, denormalizujte řízeně pro reporty (materiálované pohledy).
- V NoSQL modelujte podle agregátů (dokumentů), minimalizujte cross-document transakce a navrhujte klíče proti hotspotům.
- Měřte a iterate: p95/p99 latence, plány dotazů, hit-rate cache, contention.
- Řešte governance: pojmenování, typy, retence, zabezpečení a audit v obou světech.
Časté omyly
- „NoSQL je vždy rychlejší.“ – Jen pro vhodné vzory; špatný model může být pomalejší než SQL.
- „SQL neumí škálovat.“ – Moderní RDBMS podporují sharding/partitioning a geo-distribuci.
- „NoSQL nepotřebuje schéma.“ – Schéma existuje, jen je posunuto do aplikace (schema-on-read); vyžaduje disciplínu.
Kontrolní seznam před volbou
- Jaké transakční garance (ACID vs. eventual) vyžaduje doména?
- Jaké dotazy a agregace budou běžné (JOIN? grafové traversály? časové agregace)?
- Jaká je růstová křivka dat a potřeba geo-replikace?
- Jaká je kompetence týmu a ekosystém nástrojů (ORM, BI, observabilita)?
- Jaké jsou regulatorní požadavky (audit, data residency, DLP)?
Závěr: komplementární, nikoli konkurenční volby
SQL a NoSQL nejsou antagonisté, ale komplementární nástroje pro různé datové domény. SQL exceluje v transakční integritě, složitých dotazech a standardizaci. NoSQL přináší flexibilitu schématu, vysokou škálovatelnost a optimalizaci pro specifické vzory. Nejlepší výsledky často přináší polyglotní přístup, který kombinuje silné stránky obou světů v jedné architektuře.
