Škálování a replikace v prostředí NoSQL: horizontální distribuce

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 hardwaru. 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 (kopírování dat pro zajištění odolnosti a výkonu). 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 rozdělení sítě (P) je nutné volit mezi Consistency (C) a Availability (A). NoSQL systémy často preferují AP (např. ve stylu Dynamo) nebo CP (např. MongoDB/majority, Etcd).
• PACELC: mimo rozdělení sítě (Else) se volí mezi Latency (L) a Consistency (C). Prakticky jde o volbu mezi kvórem a čtením s nízkou latencí z lokálních replik.
• Úrovně konzistence: strong, bounded-staleness, monotonic, read-your-writes, eventual. V praxi je lze nastavit pro každou operaci zvlášť (např. nastavitelné úrovně konzistence v Cassandře, readConcern/writeConcern v MongoDB).

Horizontální škálování: sharding a rozdělení klíčů

Sharding rozděluje datovou sadu na partitions/shards umístěné na různých uzlech. Klíčové je minimalizovat horká místa a rovnoměrně rozložit zátěž.

• Sharding založený na hashi: konzistentní hashování (Dynamo, Cassandra) nebo hashovaný shard key (MongoDB). Vyrovnává distribuci, ale snižuje efekt lokality při rozsahových dotazech.
• Sharding založený na rozsazích: výborně se hodí pro rozsahové dotazy; vyžaduje dělení a slučování shardů a hlídání horkých rozsahů (časové klíče, monotónní ID).
• Sharding podle adresáře/vyhledávání: centrální směrování (katalog routeru) je flexibilní, ale přidává další pohyb datových částí a vytváří bod selhání či škálování řídicí vrstvy.
• Kompozitní a kombinovaný hashový a rozsahový sharding: kombinují výhody obou přístupů (např. prefix tenant + hash orderId) pro scénáře s více tenanty.

Replikace: topologie a protokoly

• Na bázi leaderu (primary–replica): zápisy probíhají na leaderu a replikují se na followers (MongoDB, Couchbase, Redis v režimu replikace). Konflikty se řeší jednodušeji, konzistence je silnější při potvrzování většinou replik.
• Bez leaderu (kvórum, styl Dynamo): klient zapisuje a čte pomocí kvór; konflikty se řeší metodou last write wins, vektory verzí nebo pomocí CRDT. Dostupnost je vysoká, ale konsolidace je složitější.
• Multi-leader: více uzlů, na které lze zapisovat (geograficky distribuované active-active); je nutné řešit konfliktní zápisy a datové typy conflict-free.

Kvórum a „nastavitelná konzistence“

U systémů s kvórem a replikačním faktorem N platí pro silnou konzistenci při čtení následující pravidlo: zvolte W (počet potvrzení zápisu) a R (počet potvrzení čtení) tak, aby R + W > N. Běžné volby jsou W=majority, R=majority pro chování typu CP nebo W=1, R=1 pro nízkou latenci (eventual consistency).

Mechanismy odolnosti: anti-entropy a opravy

• Hinted handoff: dočasné uložení zápisů určených nedostupnému uzlu a jejich pozdější doručení.
• Oprava při čtení: při čtení klient zjistí rozdíly a zapíše opravy na pomalejší repliky.
• Merkleovy stromy/vrstvené hashování: efektivní porovnávání shardů mezi replikami.
• Vektorové hodiny a verze: rozlišování souběžných verzí (kauzální řazení).
• CRDT: datové typy s matematicky definovanou konvergencí (čítače, množiny, mapy) – odstraňují potřebu ručního slučování.

Datové struktury a cesty zápisu

• LSM-tree (Cassandra, HBase, základy LevelDB): zapisuje sekvenčně do logu a memtable, později provádí kompakci do souborů SST. Nabízí vysokou propustnost zápisů, ale představuje kompromis z hlediska čtení a kompakce.
• B+-tree (některé implementace úložišť klíč–hodnota a dokumentových databází): stabilní latence čtení, ale bez optimalizací jsou zápisy na HDD/SSD náročnější.
• WAL/commitlog: zajišťuje trvanlivost zápisů před potvrzením klientovi; je nutné dimenzovat IO a oddělit log od datových souborů.

Geografická replikace a více regionů

• Active-passive: primární region s asynchronní replikací do lokality pro zotavení po havárii (DR); nižší náklady, delší RPO/RTO.
• Active-active: zápisy probíhají ve více regionech; je nutné stanovit strategii řešení konfliktů (časová logika, CRDT, leader pro jednotlivé klíče).
• Latence a směrování: geo-DNS, směrování klientů na nejbližší repliku, vzory read-local/write-global.

Vyvažování zátěže a topologie clusteru

• Konzistentní hashování s virtuálními uzly: jemnozrnné rozložení shardů a rychlejší vyvažování.
• Vědomí racků/zón: repliky napříč racky či zónami zvyšují odolnost proti výpadku domény.
• Klientské ovladače: směrování „token-aware“, automatické opakování požadavků s exponenciálním prodlužováním prodlev a jističe (circuit breakers).

Resharding, vyvažování a růst clusteru

• Scale-out: přidání uzlů → přesun tokenů/partition; kontrola dopadu na latenci a IO.
• Online resharding: postupné dělení a slučování shardů za provozu, omezení rychlosti pro minimalizaci dopadů.
• Omezení horkých míst: přidávání náhodných znaků ke klíčům (salting), dělení podle časových intervalů, náhodné prefixy, write sharding na aplikační vrstvě.

Datové modelování pro škálování

• Návrh nejprve podle přístupových vzorů: tabulky/kolekce navrhujte podle dotazů; denormalizace je očekávaná.
• Disciplína při volbě partition key: vysoká kardinalita a rovnoměrná distribuce; pro rozsahové dotazy přidejte sekundární komponentu.
• TTL a zásady expirace: snížení objemu často používaných dat, dopad na kompakci a GC.

Praktické použití v konkrétních systémech

• Apache Cassandra: konzistentní hashování, nastavitelné úrovně konzistence (ONE, QUORUM, ALL), LSM+kompakce (Size-Tiered/Leveled), více datových center pomocí NetworkTopologyStrategy.
• MongoDB: shardování prostřednictvím konfiguračních serverů a routerů mongos, hashové/rozsahové shard keys, replica sets s majority writeConcern, transakce ACID v rámci shardu (transakce napříč více shardy mají režii).
• Couchbase: oddělené služby (Data/Query/Index), vbuckets pro vyvažování, replikace mezi datovými centry (XDCR).
• Redis Cluster: 16 384 hashovacích slotů, repliky pro vysokou dostupnost, pipelining/Lua pro dávkové zpracování; vhodný pro cache a úložiště klíč–hodnota s nízkou latencí.
• Amazon DynamoDB: spravovaný sharding a automatické škálování, limity partition throughput, Global Tables pro více regionů.

Latence, propustnost a řízení zpětného tlaku

• Řízení tempa a omezení rychlosti: omezte paralelismus klientů, aby se v úložišti netvořily fronty.
• Dávkové zpracování: dávkování zápisů/čtení pro efektivnější IO (pozor na SLA pro jednotlivé požadavky).
• Prioritizace: oddělení systémových a uživatelských úloh (kompakce, opětovné sestavení indexů oproti online provozu).

Správa životního cyklu dat a kompakce

• Zásady kompakce: volba mezi nižší latencí čtení (LCS) a menším zesílením zápisu (STCS/TWCS) podle vzorce zápisů.
• Ochranná lhůta GC: časové okno pro anti-entropy a tombstones; příliš krátká lhůta znamená riziko obnovení smazaných záznamů.
• Vrstvení dat podle stáří a četnosti přístupu: přesun historických shardů na levnější úložiště.

Monitorování a SLO

Bezpečnost a izolace v distribuovaných clusterech

• Šifrování při přenosu (TLS/mTLS mezi uzly a klienty), šifrování uložených dat (disky, snímky, zálohy).
• RBAC/ABAC, oddělení tenantů (prefixy klíčů, namespaces), limity na úrovni shardů.
• Audit: přístupy, změny schémat, operace správy clusteru (vyvažování, resharding).

Zálohování, PITR a obnova v topologii se shardy

• Koordinované snímky: konzistentní bod napříč shardy (bariéra/zámek, transakční značky, kontrolní body opLog/binlog/WAL).
• PITR: archivace logů pro každý shard, obnova podmnožiny shardů a přehrání do kontrolního bodu.
• Test obnovy: izolovaný testovací cluster, ověření integrity a latencí před přepnutím.

Provoz v Kubernetes a automatizace

• Operátory: deklarativní řízení topologie (shardy, repliky, anti-affinity, třída úložiště), nasazování a návrat k předchozí verzi.
• Rozpočty výpadků podů: zachování kvóra a dostupnosti při údržbě.
• PersistentVolumes: třídy IOPS/latence; vyhrazené uzly pro datové pody.

Testování škálování a scénářů selhání

• Zátěžové a dlouhodobé testy: postupné zvyšování zátěže, sledování P99 a fronty kompakce.
• Chaos engineering: simulace výpadků uzlů, zón a rozdělení sítě; ověření chování kvór.
• Kontrola schémat a dotazů: prevence dotazů typu „scatter/gather“ napříč mnoha shardy.

Nejčastější antipatterny a jak se jim vyhnout

1. Monotónní shard key (časové razítko, autoID) → horký shard. Použijte hashování/přidávání náhodných znaků ke klíčům nebo časové intervaly.
2. Výchozí konzistence všude → buď zbytečná latence, nebo riziko. Nastavte ji pro každou operaci zvlášť (read/write concern).
3. Nedostatečně dimenzovaná kompakce → nárůst latence. Sledujte frontu a plánujte údržbu mimo špičku.
4. „Replikace = záloha“ – to neplatí. Zaveďte koordinované snímky a PITR.
5. Nerovnoměrný růst tenantů → sharding zohledňující tenanty a možnost migrace mezi shardy.

Kontrolní seznam pro návrh škálovatelného NoSQL

• Jasně definované přístupové vzory; zvolený shard key s vysokou kardinalitou a bez horkých míst.
• Replikační faktor a konzistence (R/W) odvozené od SLO (latence, RPO/RTO).
• Topologie zohledňující racky/zóny a automatické vyvažování.
• Monitorování P50/95/99, zpoždění replikace, fronty kompakce, tombstones.
• Strategie geografické replikace (active-passive oproti active-active) a směrování provozu.
• Zálohy napříč shardy, PITR, pravidelné testy obnovy.
• Bezpečnost: mTLS, šifrování uložených dat, RBAC/ABAC, audit.
• Provozní příručky: resharding, výměna uzlu, průběžná aktualizace, reakce na incidenty.

Závěr: škálování jako disciplína, nikoli jednorázová volba

Úspěšné škálování a replikace v prostředí NoSQL spočívají ve správné kombinaci shardingu, replikace, volby konzistence a provozní disciplíny. Technické principy (kvórum, CRDT, anti-entropy) musejí být sladěny s obchodními SLO a 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 zajistí odolnost vůči chybám i regionálním výpadkům.