Doporučení pro dělení dat

Článek
11/15/2023

Platí pro toto doporučení kontrolního seznamu pro spolehlivost architektury Azure Well-Architected:

RE:06	Implementujte včasnou a spolehlivou strategii škálování na úrovni aplikace, dat a infrastruktury.

Související průvodce:Škálování

Tato příručka popisuje doporučení pro návrh strategie dělení dat pro nasazenou technologii databáze a úložiště dat. Tato strategie vám pomůže zlepšit spolehlivost vašich datových aktiv.

Klíčové strategie návrhu

V mnoha rozsáhlých řešeních se k rozdělení dat používají oddíly, aby je bylo možné spravovat a přistupovat k němu samostatně. Dělení dat zlepšuje škálovatelnost, snižuje kolize a optimalizuje výkon. Implementujte dělení dat a rozdělte data podle vzorce využití. Starší data můžete například archivovat v levném úložišti dat. Strategii dělení vybírejte pečlivě, abyste maximalizovali výhody a minimalizovali nežádoucí účinky.

Poznámka

Termín dělení v tomto článku označuje proces fyzického rozdělení dat do samostatných úložišť dat. Liší se od SQL Server dělení tabulek.

Proč dělit data?

Zlepšení škálovatelnosti. Při vertikálním navýšení kapacity jednoúčelového databázového systému databáze nakonec databáze dosáhne fyzického hardwarového limitu. Pokud rozdělíte data mezi několik oddílů, přičemž každý oddíl je hostovaný na samostatném serveru, můžete systém škálovat téměř neomezeně dlouho.
Zvýšení výkonu. V každém oddílu se operace přístupu k datům provádějí s menším objemem dat v porovnání s daty, která nejsou rozdělená na oddíly. Rozdělte data, aby byl váš systém efektivnější. Operace, které ovlivňují víc než jeden oddíl, mohou běžet paralelně.
Vylepšení zabezpečení. V některých případech můžete citlivá a nesmyslná data rozdělit do různých oddílů a použít u nich různé bezpečnostní prvky.
Zajištění provozní flexibility. Rozdělením dat můžete doladit operace, maximalizovat efektivitu správy a minimalizovat náklady. Můžete například definovat strategie správy, monitorování, zálohování a obnovení a další úlohy správy na základě důležitosti dat v jednotlivých oddílech.
Zajištění shody mezi úložištěm dat a způsobem použití. Každý oddíl můžete nasadit na jiný typ úložiště dat v závislosti na nákladech a integrovaných funkcích, které úložiště dat nabízí. Můžete například ukládat velká binární data v úložišti objektů blob a strukturovaná data do databáze dokumentů. Další informace najdete v tématu Principy modelů úložiště dat.
Zlepšení dostupnosti. Abyste se vyhnuli jedinému bodu způsobujícímu selhání, můžete data rozdělit mezi několik serverů. Pokud jedna instance selže, nebudou k dispozici pouze data v tomto oddílu. Operace budou pokračovat v jiných oddílech. To je méně relevantní pro úložiště dat spravované platformy jako služby (PaaS), protože mají integrovanou redundanci.

Návrh oddílů

Existují tři typické strategie pro dělení dat:

Horizontální dělení (označované také jako sharding). V této strategii je každý oddíl samostatné úložiště dat, ale všechny oddíly mají stejné schéma. Každý oddíl se označuje jako horizontální oddíl a obsahuje podmnožinu dat, například sadu objednávek zákazníků.
Vertikální dělení. Při použití této strategie každý oddíl obsahuje podmnožinu polí pro položky v úložišti dat. Pole jsou rozdělená podle způsobu jejich použití. Můžete například dát často používaná pole do jednoho vertikálního oddílu a méně používaná pole do jiného.
Funkční dělení. V této strategii se data agregují podle toho, jak každý ohraničený kontext v systému data používá. Systém elektronického obchodování může například ukládat data faktur v jednom oddílu a data inventáře produktů do jiného.

Při návrhu schématu dělení zvažte kombinaci těchto strategií. Můžete například rozdělit data do horizontálních oddílů a data v jednotlivých horizontálních oddílech dál rozdělit pomocí vertikálního dělení.

Horizontální dělení (sharding)

Následující obrázek ukazuje příklad horizontálního dělení neboli horizontálního dělení. Tento příklad rozdělí data inventáře produktů do horizontálních oddílů založených na kódu Product Key. Každý horizontální oddíl uchovává data pro souvislý rozsah klíčů horizontálního oddílu (A-G a H-Z) v abecedním pořadí. Když provádíte horizontální dělení, rozdělí zatížení do více počítačů, což snižuje kolize a zvyšuje výkon.

Nejdůležitějším faktorem je klíč horizontálního dělení, který zvolíte. Jakmile je systém v provozu, může být změna klíčů někdy obtížná. Klíč musí zajistit, aby byla data rozdělená na oddíly, aby se úloha rozložila co nejrovnoměrněji napříč horizontálními oddíly.

Horizontální oddíly nemusí mít stejnou velikost. Důležitější je vyrovnávat počet požadavků. Některé horizontální oddíly můžou být velké, ale každá položka v horizontálním oddílu má nízký počet přístupových operací. Jiné horizontální oddíly můžou být menší, ale ke každé položce v horizontálním oddílu se přistupuje častěji. Je také důležité zajistit, aby jeden horizontální oddíl nepřekračoval limity škálování úložiště dat z hlediska kapacity a prostředků zpracování.

Vyhněte se vytváření horkých oddílů, které můžou mít vliv na výkon a dostupnost. Pokud například použijete první písmeno jména zákazníka, může dojít k nevyvážené distribuci, protože některá písmena jsou běžnější než jiná. Místo toho použijte hodnotu hash identifikátoru zákazníka k rovnoměrné distribuci dat napříč oddíly.

Zvolte klíč horizontálního dělení, který minimalizuje budoucí potřebu rozdělit velké horizontální oddíly, zkombinovat malé horizontální oddíly do větších oddílů nebo změnit schéma. Tyto operace jsou časově náročné a můžou vyžadovat, abyste jeden nebo více horizontálních oddílů přetáli do offline režimu.

Pokud se horizontální oddíly replikují, můžete některé repliky ponechat online, zatímco jiné se rozdělí, sloučí nebo překonfigurují. Systém však může omezit operace, které je možné provádět během rekonfigurace. Například data v replikách můžou být označená jako jen pro čtení, aby se zabránilo jejich nekonzistenci.

Další informace najdete v tématu Model horizontálního dělení.

Vertikální dělení

Nejběžnějším použitím vertikálního dělení je snížení nákladů na vstupně-výstupní operace a výkon, které jsou spojené s načítáním často používaná položek. Následující obrázek ukazuje příklad vertikálního dělení. V tomto příkladu jsou různé vlastnosti položky uložené v různých oddílech. Jeden oddíl obsahuje data, ke kterým se přistupuje častěji, včetně názvu produktu, popisu a ceny. Jiný oddíl obsahuje data inventáře, včetně počtu zásob a data poslední objednávky.

V tomto příkladu se aplikace při zobrazení podrobností o produktu zákazníkům pravidelně dotazuje na název produktu, popis a cenu. Počet zásob a datum poslední objednávky jsou v samostatném oddílu, protože tyto dvě položky se běžně používají společně.

Podívejte se na následující výhody vertikálního dělení:

Relativně pomalu se pohybující data (název produktu, popis a cena) můžete oddělit od dynamičtějších dat (stav zásob a datum poslední objednávky). Pomalu se pohybující data jsou vhodným kandidátem na ukládání aplikací do mezipaměti.
Citlivá data můžete uložit do samostatného oddílu s přidanými bezpečnostními prvky.
Vertikální dělení může snížit množství souběžného přístupu, který je potřeba.

Vertikální dělení funguje v rámci úložiště dat na úrovni entit, částečně je normalizuje a dělí široké položky do sady úzkých položek. Je ideální pro sloupcová úložiště dat, jako jsou HBase a Cassandra. Pokud je nepravděpodobné, že by se data v kolekci sloupců změnila, zvažte použití úložišť sloupců v SQL Server.

Funkční dělení

Pokud je možné identifikovat ohraničený kontext pro každou jednotlivou obchodní oblast v aplikaci, funkční dělení může zlepšit izolaci a výkon přístupu k datům. Dalším běžným využitím funkčního dělení je oddělení dat pro čtení a zápis od dat jen pro čtení. Následující obrázek ukazuje přehled funkčního dělení, které obsahuje data inventáře oddělená od zákaznických dat.

Tato strategie dělení pomáhá omezit kolize přístupu k datům napříč různými částmi systému.

Návrh oddílů pro zajištění škálovatelnosti

Je důležité zvážit velikost a úlohu každého oddílu. Vyvažte je tak, aby se data distribuovala, aby se dosáhlo maximální škálovatelnosti. Musíte ale také rozdělit data tak, aby nepřekračovala limity škálování úložiště s jedním oddílem.

Při návrhu oddílů pro zajištění škálovatelnosti postupujte takto:

Analyzujte aplikaci, abyste porozuměli vzorům přístupu k datům, například velikosti sady výsledků, kterou každý dotaz vrací, frekvenci přístupu, inherentní latenci a požadavkům na zpracování výpočetních prostředků na straně serveru. V mnoha případech vyžaduje většinu prostředků zpracování několik hlavních entit.
Pomocí této analýzy můžete určit aktuální a budoucí cíle škálovatelnosti, jako je velikost dat a zatížení. Distribucí dat napříč oddíly potom splňte cíle škálovatelnosti. Pro horizontální dělení zvolte správný klíč horizontálního oddílu, který zajistí rovnoměrnou distribuci. Další informace najdete v tématu Model horizontálního dělení.
Ujistěte se, že každý oddíl má dostatek prostředků pro zvládnutí požadavků na škálovatelnost z hlediska velikosti a propustnosti dat. V závislosti na úložišti dat může být pro každý oddíl limit velikosti úložného prostoru, výpočetního výkonu nebo šířky pásma sítě. Pokud požadavky pravděpodobně překročí tato omezení, možná budete muset upřesnit strategii dělení nebo dále rozdělit data. Možná budete muset zkombinovat dvě nebo více strategií.
Monitorujte systém a ověřte, že jsou data distribuovaná podle očekávání a že oddíly zvládnou zatížení. Skutečné využití nemusí vždy odpovídat tomu, co analýza předpovídá. Možná budete muset znovu vybalancovat oddíly nebo přepracovat některé části systému, abyste dosáhli požadovaného zůstatku.

Některá cloudová prostředí přidělují prostředky na základě hranic infrastruktury. Ujistěte se, že limity vybrané hranice poskytují dostatek místa pro očekávaný nárůst objemu dat, úložiště dat, výpočetního výkonu a šířky pásma.

Pokud například používáte Azure Table Storage, existuje omezení objemu požadavků, které může jeden oddíl zpracovat v určitém časovém období. Další informace najdete v tématu Cíle škálovatelnosti a výkonu pro účty úložiště úrovně Standard. Zaneprázdněný horizontální oddíl může vyžadovat více prostředků, než dokáže zpracovat jeden oddíl. Možná budete muset oddíly horizontálního oddílu rozdělit, aby se zatížení rozložilo. Pokud celková velikost nebo propustnost těchto tabulek překročí kapacitu účtu úložiště, možná budete muset vytvořit více účtů úložiště a rozprostřít tabulky mezi tyto účty.

Návrh oddílů pro výkon dotazů

Výkon dotazů můžete zvýšit pomocí malých datových sad a spouštění paralelních dotazů. Každý oddíl by měl obsahovat malou část celé datové sady. Toto omezení objemu může zlepšit výkon dotazů. Dělení ale není alternativou k vhodnému návrhu a konfiguraci databáze. Ujistěte se, že implementujete potřebné indexy.

Při návrhu oddílů pro výkon dotazů postupujte takto:

Prozkoumejte požadavky a výkon aplikace.
- Pomocí obchodních požadavků můžete určit důležité dotazy, které musí vždy rychle provádět.
- Monitorujte systém a identifikujte dotazy, které fungují pomalu.
- Určete dotazy, které se provádějí nejčastěji. I když má jeden dotaz minimální náklady, může být kumulativní spotřeba prostředků významná.
Rozdělte data, která způsobují nízký výkon.
- Omezte velikosti jednotlivých oddílů, aby doba odezvy dotazů odpovídala cílovým hodnotám.
- Pokud používáte horizontální dělení, navrhni klíč horizontálního oddílu tak, aby aplikace snadno vybrala příslušný oddíl. Tato specifikace brání dotazu ve kontrole všech oddílů.
- Zamyslete se nad umístěním oddílu. Pokuste se uchovávat data v oddílech, které jsou geograficky blízko aplikacím a uživatelům, kteří k ní přistupují.
Pokud má entita požadavky na propustnost a výkon dotazů, použijte funkční dělení založené na této entitě. Pokud toto přidělení stále nesplňuje požadavky, můžete přidat horizontální dělení. Strategie jednoho dělení je obvykle adekvátní, ale v některých případech je efektivnější obě strategie kombinovat.
Spouštění dotazů paralelně napříč oddíly za účelem zvýšení výkonu

Návrh oddílů pro zajištění dostupnosti

Rozdělte data na oddíly, abyste zlepšili dostupnost aplikací. Dělení zajistí, že celá datová sada nebude mít jediný bod selhání, a můžete nezávisle spravovat jednotlivé podmnožina datové sady.

Vezměte v úvahu následující faktory, které mají vliv na dostupnost:

Určete důležitost dat. Identifikujte důležitá obchodní data, jako jsou transakce, a méně důležitá provozní data, jako jsou soubory protokolů.

Ukládejte důležitá data ve vysoce dostupných oddílech a vytvořte vhodný plán zálohování.
Vytvořte samostatné postupy správy a monitorování pro různé datové sady.
Umístěte data, která mají stejnou úroveň důležitosti, do stejného oddílu, aby je bylo možné zálohovat se stejnou frekvencí. Můžete například potřebovat zálohovat oddíly, které obsahují transakční data častěji než oddíly, které obsahují informace o protokolování nebo trasování.

Správa jednotlivých oddílů Navrhujte oddíly pro podporu nezávislé správy a údržby. Tento postup poskytuje několik výhod, například:

Pokud oddíl selže, je možné ho obnovit nezávisle bez aplikací, které přistupují k datům v jiných oddílech.
Rozdělení dat podle geografické oblasti umožňuje, aby úlohy plánované údržby probíhaly pro každé umístění mimo špičku. Ujistěte se, že oddíly nejsou tak velké, aby se zabránilo dokončení plánované údržby během tohoto období.

Replikace důležitých dat napříč oddíly Tato strategie zlepšuje dostupnost a výkon, ale může také představovat problémy s konzistencí. Synchronizace změn s každou replikou nějakou dobu trvá. Během synchronizace obsahují různé oddíly různé hodnoty dat.

Aspekty návrhu aplikace

Dělení zvyšuje složitost návrhu a vývoje systému. Data oddílů jako základní součást návrhu systému, i když systém zpočátku obsahuje pouze jeden oddíl. Pokud dělení řešíte jako domýšlání, je to náročné, protože už máte živý systém, který je potřeba udržovat. Můžete:

Je potřeba upravit logiku přístupu k datům.
Abyste je mohli distribuovat mezi oddíly, musíte migrovat velké objemy existujících dat.
Narazíte na problémy, protože uživatelé očekávají, že budou systém během migrace dál používat.

V některých případech není dělení důležité, protože počáteční datová sada je malá a jeden server ji může snadno zpracovat. Některé úlohy můžou být bez oddílů, ale řada komerčních systémů se musí s rostoucím počtem uživatelů rozšiřovat.

Dělení je také výhodné pro některá malá úložiště dat. Například stovky souběžných klientů můžou přistupovat k malému úložišti dat. Pokud v této situaci rozdělíte data, může to pomoct snížit kolize a zlepšit propustnost.

Při návrhu schématu dělení dat zvažte následující body:

Minimalizujte operace přístupu k datům napříč oddíly. Pokuste se uchovávat data pro nejběžnější databázové operace pohromadě v oddílu, abyste minimalizovali operace přístupu k datům napříč oddíly. Dotazování napříč oddíly může být časově náročnější než dotazování v rámci jednoho oddílu. Optimalizace oddílů pro jednu sadu dotazů ale může nepříznivě ovlivnit jiné sady dotazů. Pokud potřebujete dotazovat napříč oddíly, minimalizujte čas dotazování spuštěním paralelních dotazů a agregací výsledků v rámci aplikace. V některých případech tento přístup použít nemůžete, například pokud se v dalším dotazu použije výsledek z jednoho dotazu.

Replikace statických referenčních dat Pokud dotazy používají relativně statická referenční data, jako jsou tabulky PSČ nebo seznamy produktů, zvažte replikaci těchto dat ve všech oddílech, abyste omezili samostatné operace vyhledávání v různých oddílech. Tento přístup může také snížit pravděpodobnost, že se referenční data stanou horkou datovou sadou s velkým provozem v celém systému. Se synchronizací změn referenčních dat jsou spojené další náklady.

Minimalizujte spojení napříč oddíly. Pokud je to možné, minimalizujte požadavky na referenční integritu napříč vertikálními a funkčními oddíly. V těchto schématech je aplikace zodpovědná za udržování referenční integrity napříč oddíly. Dotazy, které spojují data napříč několika oddíly, jsou neefektivní, protože aplikace obvykle provádí po sobě jdoucí dotazy založené na klíči a potom na cizím klíči. Místo toho zvažte replikaci nebo denormalizaci relevantních dat. Pokud je potřeba připojení mezi oddíly, spusťte paralelní dotazy na oddíly a připojte data v rámci aplikace.

Zapojte konečnou konzistenci. Vyhodnoťte, jestli je požadavkem silná konzistence. Běžným přístupem v distribuovaných systémech je implementace konečné konzistence. Data v každém oddílu se aktualizují samostatně a logika aplikace zajišťuje úspěšné dokončení aktualizací. Logika aplikace také zpracovává nekonzistence, které vznikají při dotazování na data, zatímco se spouští operace, která je nakonec konzistentní.

Zvažte, jak dotazy zjišťují správný oddíl. Pokud dotaz musí prohledat všechny oddíly, aby vyhlašil požadovaná data, výrazně to ovlivní výkon, i když se spustí více paralelních dotazů. Při vertikálním a funkčním dělení můžou dotazy určit oddíl. Na druhou stranu horizontální dělení může ztížit vyhledání položky, protože každý horizontální oddíl má stejné schéma. Typickým řešením je udržovat mapu, která slouží k vyhledání umístění horizontálních oddílů položek. Implementujte tuto mapu do logiky horizontálního dělení aplikace. Pokud úložiště dat podporuje transparentní horizontální dělení, může ho také udržovat úložiště dat.

Pravidelně obnovujte vyrovnávání horizontálních oddílů. Díky horizontálnímu dělení může vyrovnávání horizontálních oddílů pomoct rovnoměrně distribuovat data podle velikosti a úlohy. Opětovné vyrovnání horizontálních oddílů za účelem minimalizace hotspotů, maximalizace výkonu dotazů a alternativního řešení omezení fyzického úložiště Tato úloha je složitá a často vyžaduje vlastní nástroj nebo proces.

Replikujte oddíly. Replikujte jednotlivé oddíly, abyste zajistili další ochranu před selháním. Pokud selže jedna replika, dotazy se směrují na funkční kopii.

Rozšiřte škálovatelnost na jinou úroveň. Pokud dosáhnete fyzických omezení strategie dělení, možná bude potřeba rozšířit škálovatelnost na jinou úroveň. Pokud například dělení probíhá na úrovni databáze, možná bude potřeba umístit nebo replikovat oddíly do více databází. Pokud už dělení probíhá na úrovni databáze a existují fyzická omezení, možná budete muset najít nebo replikovat oddíly ve více hostitelských účtech.

Vyhněte se transakcím, které přistupují k datům v několika oddílech. Některá úložiště dat implementují transakční konzistenci a integritu pro operace, které upravují data, ale pouze v případě, že se data nacházejí v jednom oddílu. Pokud potřebujete podporu transakcí napříč několika oddíly, implementujte ji jako součást logiky aplikace, protože většina systémů dělení neposkytuje nativní podporu.

Všechna úložiště dat vyžadují určité aktivity provozní správy a monitorování. Mezi tyto úlohy patří načítání dat, zálohování a obnovení dat, reorganizace dat a zajištění správného a efektivního fungování systému.

Vezměte v úvahu následující faktory, které ovlivňují provozní správu:

Implementace vhodných úloh správy a provozních úloh při dělení dat Mezi tyto úlohy může patřit zálohování, obnovení a archivace dat, monitorování systému a další úlohy správy. Může být například náročné udržovat logickou konzistenci během operací zálohování a obnovení.
Načtěte data do několika oddílů a přidejte nová data, která pocházejí z jiných zdrojů. Některé nástroje nemusí podporovat operace horizontálně dělených dat, například načítání dat do správného oddílu.
Pravidelně archivujte a odstraňujte data. Aby nedocházelo k nadměrnému růstu oddílů, archivujte a odstraňujte data každý měsíc. Možná budete muset transformovat data tak, aby odpovídala jinému schématu archivu.
Vyhledejte problémy s integritou dat. Zvažte spuštění pravidelného procesu, který vyhledá problémy s integritou dat, například data v jednom oddílu, která odkazují na chybějící informace v jiném oddílu. Proces se může buď automaticky pokusit tyto problémy opravit, nebo vygenerovat sestavu pro ruční kontrolu.

Opětovné vyrovnání oddílů

Až systém zraje, možná budete muset upravit schéma dělení. Jednotlivé oddíly například můžou začít přijímat nepřiměřený objem provozu a být horké, což může vést k nadměrným kolizím. Nebo jste mohli podcenit objem dat v některých oddílech, což způsobuje, že se oddíly blíží limitům kapacity.

Některá úložiště dat, například Azure Cosmos DB, můžou automaticky obnovit rovnováhu oddílů. V ostatních případech můžete znovu vyvážit oddíly ve dvou fázích:

Určete novou strategii dělení na oddíly.
- Které oddíly je potřeba rozdělit nebo zkombinovat?
- Co je nový klíč oddílu?
Migrujte data ze starého schématu dělení na novou sadu oddílů.

Při přemísťovaní dat může být potřeba, aby oddíly byly nedostupné, což se označuje jako offline migrace. V závislosti na úložišti dat můžete migrovat data mezi oddíly, které se používají. Tato technika se nazývá online migrace.

Offline migrace

Offline migrace snižuje riziko kolizí. Provedení offline migrace:

Označte oddíl jako offline. Oddíl můžete označit jako jen pro čtení, aby aplikace při přesouvání stále mohly číst data.
Rozdělte a sloučit a přesuňte data do nových oddílů.
Ověření dat.
Převeďte nové oddíly online.
Odeberte starý oddíl.

Online migrace

Online migrace je v porovnání s offline migrací složitější, ale méně rušivá. Tento proces se podobá offline migraci, ale neoznačíte původní oddíl jako offline. V závislosti na členitosti procesu migrace, například položky po položce a horizontálním dělení podle horizontálního oddílu, může kód pro přístup k datům v klientských aplikacích číst a zapisovat data, která jsou na dvou místech, v původním oddílu a v novém oddílu.

Usnadnění Azure

Následující části popisují doporučení pro dělení dat uložených ve službách Azure.

Oddíl ve službě Azure SQL Database

Pro jednu databázi SQL platí omezení objemu dat, která může obsahovat. Propustnost je omezená faktory architektury a počtem souběžných připojení, která architektura podporuje.

Elastické fondy podporují horizontální škálování databáze SQL. Pomocí elastických fondů rozdělte data do horizontálních oddílů, které jsou rozdělené do několika databází SQL. S rostoucím a zmenšujícím se objemem dat můžete také přidávat nebo odebírat horizontální oddíly. Elastické fondy můžou také pomoct omezit kolize rozdělením zatížení mezi databáze.

Každý horizontální oddíl se implementuje jako databáze SQL. Horizontální oddíl může obsahovat více než jednu datovou sadu. Každá datová sada se nazývá shardlet. Každá databáze obsahuje metadata, která popisují shardlety, které obsahuje. Shardlet může být jedna datová položka nebo skupina položek, které sdílejí stejný klíč shardletu. Například ve víceklientské aplikaci může být klíč shardletu ID tenanta a všechna data tenanta můžou být ve stejném shardletu.

Aplikace zodpovídají za přidružení datové sady k klíči shardletu. Jako globální správce mapování horizontálních oddílů slouží samostatná databáze SQL. Tato databáze obsahuje seznam všech horizontálních oddílů a shardletů v systému. Aplikace se připojí k databázi správce mapování horizontálních oddílů a získá kopii mapy horizontálních oddílů. Místně ukládá mapu horizontálních oddílů do mezipaměti a používá ji ke směrování požadavků na data do příslušného horizontálního oddílu. Tato funkce je skrytá za řadou rozhraní API obsažených v klientské knihovně funkce Elastic Database SQL Database, která je k dispozici pro Javu a .NET.

Další informace o elastických fondech najdete v tématu Horizontální navýšení kapacity s SQL Database.

Pokud chcete snížit latenci a zlepšit dostupnost, můžete replikovat globální databázi správce mapování horizontálních oddílů. S cenovými úrovněmi Premium můžete nakonfigurovat aktivní geografickou replikaci pro průběžné kopírování dat do databází v různých oblastech.

Případně můžete použít Synchronizace dat SQL pro SQL Database nebo Azure Data Factory k replikaci databáze správce mapování horizontálních oddílů napříč oblastmi. Tato forma replikace se spouští pravidelně a je vhodnější, pokud se mapa horizontálních oddílů mění zřídka a nevyžaduje úroveň Premium.

Elastic Database poskytuje dvě schémata pro mapování dat na shardlety a jejich ukládání v horizontálních oddílech:

Mapa horizontálních oddílů seznamu přidruží jeden klíč k shardletu. Například ve víceklientském systému může být k datům pro každého tenanta přidružený jedinečný klíč a tato data můžou být uložená ve vlastním shardletu. Pro zajištění izolace může být každý shardlet uchován ve svém vlastním horizontálním oddílu.

Stáhněte si soubor Visia s tímto diagramem.
Mapa rozsahu horizontálních oddílů přidruží sadu souvislých hodnot klíčů k shardletu. Můžete například seskupit data pro sadu tenantů, z nichž každý má svůj vlastní klíč, v rámci stejného shardletu. Toto schéma je levnější než mapa horizontálních oddílů seznamu, protože tenanti sdílejí úložiště dat, ale poskytuje menší izolaci.

Stáhnout soubor Visia s tímto diagramem

Jeden horizontální oddíl může obsahovat data pro několik shardletů. Seznamy shardletů můžete použít například k ukládání dat pro různé nesouvislé tenanty ve stejném horizontálním oddílu. Můžete také kombinovat shardlety rozsahu a výpis shardletů ve stejném horizontálním oddílu, ale pak jsou adresovány prostřednictvím různých map. Následující diagram znázorňuje tento přístup:

Stáhněte si soubor Visia s tímto diagramem.

S elastickými fondy můžete přidávat a odebírat horizontální oddíly s rostoucím a zmenšujícím se objemem dat. Klientské aplikace můžou dynamicky vytvářet a odstraňovat horizontální oddíly a transparentně aktualizovat správce mapování horizontálních oddílů. Odebrání horizontálního oddílu je však destruktivní operace, která vyžaduje také odstranění všech dat v daném horizontálním oddílu.

Pokud aplikace potřebuje rozdělit horizontální oddíl do dvou samostatných horizontálních oddílů nebo sloučit horizontální oddíly, použijte nástroj pro rozdělení a sloučení. Tento nástroj běží jako webová služba Azure a bezpečně migruje data mezi horizontálními oddíly.

Schéma dělení může výrazně ovlivnit výkon vašeho systému. Může to také ovlivnit rychlost, s jakou je potřeba přidávat nebo odebírat horizontální oddíly, nebo že se data musí znovu rozdělit na oddíly napříč horizontálními oddíly. Zvažte následující skutečnosti:

Seskupte data, která se používají společně ve stejném horizontálním oddílu, a vyhněte se operacím, které přistupují k datům z více horizontálních oddílů. Horizontální oddíl je databáze SQL sama o sobě a spojení mezi databázemi se musí provádět na straně klienta, pokud operace přistupují k více horizontálním oddílům.

I když SQL Database nepodporuje spojení mezi databázemi, můžete použít nástroje Elastic Database k provádění dotazů s více horizontálními oddíly. Dotaz s více horizontálními oddíly odesílá jednotlivé dotazy do každé databáze a slučuje výsledky.
Navrhni systém, který nemá závislosti mezi horizontálními oddíly. Omezení referenční integrity, triggery a uložené procedury v jedné databázi nemůžou odkazovat na objekty v jiné databázi.
Pokud máte referenční data, která často používají dotazy, zvažte replikaci dat napříč horizontálními oddíly. Tento přístup může eliminovat potřebu spojovat data mezi databázemi. V ideálním případě by taková data měla být statická nebo pomalá, aby se minimalizovalo úsilí replikace a snížila se pravděpodobnost, že budou zastaralá.
Stejné schéma použijte pro shardlety, které patří do stejné mapy horizontálních oddílů. Tyto pokyny nevynucuje SQL Database, ale správa dat a dotazování jsou složité, pokud má každý shardlet jiné schéma. Místo toho vytvořte samostatné mapy horizontálních oddílů pro každé schéma. Data, která patří do různých shardletů, můžete ukládat do stejného horizontálního oddílu.
Uložte data ve stejném horizontálním oddílu nebo implementujte konečnou konzistenci, pokud vaše obchodní logika potřebuje provádět transakce. Transakční operace jsou podporovány pouze pro data, která jsou v horizontálním oddílu, a ne napříč horizontálními oddíly. Transakce můžou zahrnovat shardlety, pokud jsou součástí stejného horizontálního oddílu.
Umístěte horizontální oddíly blízko uživatelů, kteří přistupují k datům v těchto horizontálních oddílech. Tato strategie pomáhá snižovat latenci.
Vyhněte se kombinaci vysoce aktivních a relativně neaktivních horizontálních oddílů. Pokuste se rovnoměrně rozložit zatížení mezi horizontální oddíly. Možná budete muset hashovat klíče horizontálního dělení. Pokud geograficky lokalujete horizontální oddíly, ujistěte se, že se hashované klíče mapují na shardlety uložené v horizontálních oddílech, které jsou uložené v blízkosti uživatelů, kteří k datům přistupují.

Oddíl v Azure Blob Storage

Se službou Blob Storage můžete ukládat velké binární objekty. Objekty blob bloku používejte ve scénářích, které vyžadují rychlé nahrávání nebo stahování velkých objemů dat. Objekty blob stránky použijte pro aplikace, které vyžadují náhodný, nikoli sériový přístup k částem dat.

Každý objekt blob bloku nebo objekt blob stránky se uchovává v kontejneru v účtu úložiště Azure. Pomocí kontejnerů seskupte související objekty blob, které mají stejné požadavky na zabezpečení. Toto seskupení je spíše logické než fyzické. Uvnitř kontejneru má každý objekt blob jedinečný název.

Klíč oddílu pro objekt blob je název účtu, název kontejneru a název objektu blob. Klíč oddílu slouží k rozdělení dat do rozsahů. Tyto rozsahy se vyrovnávají zatížení v celém systému. Objekty blob je možné distribuovat na mnoho serverů, aby se k nim škáloval přístup na více instancí. Jeden objekt blob může obsluhovat jenom jeden server.

Pokud vaše schéma pojmenování používá časová razítka nebo číselné identifikátory, může to vést k nadměrnému provozu do jednoho oddílu. Brání systému v efektivním vyrovnávání zatížení. Pokud například máte každodenní operace, které používají objekt blob s časovým razítkem, například yy-mm-dd, veškerý provoz pro tuto operaci bude směrován na server s jedním oddílem. Místo toho před název zadejte třímístnou hodnotu hash. Další informace najdete v tématu Zásady vytváření názvů oddílů.

Akce zápisu jednoho bloku nebo stránky jsou atomické, ale operace zahrnující bloky, stránky nebo objekty blob ne. Pokud potřebujete zajistit konzistenci při provádění operací zápisu napříč bloky, stránkami a objekty blob, použijte zapůjčení objektu blob.

Požadavky

Dělení dat přináší určité výzvy a složitosti, které je potřeba zvážit.

Synchronizace dat mezi oddíly se může stát výzvou. Zajistěte, aby se aktualizace nebo změny jednoho oddílu šířily do ostatních oddílů včas a konzistentně.
Procesy převzetí služeb při selhání a zotavení po havárii jsou složité, když potřebujete koordinovat zálohování a obnovení více oddílů. K problémům s integritou dat může dojít, pokud jsou některé oddíly nebo jejich zálohy poškozené nebo nedostupné.
Dělení dat může mít vliv na výkon a spolehlivost, pokud potřebujete dotazovat napříč oddíly a při opětovném vyrovnání oddílů, pokud data rostou nerovnoměrně.

Kontrolní seznam spolehlivosti

Projděte si kompletní sadu doporučení.

Kontrolní seznam spolehlivosti

Doporučení pro dělení dat