Proč NoSQL škáluje jinak
NoSQL databáze byly navrženy pro horizontální škálování, vysokou dostupnost a zpracování velkých objemů dat na běžném hardware. Na rozdíl od klasických relačních systémů s vertikálním škálováním a silnou konzistencí se NoSQL opírá o sharding (dělení dat napříč uzly) a replikaci (kopie dat pro odolnost a výkon). Volby v návrhu se často řídí principy CAP a PACELC – tedy kompromisy mezi dostupností, konzistencí, latencí a tolerancí k rozdělení sítě.
Modely konzistence a teoretické rámce
- CAP: při síťové partition (P) je nutné volit mezi Consistency (C) a Availability (A). NoSQL systémy často preferují AP (např. Dynamo-styl) nebo CP (např. MongoDB/majority, Etcd).
- PACELC: mimo partition (Else) se volí mezi Latency (L) a Consistency (C). Prakticky: volba quorum vs. low-latency lokálních čtení.
- Úrovně konzistence: strong, bounded-staleness, monotonic, read-your-writes, eventual. V praxi nastavitelné per operaci (např. Cassandra tunable consistency, MongoDB readConcern/writeConcern).
Horizontální škálování: sharding a rozdělení klíčů
Sharding rozděluje dataset na partitions/shards umístěné na různých noderch. Klíčové je minimalizovat hot-spoty a rovnoměrně rozložit zátěž.
- Hash-based sharding: konzistentní hashování (Dynamo, Cassandra) nebo hashovaný shard key (MongoDB). Vyrovnává distribuci, ale snižuje efekt lokality při range dotazech.
- Range-based sharding: výborné pro rozsahové dotazy; vyžaduje split/merge shardů a hlídat hot ranges (časové klíče, monotonní ID).
- Directory/lookup sharding: centrální směrování (router katalog) – flexibilní, ale další pohyb částí a bod selhání/škálování řídicí vrstvy.
- Composite a hashed+range: kombinují výhody (např. prefix tenant + hash orderId) pro multi-tenantní scénáře.
Replikace: topologie a protokoly
- Leader-based (primary–replica): zápisy na leader, replikace na followers (MongoDB, Couchbase, Redis v režimu replication). Jednodušší konflikty, silnější konzistence s majority potvrzeními.
- Leaderless (quorum, Dynamo-styl): klient zapisuje/čte s kvóry; konflikty řeší last write wins, vektory verzí nebo CRDT. Vysoká dostupnost, ale komplexnější konsolidace.
- Multi-leader: více zapisovatelných uzlů (geo-active-active); nutné řešit konfliktní zápisy a conflict-free datové typy.
Quorum a „tunable consistency“
U quorum systémů s replikací o faktoru N platí pro silné čtení: zvolte W (počet potvrzení zápisu) a R (počet potvrzení čtení) tak, aby R + W > N. Běžné volby: W=majority, R=majority pro CP chování, nebo W=1, R=1 pro latenci (eventual).
Mechanismy odolnosti: anti-entropy a opravy
- Hinted handoff: dočasné uložení zápisů pro nedostupný uzel, pozdější doručení.
- Read repair: při čtení klient detekuje divergence a zapisuje opravy na pomalejší repliky.
- Merkle stromy/vrstvené hashování: efektivní porovnání shardů mezi replikami.
- Vektorové hodiny a verze: rozlišení konkurenčních verzí (casual ordering).
- CRDT: datové typy s matematicky definovanou konvergencí (countery, sety, mapy) – eliminují manuální merge.
Datové struktury a zapisovací cesty
- LSM-tree (Cassandra, HBase, LevelDB podklady): zapisuje sekvenčně do logu a memtable, později kompakce do SST souborů. Vysoká propustnost zápisů, trade-off pro čtení a kompakce.
- B+-tree (některé key-value a dokumentové implementace): stabilní latence čtení, náročnější zápisy na HDD/SSD bez optimalizací.
- WAL/commitlog: trvanlivost zápisů před potvrzením klientovi; nutno dimenzovat IO a oddělit od datových souborů.
Geo-replikace a multi-region
- Active-passive: primární region s asynchronní replikací do DR; nižší náklady, delší RPO/RTO.
- Active-active: zápisy ve více regionech; požaduje konfliktní strategii (časová logika, CRDT, per-key leader).
- Latence a směrování: geo-DNS, klientské routování na nejbližší repliku, read-local/write-global vzory.
Vyvážení zátěže a topologie clusteru
- Konzistentní hashování s virtuálními nody: jemnozrnné rozložení shardů, rychlejší rebalancování.
- Rack awareness/zone awareness: repliky napříč racky/zónami; odolnost proti výpadku domény.
- Client drivers: „token-aware“ směrování, automatické retry s backoffem, circuit breakers.
Resharding, rebalancování a růst clusteru
- Scale-out: přidání uzlů → přesun tokenů/partition; kontrola dopadu na latenci a IO.
- Online resharding: postupné split/merge shardů za provozu, throttling pro minimalizaci dopadů.
- Hot-spot mitigation: salting klíčů, time-bucketing, randomizace prefixu, write sharding na aplikační vrstvě.
Datové modelování pro škálování
- Access-pattern-first: navrhujte tabulky/collections podle dotazů; denormalizace je očekávaná.
- Partition key disciplína: vysoká kardinalita, rovnoměrná distribuce; u range dotazů přidejte sekundární komponentu.
- TTL a expirační politiky: snížení objemu horkých dat, efekt na kompakce a GC.
Praktika v konkrétních systémech
- Apache Cassandra: konzistentní hashing, tunable consistency (ONE, QUORUM, ALL), LSM+kompakce (Size-Tiered/Leveled), multi-DC s NetworkTopologyStrategy.
- MongoDB: shardování přes config servery a mongos routery, hash/range shard keys, replica sets s majority writeConcern, transakce ACID v rámci shardu (víceshardové s overheadem).
- Couchbase: oddělené služby (Data/Query/Index), vbuckets pro rebalancování, cross-DC replikace (XDCR).
- Redis Cluster: 16384 hash slotů, repliky pro HA, pipelining/Lua pro dávky; vhodný pro cache a nízkolatenční klíč–hodnota.
- Amazon DynamoDB: spravované sharding a auto-scaling, partition throughput limity, Global Tables pro multi-region.
Latence, propustnost a backpressure
- Pacing a rate limiting: omezte paralelismus klientů, aby nevznikaly fronty v úložišti.
- Batching: dávkování zápisů/čtení pro efektivnější IO (pozor na SLA per-request).
- Prioritizace: oddělení systémové a uživatelské práce (kompakce, rebuild indexů vs. online traffic).
Správa životního cyklu dat a kompakce
- Compaction policy: volba mezi menší latencí čtení (LCS) a menším write amplification (STCS/TWCS) podle patternu zápisů.
- GC grace: okno pro anti-entropy a tombstones; příliš krátké → riziko obživnutí smazaných záznamů.
- Cold/hot tiering: přesun historických shardů na levnější storage.
Monitorování a SLO
| Oblast | Klíčové metriky | Poznámka |
|---|---|---|
| Latence | P50/P95/P99 read/write | Rozlišujte lokální vs. cross-DC. |
| Propustnost | Ops/sec, throttling rate | Ověřte limity shardu/partition. |
| Ztráty a chyby | Timeouty, unavailable, write fail | Mapujte na topologii/kvóra. |
| Sklad | Size/compaction backlog | Watch tombstones, sstable count. |
| Replikace | Replica lag, hinted queue | Lag > RPO = problém. |
Bezpečnost a izolace v distribuovaných clusterech
- Šifrování in-transit (TLS/mTLS mezi nody a klienty), at-rest (disk, snapshoty, zálohy).
- RBAC/ABAC, oddělení tenantů (prefixy klíčů, namespaces), limity na úrovni shardů.
- Audit: přístupy, změny schémat, operace cluster managementu (rebalancing, resharding).
Zálohování, PITR a obnova ve sharded topologii
- Koordinované snapshoty: konzistentní bod napříč shardami (barrier/lock, transakční značky, opLog/binlog/WAL checkpointy).
- PITR: archivace logů per shard, obnova subsetu shardů a replay do checkpointu.
- Test obnovy: sandbox cluster, ověření integrity a latencí před přepnutím.
Provoz v Kubernetes a automatizace
- Operátoři: deklarativní řízení topologie (shardy, repliky, anti-affinity, storage class), rollouts/rollbacks.
- Pod disruption budgets: udržení kvór a dostupnosti při údržbě.
- PersistentVolumes: IOPS/latency třídy; vyhrazené uzly pro datové pody.
Testování škálování a failure scénářů
- Load & soak: postupné zvyšování zátěže, sledování P99 a compaction backlogu.
- Chaos engineering: simulace výpadků uzlů, zón, síťových partition; ověření chování kvór.
- Schema a query reviews: prevence „scatter/gather“ dotazů přes mnoho shardů.
Nejčastější antipatterny a jak se jim vyhnout
- Monotónní shard key (timestamp, autoID) → hot shard. Použijte hashing/salting nebo time-buckets.
- Default consistency všude → buď zbytečná latence, nebo riziko. Nastavte per operaci (read/write concern).
- Nedimenzovaná kompakce → latence spike. Sledujte backlog, plánujte údržbu mimo špičku.
- „Replikace = záloha“ – není. Zaveďte koordinované snapshoty a PITR.
- Nerovnoměrný růst tenantů → tenant-aware sharding, možnost migrace mezi shardami.
Checklist pro návrh škálovatelného NoSQL
- Jasně definované access patterns; zvolený shard key s vysokou kardinalitou a bez hot-spotů.
- Replikační faktor a konzistence (R/W) odvozené od SLO (latence, RPO/RTO).
- Topologie s rack/zone awareness a automatickým rebalance.
- Monitorování P50/95/99, replica lag, compaction backlog, tombstones.
- Strategie geo-replikace (active-passive vs. active-active) a směrování provozu.
- Zálohy napříč shardami, PITR, pravidelné testy obnovy.
- Bezpečnost: mTLS, at-rest šifrování, RBAC/ABAC, audit.
- Runbooky: resharding, node replace, rolling upgrade, incident response.
Závěr: škálování jako disciplína, ne jednorázová volba
Úspěšné škálování a replikace v NoSQL prostředí spočívá ve správné kombinaci shardingu, replikace, volby konzistence a provozní disciplíny. Technické principy (quorum, CRDT, anti-entropy) musejí být sladěny s obchodními SLO a s pečlivým datovým modelováním. Dobře navržený a monitorovaný cluster umožní růst bez ztráty výkonu a poskytne odolnost vůči chybám i regionálním výpadkům.
