Vzorec horizontálního dělení

Rozdělit úložiště dat do sady horizontálních oddílů nebo shardů. Tento přístup může zlepšit škálovatelnost při ukládání a přístupu k velkým objemům dat.

Kontext a problém

Úložiště dat na jednom serveru má následující omezení:

Prostor úložiště: Úložiště dat pro rozsáhlé cloudové aplikace může obsahovat velký objem dat, která se v průběhu času rozrůstá. Server poskytuje omezené množství diskového úložiště a stávající disky můžete nahradit většími disky nebo přidávat další disky s rostoucími datovými svazky. Systém nakonec dosáhne limitu, kdy nemůžete zvýšit kapacitu úložiště na jednom serveru.
Výpočetní prostředky: Cloudová aplikace musí podporovat velký počet souběžných uživatelů, kteří každý spouští dotazy na úložiště dat. Jeden server nemusí poskytnout dostatek výpočetního výkonu pro toto zatížení, což vede k delší době odezvy a vypršení časových limitů. Můžete přidat paměť nebo upgradovat procesory, ale systém dosáhne limitu, kdy už nemůžete zvýšit výpočetní prostředky.
Šířka pásma sítě: Rychlost, s jakou může jeden server přijímat požadavky a posílat odpovědi, omezuje výkon úložiště dat. Objem síťového provozu může překročit kapacitu síťového připojení, což má za následek neúspěšné požadavky.
Geografie: Právní požadavky, dodržování předpisů nebo výkonu můžou vyžadovat uložení uživatelských dat ve stejné geografické oblasti jako uživatelé. Pokud uživatelé překlenují mezi zeměmi nebo oblastmi, možná nebudete moct ukládat všechna data aplikace do jednoho úložiště dat.

Pokud chcete tato omezení dočasně odložit, můžete vertikálně škálovat přidáním kapacity disku, výpočetního výkonu, paměti a síťových připojení. Cloudová aplikace, která musí podporovat velký počet uživatelů a velké objemy dat, se musí škálovat horizontálně.

Řešení

Rozdělte úložiště dat do horizontálních oddílů nebo fragmentů. Každý shard má stejné schéma, ale obsahuje vlastní podmnožinu dat. Každý fragment je kompletní úložiště dat, které může obsahovat data pro různé entity a typy. Shard běží na serveru, který funguje jako úložný uzel.

Tento model má tyto výhody:

Systém můžete škálovat přidáním dalších shardů na další úložné uzly.
Systém může pro každý uzel úložiště místo specializovaných a drahých počítačů používat předem připravený hardware.
Můžete snížit konkurenci a vylepšit výkon rozložením zátěže mezi shardy.
V cloudu se shardy můžou fyzicky nacházet blízko uživatelů přistupujících k datům.

Když rozdělíte úložiště dat na horizontální oddíly, rozhodněte se, která data se mají umístit do každého horizontálního oddílu. Každý shard obvykle obsahuje položky seskupené podle jednoho nebo více atributů dat. Tyto atributy tvoří klíč shardu, někdy označovaný jako klíč oddílu.

Při horizontálním dělení se data fyzicky uspořádají. Když aplikace ukládá a načítá data, logika horizontálního dělení je směruje na příslušný horizontální oddíl. Tuto logiku můžete implementovat v kódu přístupu k datům aplikace nebo v systému úložiště dat, pokud transparentně podporuje horizontální dělení.

Abstrakce fyzického umístění dat v logice horizontálního dělení poskytuje kontrolu nad tím, které horizontální oddíly obsahují která data. Můžete také migrovat data mezi horizontálními oddíly, aniž byste museli upravovat obchodní logiku aplikace, když potřebujete distribuovat data, například když se horizontální oddíly stanou nevyvážené. Kompromisem je dodatečné režijní náklady na přístup k datům, které určují umístění jednotlivých datových položek během načítání.

Výběr sdíleného klíče

Klíč horizontálního dělení je nejdůležitějším rozhodnutím o návrhu v horizontálně děleném systému. Pokud chcete po zvolení změnit klíč fragmentu, musíte obvykle migrovat všechna data do nového rozložení fragmentů, což je nákladná a riziková operace v běžícím systému. Před napsáním jakéhokoli kódu toto rozhodnutí pečlivě proveďte.

Efektivní shardový klíč je neměnný, má vysokou kardinalitu, distribuuje data a zátěž rovnoměrně a odpovídá vašim dominantním vzorcům dotazů, aby se většina požadavků vyřešila v rámci jednoho shardu. Vyhněte se monotonicky rostoucím hodnotám (automatické přírůstky celých čísel a sekvenční časová razítka), atributům nízké kardinality (booleanům a malým sadám výčtů) a nestálým atributům, které se často mění. Tyto atributy vedou k hotspotům nebo nákladnému přesunu dat napříč horizontálními oddíly.

Pokud žádný atribut nesplňuje tato kritéria, definujte složený klíč kombinací dvou nebo více atributů. Pokud dotazy potřebují načíst data podle atributů, které nejsou součástí shardového klíče, použijte vzor indexové tabulky k poskytnutí sekundárního vyhledávání.

Další informace o tom, jak zvolit klíče oddílů napříč službami Azure, najdete v pokynech k dělení dat a strategiích dělení dat.

Strategie horizontálního dělení

Při výběru shard klíče použijte jednu z následujících strategií a rozhodněte se, jak distribuovat data mezi shardy. Nepotřebujete korespondenci 1:1 mezi fragmenty a servery, které je hostují. Jeden server může hostovat více shardů.

Strategie horizontálního dělení vyhledávání

Ve vyhledávací strategii označované také jako strategie založené na adresáři implementuje logika horizontálního dělení mapu, která směruje požadavek na data do horizontálního oddílu, který tato data obsahuje pomocí klíče horizontálního dělení. Ve víceklientské aplikaci můžete všechna data nájemníka uložit společně do shardu pomocí ID nájemníka jako klíče shardu. Více nájemců může sdílet stejný shard, ale data pro jednoho nájemce nejsou rozprostřena mezi více shardy. Následující diagram znázorňuje horizontální dělení dat tenanta na základě ID tenanta.

Mapování mezi hodnotami shardovacích klíčů a fyzickým úložištěm může být přímé, kde se každá hodnota shardovacího klíče mapuje na fyzický oddíl. Flexibilnější technikou je virtuální rozdělování, kde se hodnoty shard klíčů mapují na virtuální shardy a systém pak tyto virtuální shardy mapuje na menší počet fyzických oddílů. Aplikace vyhledá data pomocí hodnoty klíče horizontálního oddílu, která odkazuje na virtuální horizontální oddíl, a systém transparentně mapuje virtuální horizontální oddíly na fyzické oddíly. Mapování mezi virtuálním shardem a fyzickou particí lze změnit bez potřeby upravovat kód aplikace.

Strategie horizontálního dělení na základě rozsahu

Strategie založená na rozsahu seskupí související položky ve stejném datovém shardu a seřadí je podle sekvenčního shard klíče. Tato strategie podporuje aplikace, které často načítají sady položek pomocí dotazů na rozsah. Dotazy rozsahu vrací sadu datových položek pro shardový klíč spadající do daného rozsahu.

Pokud například aplikace pravidelně potřebuje najít všechny objednávky zadané v daném měsíci, můžete data načíst rychleji, pokud ukládáte všechny objednávky za měsíc v pořadí data a času ve stejném horizontálním oddílu. Pokud ukládáte každou objednávku v jiném shardu, musí je aplikace načíst jednotlivě provedením velkého počtu bodových dotazů. Následující diagram znázorňuje sekvenční sady nebo rozsahy dat uložených ve shardech.

V tomto příkladu je rozdělovaící klíč složeným klíčem, který obsahuje měsíc objednávky jako nejvýznamnější prvek, následovaný dnem a časem. Nové objednávky jsou automaticky seřazeny, jakmile jsou vytvořeny a přidány do fragmentu.

Některá úložiště dat podporují klíče horizontálního dělení na dvě části. Klíč oddílu identifikuje fragment, a klíč řádku jednoznačně identifikuje položku v rámci tohoto fragmentu. Fragment obvykle ukládá data podle klíče řádku. U položek, pro které jsou potřeba dotazy na rozsah a které musí být seskupeny dohromady, můžete použít shardovací klíč se stejnou hodnotou pro klíč oddílu, ale s jedinečnou hodnotou pro klíč řádku.

Strategie dělení na základě hashování

Strategie založená na hashování snižuje pravděpodobnost vzniku přetížených segmentů, což jsou části systému, které přijímají neúměrné zatížení. Tato strategie distribuuje data mezi horizontální oddíly a vyrovnává velikost jednotlivých horizontálních oddílů a průměrné zatížení, se kterým se jednotlivé horizontální oddíly setkávají. Logika horizontálního dělení, která počítá horizontální oddíl pro uložení položky, je založená na hodnotě hash jednoho nebo více atributů dat. Zvolená funkce hash by měla rovnoměrně distribuovat data napříč shardy. Následující diagram znázorňuje horizontální dělení dat tenanta na základě hodnoty hash ID tenanta.

Abyste pochopili výhodu strategie hash oproti jiným strategiím horizontálního dělení, zvažte, jak může víceklientská aplikace, která registruje nové tenanty postupně, přiřazovat tenanty ke horizontálním oddílům v úložišti dat. Při použití strategie rozsahu se data pro tenanty 1 až n ukládají v horizontálním oddílu A, data pro tenanty n+1 na m se ukládají v horizontálních oddílech B a později se rozsahy tenantů mapují na následné horizontální oddíly. Pokud jsou aktuálně zaregistrovaní uživatelé také nejaktivnější, většina aktivity dat se odehrává v několika datových segmentech, což může způsobit místa s intenzivním zatížením. Naproti tomu strategie hash přiděluje tenanty shardům na základě hodnoty hash jejich ID tenanta. Hash obvykle distribuuje následující tenancy napříč různými shardami, což vyrovnává zatížení. Předchozí diagram znázorňuje tento přístup pro tenanty 55 a 56.

Strategie geografického horizontálního dělení

Geografická strategie přiřazuje data horizontálním oddílům na základě geografického původu nebo zamýšlené oblasti spotřeby těchto dat. V mnoha úlohách jsou uživatelé a data, která generují, soustředěny v konkrétních oblastech. Zákonné požadavky, jako jsou zákony o rezidenci dat, můžou vyžadovat, aby konkrétní data zůstala v konkrétní jurisdikci. I bez regulačních faktorů se umístění dat blízko uživatelům, kteří k němu přistupují, nejčastěji snižuje latenci sítě pro čtení a zápisy.

V této strategii odvodíte klíč fragmentu z geografického atributu, jako je země/region uživatele, původní region datacentra nebo regionální identifikátor tenanta. Každý shard hostujete nebo ho připnete do infrastruktury v rámci dané geografické hranice.

Například aplikace, která obsluhuje zákazníky v Severní Americe, Evropě a Asie-Pacifik. Může zachovávat tři shardové skupiny, jednu skupinu v každé odpovídající oblasti Azure. Evropská aplikace, která slouží pouze evropským uživatelům, směruje požadavek na evropský shard. Tento přístup snižuje latenci a splňuje požadavky na rezidenci dat.

Geografické horizontální dělení představuje riziko nerovnoměrného rozdělení dat. Pokud se většina uživatelů nachází v jedné oblasti, má shard této oblasti nepřiměřený podíl na zatížení a úložišti dat. Geografickou fragmentaci můžete kombinovat s jinou strategií, například vyhledáváním nebo hashováním, v rámci každé oblasti a rovnoměrně distribuovat zatížení napříč několika fragmenty uvnitř stejné geografické hranice.

Výhody a důležité informace pro každou strategii

Čtyři strategie horizontálního dělení mají následující výhody a aspekty:

Strategie vyhledávání poskytuje větší kontrolu nad konfigurací shardů. Virtuální oddíly snižují dopad vyrovnávání, protože můžete přidat nové fyzické oddíly k vyvážení pracovní zátěže. Mapování mezi virtuálním horizontálním oddílem a jeho fyzickými oddíly můžete upravit, aniž by to ovlivnilo kód aplikace. Hledání umístění shardů zvyšuje režii.
Strategie rozsahu se snadno implementuje a dobře funguje s dotazy rozsahu. Dotazy na rozsah mohou načíst více datových položek z jednoho úložiště v jedné operaci. Správa dat je jednodušší. Můžete například naplánovat aktualizace podle časového pásma, když uživatelé ve stejné oblasti sdílejí shard, na základě vzorců místního zatížení. Tato strategie ale nevyvažuje zatížení napříč shardy. Vyrovnávání je obtížné a nemusí vyřešit nerovnoměrné zatížení, když se většina aktivit soustředí na těchto sousedních klíče shardu.
Strategie hash poskytuje lepší šanci na rovnoměrné rozdělení dat a zatížení. Žádosti můžete směrovat přímo pomocí funkce hash bez údržby mapy. Výpočet hashe zvyšuje režii. Vyrovnávání je obtížné bez konzistentního hashování.
Geografická strategie splňuje požadavky na rezidenci dat a suverenitu, které ostatní strategie svou podstatou neřeší. Snižuje latenci čtení a zápisu, když uživatelé přistupují k datům ve své oblasti. Geografické horizontální dělení ale může způsobit významnou nerovnováhu dat a zatížení, pokud se populace uživatelů rovnoměrně nerozdělují napříč oblastmi. Dotazy, které zahrnují regiony, jako je globální generování sestav, musí načítat data ze všech geografických fragmentů a mít vyšší latenci. Pokud potřebujete dodržování předpisů i distribuci zatížení, zkombinujte geografické horizontální dělení s jinou strategií v každé oblasti.

Většina systémů horizontálního dělení implementuje jeden z těchto přístupů, měli byste ale zvážit i obchodní požadavky vaší aplikace a jejich vzorů využití dat. Například ve víceklientských aplikacích:

Můžete data shardingovat na základě zatížení systému. Oddělte data pro vysoce nestálé tenanty v samostatných shardech za účelem zlepšení rychlosti přístupu k datům pro ostatní tenanty.
Data můžete rozdělovat na základě umístění nájemníka. Uveďte data tenanta v konkrétní geografické oblasti offline pro zálohování a údržbu během doby mimo špičku této oblasti, i když data tenanta v jiných oblastech zůstávají online během pracovní doby jejich regionů.
Přiřaďte vysoce ceněným nájemcům vlastní vyhrazené a mírně načtené datové shardy. Nízko hodnotní nájemníci mohou sdílet hustěji uspořádané shardy.
Ukládejte data pro tenanty, kteří potřebují silnou izolaci dat a ochranu osobních údajů na samostatných serverech.

Operace škálování a přesunu dat pro každou strategii

Každá strategie horizontálního dělení poskytuje různé možnosti a úrovně složitosti pro správu škálování dovnitř a ven, přesunu dat a údržby stavu.

Strategie vyhledávání umožňuje operace škálování a přesunu dat na úrovni uživatele, a to buď online, nebo offline. Přesunutí dat:
1. Pozastavit některé nebo všechny aktivity uživatelů, obvykle během období mimo špičku.
2. Přesuňte data do nového virtuálního oddílu nebo fyzického segmentu.
3. Aktualizujte mapování.
4. Zneplatnění nebo aktualizace všech mezipamětí, které obsahují tato data.
5. Obnovení aktivity uživatelů
Tuto operaci můžete často spravovat centrálně. Strategie vyhledávání vyžaduje, aby byl stav vysoce ukládatelný do mezipaměti a přívětivý k replikám.
Strategie rozsahu omezuje operace škálování a přesunu dat, protože je nutné rozdělit a sloučit data napříč horizontálními oddíly, obvykle když je část nebo všechna úložiště dat offline. Když přesunete data k obnovení rovnováhy shardů, možná neodstraníte nerovnoměrné zatížení, pokud se většina aktivit soustředí na sousední klíče shardů nebo identifikátory dat ve stejném rozsahu. Strategie rozsahů může také vyžadovat stav pro mapování rozsahů na fyzické oddíly.
Strategie hash komplikuje operace škálování a přesunu dat. Klíče oddílů jsou hashy klíčů shardů nebo identifikátorů dat. Při použití standardní hashovací funkce, jako je hash(key) mod N, přidání nebo odebrání shardu přerozdělí většinu klíčů a spustí migraci velkého objemu dat. Konzistentní hashování snižuje dopad tím, že uspořádává hashovací prostor tak, aby se při změně počtu shardů přesunul pouze malý zlomek klíčů. Strategie hash nevyžaduje údržbu samostatného stavu mapování.
Geografická strategie přímo propojuje operace škálování na zřizování regionální infrastruktury. Přidání kapacity v jedné oblasti nezmírní zatížení v jiné oblasti. Zákonné požadavky, které vyžadují geografické horizontální dělení, můžou také omezit přesun dat napříč geografickými hranicemi. Škálování v rámci každé oblasti používá sekundární strategii, která distribuuje data napříč horizontálními oddíly dané oblasti.

Problémy a důležité informace

Při rozhodování o implementaci tohoto modelu zvažte následující body:

Používejte sharding jako doplněk k jiným formám dělení, jako je vertikální dělení a funkční dělení. Například jeden horizontální oddíl může obsahovat svisle dělené entity a můžete implementovat funkční oddíl jako více horizontálních oddílů. Další informace najdete v tématu Horizontální, svislé a funkční dělení dat.
Udržujte shardy vyvážené, aby všechny mohly zpracovávat podobný objem vstupu a výstupu (I/O). Nerovnováha dat se v průběhu času hromadí během vkládání a mazání záznamů, což vede ke vzniku hotspotů. Naplánujte pravidelné vyrovnávání.

Přebalancování přesouvá data mezi shardy a často způsobuje výpadky nebo snížení propustnosti. Pokud chcete obnovit rovnováhu méně často, použijte virtuální oddíly. Je možné mapovat mnoho logických oddílů na méně fyzických shardů. Pokud je shard přetížen, redistribuujte jeho virtuální oddíly do nových fyzických shardů, aniž byste rehashovali celou datovou sadu. Azure Cosmos DB používá tento přístup k oddělení schématu oddílů od fyzické infrastruktury.

Upřednostněte mnoho malých shardů před několika velkými shardami. Menší shardy migrují rychleji, vyrovnávají zatížení rovnoměrněji a poskytují větší flexibilitu pro redistribuci dat.
Pro klíč horizontálního oddílu použijte stabilní data. Pokud se klíč horizontálního oddílu změní, možná budete muset přesunout odpovídající datovou položku mezi horizontálními oddíly, což zvyšuje režijní náklady na operace aktualizace. Vyhněte se nastavovat klíč horizontálního oddílu pomocí potenciálně nestálých informací. Zvolte atributy, které jsou invariantní nebo přirozeně tvoří klíč.
Klíče shardu musí být unikátní. Jako klíč shardu například nepoužívejte pole s automatickým přírůstkem. V některých systémech se automaticky inkrementovaná pole nemohou koordinovat napříč shardy, což může vést k tomu, že položky v různých shardech mají stejný shardový klíč.

Poznámka:

Automaticky inkrementované hodnoty v jiných polích, která nejsou klíči horizontálního dělení, mohou také způsobit problémy. Pokud například k vygenerování jedinečných ID použijete pole s automatickým přírůstkem, můžou být stejné ID přiřazeny dvěma různými položkami v různých shardech.
Shardujte data tak, aby podporovala nejčastěji prováděné dotazy. Možná nebudete schopni navrhnout klíč horizontálního dělení, který by vyhovoval požadavkům všech dotazů nad daty. V případě potřeby vytvořte sekundární indexové tabulky, které podporují dotazy, jež získávají data podle atributů, které nejsou součástí shard key. Další informace najdete v tématu Vzor tabulky indexu.
Navrhněte klíč shardu a datový model tak, aby většina operací zůstala omezena na jeden shard. Dotazy, které přistupují pouze k jednomu horizontálnímu oddílu, jsou efektivnější než dotazy, které načítají data z více horizontálních oddílů. Denormalizujte svá data tak, aby související entity, které jsou často dotazovány společně, například zákazníci a jejich objednávky, byly uloženy ve stejné shardě, čímž se sníží počet samostatných čtení.

Dotazy napříč horizontálními oddíly přidávají latenci, spotřebu prostředků a složitost. Když aplikace musí načítat data z více shardů, použijte paralelní fan-out dotazy, které se spouštějí současně na každém shardu a agregují výsledky. I v případě paralelismu určuje nejpomalejší horizontální oddíl celkovou latenci.

Návod

Pokud entita v jednom horizontálním oddílu odkazuje na entitu v jiném horizontálním oddílu, zahrňte klíč horizontálního dělení pro druhou entitu jako součást schématu první entity. Tento přístup může zlepšit výkon dotazů, které odkazují na související data napříč horizontálními oddíly.
Přehodnoťte svůj shard klíč nebo zda sharding vyhovuje vašim potřebám, pokud vaše úloha vyžaduje silnou transakční integritu napříč hranicemi shardů. Transakce napříč horizontálními oddíly představují výzvy. Distribuované koordinační protokoly, jako je dvoufázové potvrzení, přidání latence, zavedení režimů selhání a snížení propustnosti. Většina horizontálně dělených systémů zabraňuje distribuovaným transakcím a přijímá místo toho konečnou konzistenci. V tomto modelu se jednotlivé shardy aktualizují nezávisle a aplikace se zabývá dočasnými nekonzistencemi.
Ujistěte se, že prostředky dostupné pro každý uzel úložiště shardů jsou schopny zvládnout požadavky na škálovatelnost z hlediska velikosti dat a propustnosti. Další informace najdete v tématu Strategie dělení dat.
Zvažte možnost replikovat referenční data na všechny shardy. Pokud dotaz na horizontální oddíl odkazuje také na statická nebo pomalá data, přidejte tato data do horizontálního oddílu. Aplikace pak může načíst všechna data pro dotaz, aniž by musela cestovat do samostatného úložiště dat.

Poznámka:

Pokud se referenční data uložená v několika horizontálních oddílech změní, musí systém tyto změny synchronizovat napříč všemi horizontálními oddíly. Během spuštění této synchronizace může dojít k určité míře nekonzistence. Navrhněte aplikace tak, aby tolerovala nekonzistence.
Systémy s fragmentací znásobují provozní zátěž. Připravte se na tyto obavy:
- Sledování: Abyste získali kompletní přehled o stavu systému, musíte agregovat metriky a protokoly napříč všemi shardami.
- Zálohování a obnovení: Pokud chcete zachovat konzistenci napříč horizontálními oddíly, musíte zálohovat jednotlivé horizontální oddíly nezávisle a navrhnout postupy obnovení. Obnovení jednoho shardu na konkrétní časový bod může způsobit nesrovnalosti s jinými shardy.
- Změny schématu: Je nutné koordinovat změny v jazyce DDL (Data Definition Language) napříč každým shardem.
Tyto úlohy můžete implementovat pomocí skriptů nebo jiných řešení automatizace.
Datové fragmenty můžete geograficky přidělit tak, aby byla jejich data umístěna do blízkosti instancí aplikace, které je používají. Tento přístup může zvýšit výkon, ale vyžaduje dodatečné plánování operací, které musí přistupovat k více shardům na různých místech.

Kdy použít tento vzor

Návod

Než navrhnete vlastní vrstvu horizontálního dělení, určete, které odpovědnosti za horizontální dělení už vaše datová platforma zpracovává. Některé služby zcela spravují shardování. Azure Cosmos DB například distribuuje data mezi fyzické oddíly, zpracovává rozdělení a směruje dotazy bez zapojení aplikace. Jiné služby spravují shardování částečně. Azure SQL Database například poskytuje elastické databázové nástroje pro správu mapování shardu a směrování závislé na datech, ale navrhujete shard klíč a spravujete operace dělení. Model horizontálního dělení použijte při sestavování a provozu logiky horizontálního dělení sami.

Tento model použijte v těchto případech:

Celkový objem dat překračuje kapacitu úložiště jedné instance databáze a žádná možnost vertikálního škálování neřeší nedostatek.
Propustnost transakcí nebo souběžnost dotazů překračuje, co může jedna instance udržovat, a samotné repliky pro čtení problém nevyřeší, protože zatížení zápisu je také vysoké.

Poznámka:

Horizontální dělení zlepšuje výkon a škálovatelnost systému a může také zlepšit dostupnost. Selhání v jednom oddílu nemusí nutně bránit aplikaci v přístupu k datům v jiných oddílech. Operátor může provádět údržbu nebo obnovení jednoho oddílu, aniž by byla všechna data nedostupná. Další informace najdete v doprovodných materiálech k dělení dat.
Zákonné požadavky nebo požadavky na dodržování předpisů vyžadují, aby se konkrétní podmnožina dat nacházejí v konkrétních geografických jurisdikcích a žádné nasazení v jedné oblasti nesplní všechny požadavky.
Odlišné tenanty nebo segmenty zákazníků vyžadují fyzickou izolaci dat z bezpečnostních, výkonnostních nebo smluvních důvodů.

V podobných scénářích se model horizontálního dělení někdy používá mimo tradiční úložiště dat. Například systém správy zón DNS může být rozdělený podle týmu, prostředí nebo regionu, aby se snížil dopad změn DNS a vytvořily se jasné hranice vlastnictví. V tomto kontextu je primární motivací provozní segmentace místo škálovatelnosti. Další informace najdete v tématu Horizontální dělení privátních zón DNS.

Sharding přináší do architektury dat podstatnou a trvalou složitost. Tato složitost ovlivňuje vývoj, operace, testování, návrh dotazů a obnovení po selhání po celou dobu životního cyklu systému.

Tento vzor nemusí být vhodný v těchto případech:

Objem dat a propustnost se vejdou do jedné instance databáze, a to i v případě předpokládaného růstu. Vertikální škálování zachovává jednoduchost dotazů a transakční integritu.
Kritickým bodem je objem pro čtení, ne objem zápisu ani kapacita úložiště. Repliky pro čtení a vrstvy cache mohou zmírnit zatížení čtecích operací bez složitosti dotazů napříč shardami, které horizontální dělení zavádí.
Databázový stroj podporuje dělení na úrovni tabulky, které splňuje vaše požadavky na výkon. Dělení v rámci jedné instance nevyžaduje více serverů ani logiku směrování.
Vaše dominantní vzory dotazů vyžadují propojování mezi entitami, transakce mezi více entitami nebo agregace celého datového souboru. Horizontální dělení tyto operace činí nákladnými a režijní náklady dotazů typu fan-out a distribuované koordinace mohou převážit nad výhodami škálování.

Návrh úloh

Vyhodnoťte, jak použít model horizontálního dělení v návrhu úlohy k řešení cílů a principů popsaných v pilířích architektury Azure Well-Architected Framework. Následující tabulka obsahuje pokyny, jak tento model podporuje cíle jednotlivých pilířů.

Pilíř	Jak tento model podporuje cíle pilíře
Spolehlivostní rozhodnutí o návrhu pomáhají vaší pracovní zátěži stát se odolná proti poruchám a zajistit, aby se po selhání obnovila do plně funkčního stavu.	Data a zpracování jsou izolovaná v shardu, takže selhání v jednom shardu zůstává izolované v tomto shardu. - Dělení dat - RE:07 Sebezáchování
Optimalizace nákladů se zaměřuje na udržení a zlepšenínávratnosti vašich úloh.	Systém, který implementuje shardy, často těží z použití několika instancí levnějších výpočetních a úložných prostředků místo jednoho nákladnějšího prostředku. V mnoha případech vám tato konfigurace může ušetřit peníze. - CO:07 Náklady na komponenty
efektivita výkonu pomáhá vašim úlohám efektivně splňovat požadavky prostřednictvím optimalizací škálování, dat a kódu.	Při použití šardování ve vaší strategii škálování jsou data a zpracování izolovaná pro každý šard, takže požadavky soutěží pouze o prostředky v rámci jejich přiřazeného šardu. Horizontální dělení můžete použít také k optimalizaci na základě zeměpisné polohy. - PE:05 Škálování a dělení - PE:08 Výkon dat

Pokud tento model představuje kompromisy v rámci pilíře, zvažte je proti cílům ostatních pilířů.

Příklad

Představte si web, který poskytuje rozsáhlé kolekce informací o publikovaných knihách po celém světě. Počet možných knih katalogovaných v této úloze a typické vzory dotazů a použití překračují, co dokáže zpracovat jedna relační databáze. Architekt úloh se rozhodne rozdělit data napříč několika instancemi databáze pomocí statického ISBN knihy jako klíče pro dělení. Konkrétně architekt používá kontrolní číslici (0–10) kódu ISBN, která poskytuje 11 možných logických shardů s poměrně vyváženou distribucí dat.

Začněme tím, že architekt umísťuje 11 logických fragmentů do tří fyzických databází fragmentů. V tomto přístupu k virtuálním oddílům se mnoho logických oddílů mapuje na méně fyzických uzlů. Architekt používá přístup shardování vyhledávání a ukládá mapování klíčů na server v databázi mapování shardů.

Diagram znázorňující horizontálně dělenou architekturu služby SQL Database pro aplikaci katalogu knih

Mapa horizontálních oddílů vyhledávání

Databáze mapování horizontálních oddílů obsahuje následující tabulku a data mapování horizontálních oddílů.

SELECT ShardKey, DatabaseServer
FROM BookDataShardMap

| ShardKey | DatabaseServer |
|----------|----------------|
|        0 | bookdbshard0   |
|        1 | bookdbshard0   |
|        2 | bookdbshard0   |
|        3 | bookdbshard1   |
|        4 | bookdbshard1   |
|        5 | bookdbshard1   |
|        6 | bookdbshard2   |
|        7 | bookdbshard2   |
|        8 | bookdbshard2   |
|        9 | bookdbshard0   |
|       10 | bookdbshard1   |

Ukázkový kód webu: přístup k jednomu oddílu

Web neví, kolik fyzických shard databází existuje (v tomto případě tři) nebo logika, která mapuje klíč shardu na instanci databáze. Jen ví, že kontrolní číslice ISBN knihy je klíč horizontálního dělení. Webová stránka má přístup jen pro čtení k databázi mapování shardů a přístup pro čtení i zápis ke všem databázím shardů. V tomto příkladu používá web identitu spravovanou systémem svého hostitele služby Azure App Service k autorizaci, která uchovává tajné kódy mimo připojovací řetězce.

Web je nakonfigurovaný s následujícími připojovacími řetězci v appsettings.json souboru, jak je znázorněno v tomto příkladu, nebo prostřednictvím nastavení aplikace služby App Service.

{
  ...
  "ConnectionStrings": {
    "ShardMapDb": "Data Source=tcp:<database-server-name>.database.windows.net,1433;Initial Catalog=ShardMap;Authentication=Active Directory Default;App=Book Site v1.5a",
    "BookDbFragment": "Data Source=tcp:SHARD.database.windows.net,1433;Initial Catalog=Books;Authentication=Active Directory Default;App=Book Site v1.5a"
  },
  ...
}

Následující kód ukazuje, jak web spouští aktualizační dotaz na fragmenty databáze úlohy v jejich shard poolu.

...

// All data for this book is stored in a shard based on the book's ISBN check digit,
// which is converted to an integer 0 - 10 (special value 'X' becomes 10).
int isbnCheckDigit = book.Isbn.CheckDigitAsInt;

// Establish a pooled connection to the database shard for this specific book.
using (SqlConnection sqlConn = await shardedDatabaseConnections.OpenShardConnectionForKeyAsync(key: isbnCheckDigit, cancellationToken))
{
  // Update the book's Library of Congress catalog information.
  SqlCommand cmd = sqlConn.CreateCommand();
  cmd.CommandText = @"UPDATE LibraryOfCongressCatalog
                         SET ControlNumber = @lccn,
                             ...
                             Classification = @lcc
                       WHERE BookID = @bookId";

  cmd.Parameters.AddWithValue("@lccn", book.LibraryOfCongress.Lccn);
  ...
  cmd.Parameters.AddWithValue("@lcc", book.LibraryOfCongress.Lcc);
  cmd.Parameters.AddWithValue("@bookId", book.Id);

  await cmd.ExecuteNonQueryAsync(cancellationToken);
}

...

V předchozím příkladu kódu, pokud book.Isbn byl 978-8-1130-1024-6, pak isbnCheckDigit by měl být 6. Volání OpenShardConnectionForKeyAsync(6) se obvykle implementuje pomocí přístupu typu cache-aside. Pokud nejsou v mezipaměti k dispozici informace o shardu pro klíč shardu 6, metoda se dotazuje na databázi mapování shardů identifikovanou připojovacím řetězcem ShardMapDb. Metoda načte hodnotu bookdbshard2 z mezipaměti aplikace nebo shardovací databáze a nahradí ji v připojovacím řetězci SHARD na místo BookDbFragment. Metoda pak vytvoří nebo obnoví sdružené připojení k bookdbshard2.database.windows.net, otevře ho a vrátí k volajícímu kódu. Kód pak aktualizuje existující záznam pro danou instanci databáze.

Ukázkový kód webu: přístup k více shardům

Ve výjimečných případech, kdy web přímo vyžaduje dotaz napříč shardami, aplikace provede paralelní fan-out dotaz napříč všemi shardami.

...

// Retrieve all shard keys.
var shardKeys = shardedDatabaseConnections.GetAllShardKeys();

// Run the query in a fan-out style against each shard in the shard list.
Parallel.ForEachAsync(shardKeys, async (shardKey, cancellationToken) =>
{
  using (SqlConnection sqlConn = await shardedDatabaseConnections.OpenShardConnectionForKeyAsync(key: shardKey, cancellationToken))
  {
    SqlCommand cmd = sqlConn.CreateCommand();
    cmd.CommandText = @"SELECT ...
                          FROM ...
                         WHERE ...";

    SqlDataReader reader = await cmd.ExecuteReaderAsync(cancellationToken);

    while (await reader.ReadAsync(cancellationToken))
    {
      // Collect the results into a thread-safe data structure.
    }

    reader.Close();
  }
});

...

Jako alternativu k dotazům napříč horizontálními oddíly může tato úloha použít externě udržovaný index ve službě Azure AI Search pro vyhledávání webů nebo fasetovou navigaci.

Přidat instance shardů

Tým úloh ví, že pokud se katalog dat nebo jeho souběžné využití výrazně zvětšuje, může vyžadovat více než tři databázové instance. Tým pro správu zátěže neočekává dynamické přidávání databázových serverů a přijímá výpadek zátěže, když je nový databázový oddíl online. Aby byla nová instance fragmentu online, musejí přesunout data z existujících fragmentů do nového fragmentu a aktualizovat tabulku mapování fragmentů. Díky tomuto poměrně statickému přístupu může pracovní zátěž s jistotou ukládat do mezipaměti mapování databázového klíče shard key v kódu webové stránky.

Logika klíče shardingu v tomto příkladu má horní limit 11 fyzických shardů. Pokud tým pro pracovní zátěž zjistí na základě odhadu zatížení, že nakonec vyžaduje více než 11 databázových instancí, musí provést zásadní změnu logiky klíče šardování. Tato změna zahrnuje pečlivé plánování úprav kódu a migrace dat do nové klíčové logiky.

Funkce sady SDK

Místo psaní vlastního kódu pro správu shardů a směrování dotazů k instancím služby SQL Database vyhodnoťte elastickou klientskou knihovnu databáze. Tato knihovna podporuje správu mapování horizontálních oddílů, směrování dotazů závislých na datech a dotazy napříč horizontálními oddíly v C# i Javě.

Další krok

Úrovně konzistence ve službě Azure Cosmos DB: Distribuce dat napříč shardy představuje kompromisy konzistence. Tento článek popisuje spektrum modelů konzistence od silného po konečné a jejich účinky na dostupnost a latenci.

Horizontální, vertikální a funkční dělení dat: Tento článek popisuje další strategie dělení dat v cloudu za účelem zlepšení škálovatelnosti, snížení kolizí a optimalizace výkonu.
Vzor tabulky indexu: Někdy nemůžete podporovat všechny dotazy pouze návrhem samotného shard klíče. Aplikace může pomocí vzoru Index Table načíst data z velkého úložiště dat zadáním klíče jiného než klíče horizontálního oddílu.
Model materializovaného zobrazení: Pokud chcete zachovat výkon některých operací dotazů, můžete vytvořit materializovaná zobrazení, která agregují a shrnují data, zejména pokud tato data distribuujete mezi horizontální oddíly.

Váš názor

Byla tato stránka užitečná?

Last updated on 2026-04-03