šárdingTakédatabase sharding, shardovaná databázePokročilý
Definice
Sharding je způsob horizontálního dělení datové sady na menší části, zvané shardy, které běží na oddělených uzlech nebo instancích databáze. Cílem je rozložit velikost dat, zápisy a dotazy tak, aby systém rostl za hranice jednoho serveru, ale za cenu složitějšího směrování, transakcí a provozu.
Proč sharding vzniká u velkých databází
Sharding řeší situaci, kdy jedna databázová instance přestává stačit kapacitou, zápisovým výkonem nebo propustností dotazů. Data se nerozmnoží na stejné kopie, ale rozdělí se na části. Každý shard drží jen určitou podmnožinu záznamů a může běžet na jiném serveru, virtuálním stroji nebo spravovaném uzlu. Aplikace, databázový router nebo samotný databázový systém musí poznat, kam konkrétní záznam patří.
Sharding bývá nejčastěji horizontální: tabulka uživatelů, objednávek nebo zpráv se dělí po řádcích. Jeden shard může obsahovat zákazníky s určitým rozsahem ID, jiný shard zákazníky podle výsledku hashovací funkce. Vertikální dělení, kde se oddělí sloupce nebo celé funkční oblasti, se obvykle řeší jinými architektonickými postupy.
Shard key rozhoduje o rovnováze clusteru
Shard key je hodnota, podle které systém vybírá shard. Volba shard key bývá důležitější než samotný počet serverů, protože špatně zvolený klíč vytvoří horký shard. Horký shard přijímá nepoměrně mnoho zápisů nebo dotazů, zatímco ostatní uzly čekají. Dobrý shard key má vysokou kardinalitu, rovnoměrně rozděluje data a zároveň odpovídá dotazům, které aplikace skutečně posílá.
Rozsahové shardování
Rozsahové shardování ukládá sousední hodnoty na stejný shard. Rozsah se dobře čte při dotazech typu „od do“, ale rostoucí klíč může přetížit poslední shard, protože nové záznamy padají pořád na stejné místo.
Hashované shardování
Hashované shardování rozprostře hodnoty pomocí hashovací funkce. Zátěž bývá rovnoměrnější, ale dotazy na souvislý rozsah často musejí obejít více shardů. Pro analytiku nad celou sadou dat proto může být nákladné.
Co sharding stojí při dotazech a změnách schématu
Sharding zvyšuje provozní složitost. Dotaz, který zná shard key, lze poslat přímo na správný shard. Dotaz bez shard key se mění na fan-out: systém se ptá více shardů a výsledek skládá dohromady. Podobně se komplikují unikátní indexy, spojování tabulek, transakce přes více shardů, zálohy, migrace dat a ladění incidentů.
Resharding znamená změnu rozdělení dat po nasazení. Resharding je citlivá operace, protože přesouvá živá data a musí zachovat konzistenci i dostupnost. Moderní databáze umějí část práce automatizovat, ale architektonické rozhodnutí zůstává na návrhu aplikace.
Dva příklady shardingu z praxe
Objednávky podle zákazníka
E-shop ukládá objednávky podle customer_id, protože zákaznický účet nejčastěji zobrazuje historii vlastních nákupů. Aplikace spočítá shard z identifikátoru zákazníka a pošle zápis jen na jeden uzel. Výpis objednávek je rychlý, ale celofiremní report za všechny zákazníky musí číst více shardů.
shard_id = hash(customer_id) % 16
write("orders_" + shard_id, order)Chatovací služba podle konverzace
Chatovací služba ukládá zprávy podle conversation_id, aby celé vlákno zůstalo pohromadě. Načtení posledních zpráv v jedné konverzaci míří na jediný shard a má stabilní odezvu. Velká skupinová konverzace ale může vytvořit horké místo, takže návrh musí počítat s limity extrémně aktivních vláken.
Příklady z praxe
Horký shard u chatovací aplikace
Tým vývojářů firemního chatu zvolil jako shard key časovou složku ID zprávy, takže všechny nové zprávy padaly na poslední shard. Během špičky dosahoval jeden uzel devadesáti procent zápisové kapacity, ostatní čtyři se nudily pod deseti procenty. Po analýze provozu tým přešel na hashovaný shard key složený z channel_id, protože většina dotazů stahuje historii jednoho kanálu. Zátěž se rozprostřela rovnoměrně, latence zápisu klesla z 240 na 35 milisekund a resharding proběhl po částech během tří nocí.
// před: rostoucí klíč = horký shard sh.shardCollection("chat.messages", { _id: 1 }) // po: hash podle kanálu, dotazy míří na jeden shard sh.shardCollection("chat.messages", { channel_id: "hashed" }) db.messages.find({ channel_id: 8842 }).sort({ created_at: -1 }).limit(50)Fan-out dotaz v reportingu e-shopu
Marketingové oddělení e-shopu požadovalo denní přehled obratu podle produktových kategorií, ale objednávky byly rozdělené podle customer_id na dvanáct shardů. Report bez shard key znamenal fan-out na všechny uzly a běžel přes dvacet minut, přičemž blokoval provozní dotazy. Řešením nebyl resharding, ale oddělený analytický sklad: noční replikace agregovala data ze všech shardů do samostatné analytické databáze. Report se zkrátil na necelou minutu a produkční shardy zůstaly vyhrazené pro zákaznické dotazy.
Časté omyly
- MýtusSharding je totéž co replikace.
- Ve skutečnostiReplikace vytváří kopie stejných dat na více uzlech. Sharding rozděluje datovou sadu na různé části, takže každý shard typicky drží jen část záznamů.
- MýtusStačí shardovat podle ID a databáze se vyřeší sama.
- Ve skutečnostiRostoucí ID může soustředit nové zápisy na jeden shard, pokud se používá rozsahové dělení. Shard key musí odpovídat distribuci dat i dotazům aplikace.
- MýtusSharding vždy zrychlí databázi.
- Ve skutečnostiSharding zrychlí jen zátěž, kterou lze dobře rozdělit. Dotazy přes více shardů, transakce napříč uzly a globální agregace mohou být pomalejší než v jedné dobře navržené databázi.
Časté dotazy
- Kdy má sharding smysl pro jednu rostoucí databázi?
- Sharding má smysl ve chvíli, kdy optimalizace dotazů, indexy, výkonnější server, cache, read repliky nebo běžný partitioning nestačí. Rozhodnutí by mělo vycházet z měření, ne z předčasné architektury. Sharding přidává směrování dotazů, složitější obnovu po chybě a náročnější změny datového modelu, takže u menších systémů často prodraží provoz víc, než pomůže výkonu.
- Proč je shard key u shardingu tak důležitý?
- Shard key určuje, kam systém uloží záznam a kam později pošle dotaz. Nevhodný shard key způsobí nerovnoměrné rozdělení dat, horké shardy nebo zbytečné dotazy přes celý cluster. Správný shard key musí vycházet z reálných přístupových vzorců: jak aplikace zapisuje, jak hledá jednotlivé záznamy a jak často potřebuje rozsahové nebo agregační dotazy.
- Kdy sharding nahrazuje partitioning v jedné databázi?
- Sharding obvykle rozděluje data mezi více samostatných uzlů, zatímco partitioning může probíhat uvnitř jedné databázové instance. Partitioning často pomáhá správě velkých tabulek, indexům a mazání starých dat. Sharding přichází ke slovu tehdy, když jeden uzel nestačí výkonem, úložištěm nebo dostupností a systém musí zátěž roznést fyzicky nebo logicky mezi více strojů.
- Co znamená resharding a proč bývá rizikový?
- Resharding znamená změnu pravidel, podle kterých jsou data rozdělená mezi shardy. Resharding může být potřeba při přidání nových uzlů, při špatně zvoleném shard key nebo při změně provozního zatížení. Operace je náročná, protože přesouvá data, upravuje směrovací metadata a musí hlídat, aby aplikace během přesunu nečetla neúplný nebo nekonzistentní stav.
Zdroje
- Sharding(otevře se v novém okně)
- What Is Database Sharding?(otevře se v novém okně)
- Partitioning and horizontal scaling in Azure Cosmos DB(otevře se v novém okně)
- Table Partitioning(otevře se v novém okně)
Související pojmy
