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í, rychlost vývoje i nákladový model aplikací. SQL databáze využívají tabulkový model se striktní 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 preferuje schema-on-read, horizontální škálování a optimalizaci pro specifické 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 operací.
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, MapReduce, pattern matching u grafů). Dotazování je často optimalizované pro předem definované „query shapes“.
Transakce a konzistence
- SQL: plnohodnotné ACID transakce napříč více řádky či tabulkami, různé úrovně izolace, často s využitím MVCC.
- NoSQL: škála od silné konzistence po eventual consistency; mnoho systémů nabízí atomické operace na úrovni jednotlivých klíčů či 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ší servery), sekundární repliky pro čtení; moderní systémy podporují partitioning/sharding, avšak s vyšší složitostí implementace.
- NoSQL: nativní horizontální škálování přes sharding, elastické přidávání uzlů, geo-replikace; kompromisy dle CAP/PACELC principů (latence vs. konzistence).
Integrita a referenční vazby
- SQL: cizí klíče, CHECK, UNIQUE a triggery vynucují referenční integritu přímo na úrovni databáze.
- NoSQL: integrita je často spravována na aplikační vrstvě; dokumentové databáze preferují agregát jako jednotku konzistence, grafové databáze reprezentují vazby explicitně pomocí hran.
Výkonové charakteristiky
- SQL: optimalizátor dotazů, rozsáhlá indexace (B-tree, hash, bitmapové, full-text), materiálované pohledy; exceluje v OLTP s komplexními pravidly i v OLAP (zejména ve sloupcových enginech).
- NoSQL: vysoká propustnost pro specifické vzory (např. key-value GET/PUT, časové řady), sekundární indexy v závislosti na platformě; výkon často závisí na vhodném datovém modelu k daným dotazům.
Bezpečnost a governance
- SQL: vyspělý RBAC/ABAC, row- a column-level security, transakční audit, rozsáhlé nástroje pro dodržování compliance.
- NoSQL: široké spektrum možností; moderní platformy nabízí šifrování, role, audit i jemnozrnné oprávnění, nicméně funkčnost se liší dle typu a výrobce.
Náklady a provoz (TCO, FinOps)
- SQL: licence (u komerčních produktů), náklady na HA/DR, výkonové škálování „nahoru“. Spravované cloudové služby mírní provozní režii.
- NoSQL: lineární škálování „do šířky“, pay-as-you-go model, ale citlivost na egress, velikost dokumentů a sekundární indexy; důležité je správné rightsizing a řízení životního cyklu 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í (optimalizovaný 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 nastavení | Konfigurovatelná (od silné po 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 operacemi, silná referenční integrita.
- Preferujte NoSQL: uživatelské profily a obsah s proměnlivým schématem, vysoce propustné logy a telemetrie, real-time feedy, grafové vztahy (doporučovací systémy).
Migrační a hybridní přístupy
- Polyglot persistence: kombinace SQL jako 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 (Change Data Capture) 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 tak, aby se vyhnuly hotspotům.
- Měřte a iterujte: p95/p99 latence, plány dotazů, hit-rate cache, contention.
- Řešte governance: pojmenování, typy, retence, zabezpečení a audit v obou přístupech.
Časté omyly
- „NoSQL je vždy rychlejší.“ – Platí pouze pro vhodné vzory; nevhodný model může být pomalejší než SQL.
- „SQL neumí škálovat.“ – Moderní relační databáze podporují sharding, partitioning a geo-distribuci.
- „NoSQL nepotřebuje schéma.“ – Schéma existuje, jen je přesunuto do aplikace (schema-on-read) a vyžaduje disciplínu.
Kontrolní seznam před volbou
- Jaké transakční garance (ACID vs. eventual consistency) vyžaduje daná doména?
- Jaké dotazy a agregace budou běžné (JOINy? grafové průchody? časové agregace)?
- Jaká je růstová křivka dat a potřeba geo-replikace?
- Jaká je kompetence týmu a dostupnost ekosystému 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 nabízí 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.
