Doporučení pro dělení dat

Článek
07/03/2024

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

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 databázi a technologii úložiště dat, kterou nasadíte. 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 oddíly používají k dělení dat tak, aby se k datům mohly spravovat a přistupovat samostatně. Dělení dat zlepšuje škálovatelnost, snižuje kolize a optimalizuje výkon. Implementujte dělení dat tak, aby se data dělily podle způsobu použití. Můžete například archivovat starší data v levném úložišti dat. Strategii dělení pečlivě zvolte, 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 dělení tabulek SQL Serveru.

Data můžete rozdělit na:

Zlepšení škálovatelnosti. Při vertikálním navýšení kapacity jednoúčelového databázového systému databáze nakonec dosáhne limitu fyzického hardwaru. Pokud rozdělíte data mezi více oddílů, přičemž každý oddíl je hostovaný na samostatném serveru, můžete systém škálovat téměř na neomezenou dobu.
Zvýšení výkonu. V každém oddílu se operace přístupu k datům provádějí v porovnání s daty, která nejsou rozdělená na oddíly. Rozdělte data tak, aby byl 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ýchpřípadechch
Zajištění provozní flexibility. Data můžete rozdělit na oddíly a optimalizovat 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ších úloh 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 do jiného typu úložiště dat na základě nákladů a integrovaných funkcí, které úložiště dat nabízí. Můžete například ukládat velká binární data do úložiště objektů blob a ukládat strukturovaná data do databáze dokumentů. Další informace najdete v tématu Vysvětlení modelů úložiště dat.
Zlepšení dostupnosti. Abyste se vyhnuli jedinému bodu selhání, můžete data oddělit mezi více servery. Pokud jedna instance selže, nebudou k dispozici pouze data v tomto oddílu. Operace pokračují v jiných oddílech. Tento faktor je méně relevantní pro úložiště dat PaaS (Managed Platform as a Service), protože mají integrovanou redundanci.

Výběr správné strategie dělení

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

Horizontální dělení (označované také jako sharding). V této strategii je každý oddíl samostatným úložištěm 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 jednotlivé ohraničené kontexty v systému data používají. Například systém elektronického obchodování může ukládat data faktury do jednoho oddílu a data inventáře produktů v jiném oddílu.

Při návrhu schématu dělení zvažte kombinování 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í nebo horizontálního dělení. Tento příklad rozdělí data inventáře produktů na horizontální oddíly založené 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í. Při provádění horizontálního dělení se zatížení rozdělí na více počítačů, což snižuje kolize a zlepš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 se data rozdělila tak, aby se úloha co nejvíce rozprostřela napříč horizontálními oddíly.

Horizontální oddíly nemusí mít stejnou velikost. Je důležitější vyvážit 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á malý počet operací přístupu. 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í z hlediska kapacity a prostředků zpracování úložiště dat.

Vyhněte se vytváření horkých oddílů, které můžou ovlivnit výkon a dostupnost. Pokud například použijete první písmeno jména zákazníka, může vytvořit nevyváženou distribuci, protože některá písmena jsou častě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ělení velkých horizontálních oddílů, kombinování malých horizontálních oddílů do větších oddílů nebo změna schématu. Tyto operace jsou časově náročné a můžou vyžadovat offline použití jednoho nebo více horizontálních oddílů.

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

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

Vertikální dělení

Nejběžnějším využ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 přístupných 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ženy 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. Další oddíl obsahuje data inventáře, včetně počtu zásob a data poslední objednávky.

V tomto příkladu se aplikace pravidelně dotazuje na název produktu, popis a cenu, když zákazníkům zobrazí podrobnosti o produktu. Počet akcií 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ě pomalá data (název produktu, popis a cena) můžete oddělit od dynamičtějších dat (úroveň zásob a datum poslední objednávky). Pomalé přesouvání dat je vhodným kandidátem pro aplikaci pro ukládání do mezipaměti v paměti.
Citlivá data můžete ukládat 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 úložiště dat orientovaných na sloupce, jako jsou HBase a Cassandra. Pokud se data v kolekci sloupců pravděpodobně nezmění, zvažte použití úložišť sloupců na SQL Serveru.

Funkční dělení

Pokud je možné identifikovat ohraničený kontext pro každou samostatnou 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 použ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 škálovatelnost

Je důležité zvážit velikost a úlohu pro každý oddíl. Vyvažte je tak, aby se data distribuovala za účelem dosažení maximální škálovatelnosti. Musíte ale také rozdělit data tak, aby nepřekračovala limity škálování jednoho úložiště oddílů.

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, jako je například velikost sady výsledků, kterou každý dotaz vrací, četnost přístupu, vlastní latenci a požadavky na zpracování výpočetních prostředků na straně serveru. V mnohapřípadechch
Pomocí této analýzy můžete určit aktuální a budoucí cíle škálovatelnosti, jako je velikost dat a úloha. Distribucí dat napříč oddíly potom splňte cíle škálovatelnosti. Pokud chcete zajistit rovnoměrné rozdělení, zvolte správný klíč horizontálního oddílu. 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 zpracování 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 objemu úložného prostoru, výpočetního výkonu nebo šířky pásma sítě. Pokud požadavky pravděpodobně překročí tyto limity, 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 můžou zpracovat zatížení. Skutečné využití neodpovídá tomu, co analýza predikuje. Možná budete muset znovu vyrovnávat oddíly nebo přepracovávat 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ý 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 Škálovatelnost a výkonnostní cíle pro účty úložiště úrovně Standard. Zaneprázdněný horizontální oddíl může vyžadovat více prostředků, než může zpracovat jeden oddíl. Možná bude potřeba znovu rozdělení horizontálního oddílu, aby se zatížení rozložilo. Pokud celková velikost nebo propustnost těchto tabulek překročí kapacitu účtu úložiště, budete možná muset vytvořit více účtů úložiště a rozložit 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 provádět rychle.
- Monitorujte systém a identifikujte dotazy, které se provádějí pomalu.
- Určete dotazy, které 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í, navrhejte klíč horizontálního oddílu tak, aby aplikace snadno vybrala příslušný oddíl. Tato specifikace brání dotazu ve skenování každého oddílu.
- 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ěmu přistupují.
Pokud má entita požadavky na propustnost a výkon dotazů, použijte funkční dělení, které je založené na dané entitě. Pokud toto přidělení stále nesplňuje požadavky, můžete přidat horizontální dělení. Jedna strategie dělení je obvykle adekvátní, ale v některých případech je efektivnější kombinovat obě strategie.
Spouštění dotazů paralelně napříč oddíly za účelem zlepšení výkonu

Návrh oddílů pro dostupnost

Rozdělte data tak, aby se zlepšila dostupnost aplikací. Dělení zajišťuje, že celá datová sada nemá jediný bod selhání a můžete nezávisle spravovat jednotlivé podmnožina datové sady.

Vezměte v úvahu následující faktory, které ovlivňují 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 do vysoce dostupných oddílů 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ň závažnosti ve stejném oddílu, aby je bylo možné zálohovat ve stejné frekvenci. Můžete například potřebovat zálohovat oddíly, které obsahují transakční data častěji než oddíly, které uchovávají informace protokolování nebo trasování.

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

Pokud dojde k selhání oddílu, 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 v době mimo špičku pro každé umístění. Ujistěte se, že oddíly nejsou tak velké, aby zabránily 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é zavádět 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é datové hodnoty.

Optimalizace kódu aplikace pro použití oddílů

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

Musíte upravit logiku přístupu k datům.
Abyste je mohli distribuovat mezi oddíly, musíte migrovat velké množství existujících dat.
Narazíte na výzvy, 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 dokáže snadno zpracovat. Některé úlohy můžou jít bez oddílů, ale řada komerčních systémů se musí s rostoucím počtem uživatelů rozšířit.

Některé malé úložiště dat také využívají dělení. Například stovky souběžných klientů můžou přistupovat k malému úložišti dat. Pokud data v této situaci rozdělíte, může vám 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 zachovat data pro nejběžnější databázové operace 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. Optimalizaceoddílůch Pokud se musíte dotazovat napříč oddíly, minimalizujte čas dotazu spuštěním paralelních dotazů a agregací výsledků v aplikaci. V některých případech tento přístup nemůžete použít, 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, aby se snížily samostatné vyhledávací operace 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 z celého systému. Při synchronizaci 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 zachová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 cizí klíč. Místo toho zvažte replikaci nebo denormalizaci relevantních dat. Pokud je potřeba spojení mezi oddíly, spusťte paralelní dotazy přes oddíly a připojte data v aplikaci.

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í z dotazování dat, zatímco se nakonec spustí konzistentní operace.

Zvažte, jak dotazy zjišťují správný oddíl. Pokud dotaz musí prohledat všechny oddíly a vyhledat požadovaná data, výrazně ovlivňuje 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. Horizontální dělení může naopak znesnadnit umístě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á se používá k vyhledání umístění horizontálních oddílů položek. Implementujte tuto mapu v logice horizontálního dělení aplikace. Úložiště dat může také udržovat, pokud úložiště dat podporuje transparentní horizontální dělení.

Pravidelně vyrovnává horizontální oddíly. Při horizontálním dělení vám může vyrovnávání horizontálních oddílů pomoct rovnoměrně distribuovat data podle velikosti a úloh. Vyrovnávání horizontálních oddílů za účelem minimalizace hotspotů, maximalizace výkonu dotazů a řešení omezení fyzického úložiště Tento úkol je složitý a často vyžaduje vlastní nástroj nebo proces.

Replikujte oddíly. Replikujte každý oddíl, abyste zajistili přidanou 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 vyhledat nebo replikovat oddíly v několika 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 operací, které upravují data, ale pouze v případě, že jsou data umístěná v jednom oddílu. Pokud potřebujete transakční podporu 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, změna uspořádání 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:

Při dělení dat implementujte vhodné úlohy správy a provozu. 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 pocházející z jiných zdrojů. Některé nástroje a nástroje nemusí podporovat operace s horizontálně dělenými daty, například načítání dat do správného oddílu.
Pravidelně archivujte a odstraňujte data. Abyste zabránili nadměrnému růstu oddílů, archivujte a odstraňte 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 pro vyhledání problémů s integritou dat, jako jsou data v jednom oddílu, který odkazuje 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.

Změna rovnováhy oddílů

Vzhledem k tomu, že systém zralý, možná budete muset upravit schéma dělení. Například jednotlivé oddíly můžou začít přijímat nepřiměřený objem provozu a stát se horkým, což vede k nadměrnému kolizí. Nebo jste možná podcenili objem dat v některých oddílech, což způsobuje, že oddíly přistupují k limitům kapacity.

Některá úložiště dat, jako je azure Cosmos DB, můžou automaticky vyrovnát oddíly. V jiných případech můžete znovu vyrovnát oddíly ve dvou fázích:

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

Možná bude potřeba, aby oddíly byly při přemístění dat nedostupné, což se označuje jako offline migrace. V závislosti na úložišti dat můžete migrovat data mezi oddíly, zatímco se používají. Tato technika se nazývá online migrace.

Offline migrace

Offline migrace snižuje pravděpodobnost kolize. 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 přesuňte data do nových oddílů.
Verify the data.
Přeneste nové oddíly do online režimu.
Odeberte starý oddíl.

Online migrace

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

Usnadnění azure

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

Dělení 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í pro databázi SQL. Pomocí elastických fondů rozdělte data do horizontálních oddílů, které jsou rozložené do více databází SQL. S rostoucím objemem dat a zmenšením můžete také přidávat nebo odebírat horizontální oddíly. Elastické fondy také můžou pomoct snížit kolize tím, že zatížení distribuují 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 má 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 pro 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ů. Mapování horizontálních oddílů ukládá do mezipaměti místně a pomocí mapy směruje žádosti o 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 služby SQL Database, která je k dispozici pro Javu a .NET.

Další informace o elastickýchfondch

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

Alternativně 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ů změ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. Aby bylo možné zaručit izolaci, může být každý shardlet uložen v rámci svého vlastního horizontálního oddílu.

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

Stažení souboru Visia tohoto diagramu

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 rozsahy shardletů a vypsat shardlety 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 tohoto diagramu.

S elastickými fondy můžete přidávat a odebírat horizontální oddíly při růstu a zmenšení objemu dat. Klientské aplikace můžou dynamicky a transparentně 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 na dva samostatné horizontální oddíly nebo kombinovat horizontální oddíly, použijte nástroj pro rozdělení 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 systému. Může také ovlivnit rychlost přidání nebo odebrání horizontálních oddílů nebo opětovné rozdělení dat 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, když operace přistupují k více horizontálním oddílům.

I když SQL Database nepodporuje připojení mezi databázemi, můžete k provádění dotazů s více horizontálními oddíly použít nástroje Elastic Database. Dotaz s více horizontálními oddíly odesílá jednotlivé dotazy do každé databáze a sloučí výsledky.
Navrhňte 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é.
Pokud máte referenční data často používaná dotazy, zvažte replikaci dat napříč horizontálními oddíly. Tento přístup může eliminovat potřebu spojení dat mezi databázemi. V ideálním případě by taková data měla být statická nebo pomalá, aby se minimalizovala úsilí replikace a snížila pravděpodobnost, že budou zastaralá.
Pro shardlety, které patří do stejné mapy horizontálních oddílů, použijte stejné schéma. Tyto pokyny sql Database nevynucují, ale správa dat a dotazování jsou složité, pokud má každý shardlet jiné schéma. Místo toho vytvořte pro každé schéma samostatné mapy horizontálních oddílů. Data, která patří do různých shardletů, můžete ukládat do stejného horizontálního oddílu.
Data můžete ukládat do stejného horizontálního oddílu nebo implementovat 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ům, 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 zatřiďovat klíče horizontálního dělení. Pokud geograficky lokujete 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é blízko uživatelům, kteří k datům přistupují.

Dělení ve službě Azure Blob Storage

Se službou Blob Storage můžete ukládat velké binární objekty. Používejte objekty blob bloku ve scénářích, které vyžadují rychlé nahrávání nebo stahování velkých objemů dat. Objekty blob stránky používejte pro aplikace, které vyžadují náhodný přístup místo sériového přístupu 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ů můžete seskupit související objekty blob se stejnými 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 objektu 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 jsou v systému vyváženy zatížení. Objekty blob je možné distribuovat napříč mnoha servery, aby se k nim mohl škálovat přístup. Jeden objekt blob může obsluhovat jenom jeden server.

Pokud schéma pojmenování používá časové razítko nebo číselné identifikátory, může vést k nadměrnému provozu do jednoho oddílu. Brání tomu, aby systém efektivně vyrovnává zatížení. Pokud máte například každodenní operace, které používají objekt blob s časovým razítkem, například yyyy-mm-dd, veškerý provoz pro tuto operaci přejde na jeden server oddílů. Místo toho zadejte před název 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, které zahrnují bloky, stránky nebo objekty blob, nejsou. Pokud potřebujete zajistit konzistenci při provádění operací zápisu napříč bloky, stránkami a objekty blob, pomocí zapůjčení objektu blob vynechejte zámek zápisu.

Důležité informace

Dělení dat představuje některé výzvy a složitosti, které je potřeba vzít v úvahu.

Synchronizace dat mezi oddíly se může stát výzvou. Zajistěte, aby se aktualizace nebo změny v jednom oddílu včas a konzistentně rozšířily do ostatních oddílů.
Procesy převzetí služeb při selhání a zotavení po havárii se stávají složitými, když potřebujete koordinovat zálohování a obnovení více oddílů. K problémům s integritou dat může dojít v případě, že 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 v případě, že potřebujete dotazovat napříč oddíly, a když znovu vyrovnáte oddíly, pokud data rostou nerovnoměrně.

Kontrolní seznam pro spolehlivost

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

Kontrolní seznam pro spolehlivost

Sdílet prostřednictvím

Doporučení pro dělení dat