Návrh strategie škálovatelného dělení pro Azure Table Storage

Tento článek popisuje dělení tabulky ve službě Azure Table Storage a strategie, které můžete použít k zajištění efektivní škálovatelnosti.

Azure poskytuje cloudové úložiště, které je vysoce dostupné a vysoce škálovatelné. Základní systém úložiště pro Azure se poskytuje prostřednictvím sady služeb, mezi které patří Azure Blob Storage, Azure Table Storage, Azure Queue Storage a Azure Files.

Azure Table Storage je navržené tak, aby ukládaly strukturovaná data. Služba Azure Storage podporuje neomezený počet tabulek. Každá tabulka může být škálovat na masivní úrovně a poskytovat terabajty fyzického úložiště. Pokud chcete co nejlépe využít výhod tabulek, musíte data rozdělit optimálně. Tento článek popisuje strategie, které můžete použít k efektivnímu dělení dat pro Azure Table Storage.

Entity tabulky

Entity tabulky představují jednotky dat, které jsou uloženy v tabulce. Entity tabulky jsou podobné řádkům v typické tabulce relační databáze. Každá entita definuje kolekci vlastností. Každá vlastnost je definována jako pár klíč/hodnota podle názvu, hodnoty a datového typu hodnoty. Entity musí v rámci kolekce vlastností definovat následující tři systémové vlastnosti:

• PartitionKey: Vlastnost PartitionKey ukládá řetězcové hodnoty, které identifikují oddíl, do kterého entita patří. Oddíly, jak si probereme později, jsou nedílnou součástí škálovatelnosti tabulky. Entity, které mají stejnou hodnotu PartitionKey , jsou uloženy ve stejném oddílu.

• RowKey: Vlastnost RowKey ukládá řetězcové hodnoty, které jedinečně identifikují entity v rámci každého oddílu. PartitionKey a RowKey společně tvoří primární klíč pro entitu.

• Časové razítko: Vlastnost časového razítka poskytuje sledovatelnost entity. Časové razítko je hodnota data a času, která sděluje čas poslední změny entity. Časové razítko se někdy označuje jako verze entity. Úpravy časových razítek jsou ignorovány, protože služba Table Service udržuje hodnotu této vlastnosti během všech operací vložení a aktualizace.

Primární klíč tabulky

Primární klíč entity Azure se skládá z kombinovaných vlastností PartitionKey a RowKey . Tyto dvě vlastnosti tvoří jeden clusterovaný index v tabulce. Hodnoty PartitionKey a RowKey můžou mít až 1024 znaků. Prázdné řetězce jsou také povoleny; Hodnoty null však nejsou povoleny.

Clusterovaný index seřadí podle klíče oddílu ve vzestupném pořadí a potom podle RowKey ve vzestupném pořadí. Pořadí řazení je pozorováno ve všech odpovědích na dotazy. Během operace řazení se používají lexikální porovnání. Před řetězcovou hodnotou 2 se zobrazí řetězcová hodnota "111". V některých případech můžete chtít, aby pořadí řazení bylo číselné. Pokud chcete řadit v číselném a vzestupném pořadí, musíte použít řetězce s pevnou délkou s nulovou délkou. V předchozím příkladu se před 111 zobrazí "002".

Oddíly tabulky

Oddíly představují kolekci entit se stejnými hodnotami PartitionKey . Oddíly se vždy obsluhují z jednoho oddílového serveru. Každý server oddílů může obsluhovat jeden nebo více oddílů. Oddílový server má limit rychlosti počtu entit, které může obsluhovat z jednoho oddílu v průběhu času. Konkrétně oddíl má cíl škálovatelnosti 2000 entit za sekundu. Tato propustnost může být vyšší při minimálním zatížení uzlu úložiště, ale při zahřátí nebo aktivaci uzlu se omezí.

Pro lepší ilustraci konceptu dělení ukazuje následující obrázek tabulku, která obsahuje malou podmnožinu dat pro registraci událostí závodu nohou. Obrázek představuje koncepční zobrazení dělení, kde Klíč oddílu obsahuje tři různé hodnoty: název události v kombinaci se třemi vzdálenostmi (úplný maraton, půlmaraton a 10 km). V tomto příkladu se používají dva oddílové servery. Server A obsahuje registrace pro půlmaraton a 10kilometrové vzdálenosti. Server B obsahuje pouze úplné maratonské vzdálenosti. Hodnoty RowKey jsou zobrazeny tak, aby poskytovaly kontext, ale hodnoty nejsou pro tento příklad smysluplné.

Tabulka se třemi oddíly

Škálovatelnost

Vzhledem k tomu, že se oddíl vždy obsluhuje z jednoho oddílového serveru a každý oddílový server může obsluhovat jeden nebo více oddílů, efektivita obsluhy entit je v korelaci se stavem serveru. Servery, u které dochází k vysokému provozu pro své oddíly, nemusí být schopné udržet vysokou propustnost. Například na předchozím obrázku, pokud je přijato mnoho požadavků na "2011 New York City Marathon__Half", server A může být příliš horký. Aby se zvýšila propustnost serveru, systém úložiště vyrovnává zatížení oddílů s jinými servery. Výsledkem je, že provoz se distribuuje mezi mnoho dalších serverů. Pro optimální vyrovnávání zatížení provozu byste měli použít více oddílů, aby azure Table Storage mohl distribuovat oddíly na více oddílových serverů.

Transakce skupin entit

Transakce skupiny entit je sada operací úložiště, které jsou implementovány atomicky u entit, které mají stejnou hodnotu PartitionKey . Pokud jakákoli operace úložiště ve skupině entit selže, vrátí se zpět všechny operace úložiště v entitě. Transakce skupiny entit se skládá z maximálně 100 operací úložiště a velikost nemusí být větší než 4 MiB. Transakce skupiny entit poskytují službě Azure Table Storage omezenou formu sémantiky atomicity, konzistence, izolace a stálosti (ACID) poskytovaných relačními databázemi.

Transakce skupin entit zlepšují propustnost, protože snižují počet jednotlivých operací úložiště, které je potřeba odeslat do služby Azure Table Storage. Transakce skupin entit také poskytují ekonomický přínos. Transakce skupiny entit se účtuje jako jedna operace úložiště bez ohledu na to, kolik operací úložiště obsahuje. Vzhledem k tomu, že všechny operace úložiště v transakci skupiny entit mají vliv na entity, které mají stejnou hodnotu PartitionKey , je potřeba použít transakce skupiny entit může řídit výběr hodnoty PartitionKey .

Oddíly rozsahu

Pokud pro entity použijete jedinečné hodnoty PartitionKey , každá entita patří do vlastního oddílu. Pokud se vámi používané jedinečné hodnoty zvýší nebo sníží, je možné, že Azure vytvoří oddíly rozsahu. Oddíly rozsahu seskupují entity, které mají sekvenční jedinečné hodnoty PartitionKey , aby se zlepšil výkon dotazů na rozsahy. Bez oddílů rozsahu musí dotaz na rozsah překročit hranice oddílů nebo hranice serveru, což může snížit výkon dotazů. Představte si aplikaci, která používá následující tabulku, která má rostoucí hodnotu sekvence pro PartitionKey:

Azure může seskupovat první tři entity do oddílu rozsahu. Pokud na tabulku použijete dotaz na rozsah, který jako kritérium používá PartitionKey a požaduje entity od 0001 do 0003, může dotaz fungovat efektivně, protože entity jsou obsluhovány z jednoho oddílového serveru. Neexistuje žádná záruka, kdy a jak se vytvoří oddíl rozsahu.

Existence oddílů rozsahu pro tabulku může ovlivnit výkon operací vložení, pokud vložíte entity se zvyšujícími nebo klesajícími hodnotami PartitionKey . Vkládání entit, které mají rostoucí hodnoty PartitionKey , se nazývá vzor jen pro připojení. Vkládání entit, které mají klesající hodnoty, se nazývá pouze prepend vzor. Zvažte použití těchto typů vzorů, protože celková propustnost vašich požadavků na vložení je omezená serverem s jedním oddílem. Je to proto, že pokud existují oddíly rozsahu, první a poslední oddíl (oblast) obsahují nejnižší a nejvyšší hodnotu PartitionKey v uvedeném pořadí. Proto vložení nové entity, která má postupně nižší nebo vyšší hodnotu PartitionKey , cílí na jeden z koncových oddílů. Následující obrázek znázorňuje možnou sadu oddílů rozsahu, které jsou založené na předchozím příkladu. Pokud by byla vložena sada entit "0007", "0008" a "0009", budou přiřazeny k poslednímu (oranžovým) oddílu.

Sada oddílů rozsahu

Je důležité si uvědomit, že nemá žádný negativní vliv na výkon, pokud operace vložení používají hodnoty PartitionKey , které jsou více rozptýlené.

Analýza dat

Na rozdíl od tabulky v relační databázi, kterou můžete použít ke správě indexů, můžou mít tabulky ve službě Azure Table Storage jenom jeden index. Index ve službě Azure Table Storage se vždy skládá z vlastností PartitionKey a RowKey .

V tabulce Azure nemáte luxus vyladit výkon tabulky přidáním dalších indexů nebo úpravou existující tabulky po jejím zavedení. Při návrhu tabulky musíte analyzovat data. Nejdůležitější aspekty, které je potřeba vzít v úvahu z hlediska optimální škálovatelnosti a efektivity dotazů a vkládání, jsou hodnoty PartitionKey a RowKey . Tento článek zdůrazňuje, jak zvolit klíč oddílu , protože to přímo souvisí s dělením tabulek.

Nastavení velikosti oddílů

Velikost oddílu označuje počet entit, které oddíl obsahuje. Jak si probereme v tématu Škálovatelnost, více oddílů znamená, že získáte lepší vyrovnávání zatížení. Členitost hodnoty PartitionKey ovlivňuje velikost oddílů. Na nejhrubší úrovni, pokud se jako klíč oddílu použije jedna hodnota, jsou všechny entity v jednom oddílu, který je velmi velký. Na nejvyšší úrovni členitosti může Klíč oddílu obsahovat jedinečné hodnoty pro každou entitu. Výsledkem je, že pro každou entitu existuje oddíl. V následující tabulce jsou uvedeny výhody a nevýhody rozsahu podrobností:

Tabulka ukazuje, jak hodnoty PartitionKey ovlivňují škálování. Osvědčeným postupem je upřednostňovat menší oddíly, protože nabízejí lepší vyrovnávání zatížení. V některých scénářích můžou být vhodné větší oddíly, které nemusí být nutně nevýhodné. Pokud například vaše aplikace nevyžaduje škálovatelnost, může být vhodný jeden velký oddíl.

Určení dotazů

Dotazy načítají data z tabulek. Při analýze dat pro tabulku ve službě Azure Table Storage je důležité zvážit, které dotazy bude aplikace používat. Pokud má aplikace několik dotazů, možná budete muset určit jejich prioritu, i když vaše rozhodnutí můžou být subjektivní. V mnoha případech jsou dominantní dotazy rozpoznatelné od jiných dotazů. Z hlediska výkonu spadají dotazy do různých kategorií. Vzhledem k tomu, že tabulka obsahuje pouze jeden index, výkon dotazu obvykle souvisí s vlastnostmi PartitionKey a RowKey . Následující tabulka ukazuje různé typy dotazů a jejich hodnocení výkonu:

Typy dotazů uvedené v předchozí tabulce ukazují postup od nejlepších typů dotazů k nejhorším typům na základě jejich hodnocení výkonu. Pointové dotazy jsou nejlepším typem dotazů, které je možné použít, protože plně využívají clusterovaný index tabulky. Následující bodový dotaz používá data z tabulky registrace pro závody nohou:

http://<account>.windows.core.net/registrations(PartitionKey=”2011 New York City Marathon__Full”,RowKey=”1234__John__M__55”)  
  

Pokud aplikace používá více dotazů, ne všechny z nich mohou být dotazy typu point. Z hlediska výkonu se dotazy na rozsahy řídí dotazy bodů. Existují dva typy dotazů na oblast: prohledávání rozsahu řádků a prohledávání rozsahu oddílů. Prohledávání rozsahu řádků určuje jeden oddíl. Vzhledem k tomu, že operace probíhá na serveru s jedním oddílem, jsou kontroly rozsahů řádků obecně efektivnější než prohledávání rozsahů oddílů. Klíčovým faktorem výkonu prohledávání rozsahů řádků je ale to, jak selektivní je dotaz. Selektivita dotazu určuje, kolik řádků musí být iterated, aby bylo možné najít odpovídající řádky. Selektivnější dotazy jsou efektivnější při kontrolách rozsahů řádků.

Pokud chcete vyhodnotit priority dotazů, zvažte požadavky na četnost a dobu odezvy pro každý dotaz. Dotazy, které se často spouštějí, můžou mít vyšší prioritu. Důležitý, ale zřídka používaný dotaz ale může mít požadavky na nízkou latenci, které by mohly být vyšší v seznamu priorit.

Zvolte hodnotu PartitionKey.

Jádrem návrhu každé tabulky je škálovatelnost, dotazy používané pro přístup k tabulce a požadavky na operace úložiště. Hodnoty PartitionKey , které zvolíte, určují způsob dělení tabulky a typ dotazů, které můžete použít. Na výběr hodnot PartitionKey můžou mít vliv také operace úložiště a zejména vložení. Hodnoty PartitionKey můžou být v rozsahu od jednoduchých hodnot až po jedinečné hodnoty. Můžete je také vytvořit pomocí více hodnot. Vlastnosti entity můžete použít k vytvoření hodnoty PartitionKey . Nebo aplikace může vypočítat hodnotu. Následující části popisují důležité aspekty.

Transakce skupin entit

Vývojáři by měli nejprve zvážit, jestli aplikace bude používat transakce skupin entit (dávkové aktualizace). Transakce skupin entit vyžadují, aby entity měly stejnou hodnotu PartitionKey . Vzhledem k tomu, že dávkové aktualizace jsou určené pro celou skupinu, můžou být možnosti hodnot PartitionKey omezené. Například bankovní aplikace, která udržuje hotovostní transakce, musí vložit hotovostní transakce do tabulky atomicky. Hotovostní transakce představují debetní i kreditní stranu a musí být čisté do nuly. Tento požadavek znamená, že číslo účtu nelze použít jako součást hodnoty PartitionKey , protože každá strana transakce používá jiná čísla účtů. Místo toho může být lepší volbou ID transakce.

Oddíly

Čísla a velikosti oddílů ovlivňují škálovatelnost tabulky, která je zatížená. Řídí se také tím, jak podrobné jsou hodnoty PartitionKey . Určení klíče oddílu na základě velikosti oddílu může být obtížné, zejména pokud je obtížné předpovědět rozdělení hodnot. Dobrým pravidlem je použít několik menších oddílů. Mnoho oddílů tabulky usnadňuje službě Azure Table Storage správu uzlů úložiště, ze které jsou oddíly obsluhovány.

Výběr jedinečných nebo jemnějších hodnot pro PartitionKey způsobí menší, ale více oddílů. To je obecně výhodné, protože systém může vyrovnávat zatížení mnoha oddílů a distribuovat zatížení mezi mnoho oddílů. Měli byste ale zvážit vliv mnoha oddílů na dotazy na rozsahy napříč oddíly. Tyto typy dotazů musí navštívit několik oddílů, aby se dotaz uspokojil. Je možné, že oddíly jsou distribuované napříč mnoha oddílovými servery. Pokud dotaz překročí hranici serveru, musí se vrátit tokeny pokračování. Tokeny pokračování určují další hodnoty PartitionKey nebo RowKey pro načtení další sady dat pro dotaz. Jinými slovy, tokeny pokračování představují alespoň jeden další požadavek na službu, což může snížit celkový výkon dotazu.

Selektivita dotazu je dalším faktorem, který může ovlivnit výkon dotazu. Selektivita dotazu je míra, kolik řádků musí být iterated pro každý oddíl. Čím je dotaz selektivnější, tím efektivnější je dotaz při vracení požadovaných řádků. Celkový výkon dotazů na rozsahy může záviset na počtu serverů oddílů, kterých se musí dotaz dotknout, nebo na tom, jak je dotaz selektivní. Při vkládání dat do tabulky byste se také měli vyhnout použití vzorů jen pro doplňovací nebo prepend. Pokud použijete tyto vzory, i když vytvoříte malé a mnoho oddílů, můžete omezit propustnost operací vložení. Vzory jen pro připojení a předpendy jsou popsány v oddílech rozsahu.

Dotazy

Znalost dotazů, které budete používat, vám může pomoct určit, které vlastnosti je důležité zvážit pro hodnotu PartitionKey . Vlastnosti, které použijete v dotazech, jsou kandidáty pro hodnotu PartitionKey . Následující tabulka obsahuje obecné pokyny k určení hodnoty PartitionKey :

Pokud existuje více než jeden stejně dominantní dotaz, můžete informace vložit několikrát pomocí různých hodnot RowKey , které potřebujete. Vaše aplikace bude spravovat sekundární (nebo terciární atd.) řádky. Tento typ modelu můžete použít ke splnění požadavků na výkon dotazů. Následující příklad používá data z příkladu registrace závodu nohou. Má dva dominantní dotazy:

• Dotaz podle čísla bryndové
• Dotaz podle věku

Pokud chcete obsluhovat oba dominantní dotazy, vložte dva řádky jako transakci skupiny entit. Následující tabulka ukazuje vlastnosti PartitionKey a RowKey pro tento scénář. Hodnoty RowKey poskytují předponu pro bib a age, aby aplikace mohla mezi těmito dvěma hodnotami rozlišovat.

V tomto příkladu je možná transakce skupiny entit, protože hodnoty PartitionKey jsou stejné. Transakce skupiny poskytuje atomicitu operace vložení. I když je možné tento vzor použít s různými hodnotami PartitionKey , doporučujeme použít stejné hodnoty, abyste tuto výhodu získali. V opačném případě možná budete muset napsat další logiku, aby se zajistilo, že atomické transakce, které používají různé hodnoty PartitionKey .

Operace úložiště

Tabulky ve službě Azure Table Storage můžou nastat nejen z dotazů. Mohou také narazit na zatížení z operací úložiště, jako jsou vložení, aktualizace a odstranění. Zvažte, jaký typ operací úložiště budete s tabulkou provádět a jakou rychlostí. Pokud tyto operace provádíte zřídka, nemusíte si s nimi dělat starosti. U častých operací, jako je provádění velkého počtu vložení v krátkém čase, však musíte zvážit, jak se tyto operace obsluhují jako výsledek vámi zvolených hodnot PartitionKey . Důležitými příklady jsou pouze doplňovací a prependní vzory. Vzory jen pro připojení a předpendy jsou popsány v oddílech rozsahu.

Pokud použijete vzor jen pro připojení nebo pouze předpony, použijete jedinečné vzestupné nebo sestupné hodnoty pro PartitionKey při následných vloženích. Pokud tento vzor zkombinujete s častými operacemi vložení, nebude vaše tabulka moct obsluhovat operace vložení s velkou škálovatelností. Škálovatelnost tabulky je ovlivněná tím, že Azure nemůže vyrovnávat zatížení požadavků operace na jiné oddílové servery. V takovém případě můžete zvážit použití náhodných hodnot, jako jsou hodnoty GUID. Potom můžou vaše oddíly zůstat malé a stále udržovat vyrovnávání zatížení během operací úložiště.

Zátěžové testování oddílů tabulky

Pokud je hodnota PartitionKey složitá nebo vyžaduje porovnání s jinými mapováními PartitionKey , možná budete muset otestovat výkon tabulky. Test by měl prozkoumat, jak dobře oddíl funguje při zatížení ve špičce.

Provedení zátěžového testu

1. Create testovací tabulku.
2. Načtěte testovací tabulku s daty tak, aby obsahovala entity s hodnotou PartitionKey , na kterou budete cílit.
3. Pomocí aplikace můžete simulovat zatížení tabulky ve špičce. Zacílujte na jeden oddíl pomocí hodnoty PartitionKey z kroku 2. Tento krok se pro každou aplikaci liší, ale simulace by měla zahrnovat všechny požadované dotazy a operace úložiště. Možná budete muset aplikaci upravit tak, aby cílila na jeden oddíl.
4. Zkontrolujte propustnost operací GET nebo PUT v tabulce.

Pokud chcete zjistit propustnost, porovnejte skutečné hodnoty se zadaným limitem jednoho oddílu na jednom serveru. Oddíly jsou omezené na 2000 entit za sekundu. Pokud propustnost oddílu překročí 2000 entit za sekundu, může být server v produkčním nastavení příliš horký. V tomto případě můžou být hodnoty PartitionKey příliš hrubé, takže není dostatek oddílů nebo jsou oddíly příliš velké. Možná budete muset upravit hodnotu PartitionKey tak, aby oddíly byly distribuovány mezi více serverů.

Vyrovnávání zatížení

K vyrovnávání zatížení ve vrstvě oddílu dochází, když je oddíl příliš horký. Pokud je oddíl příliš horký, funguje tento oddíl, konkrétně oddílový server, nad rámec své cílové škálovatelnosti. V případě úložiště Azure má každý oddíl cíl škálovatelnosti 2000 entit za sekundu. Vyrovnávání zatížení probíhá také na vrstvě systému souborů DFS (Distributed File System).

Vyrovnávání zatížení ve vrstvě DFS se zabývá vstupně-výstupním zatížením a je mimo rozsah tohoto článku. Vyrovnávání zatížení ve vrstvě oddílu neprovádí okamžitě po překročení cíle škálovatelnosti. Místo toho systém několik minut počká, než zahájí proces vyrovnávání zatížení. Tím se zajistí, že se oddíl skutečně zapálí. Není nutné zavádět oddíly s vygenerovaným zatížením, které aktivuje vyrovnávání zatížení, protože systém tuto úlohu provede automaticky.

Pokud byla tabulka vytvořená s určitým zatížením, systém může být schopen vyvážit oddíly na základě skutečného zatížení, což vede k výrazně odlišné distribuci oddílů. Místo vytváření oddílů zvažte psaní kódu, který zpracovává chyby vypršení časového limitu a Zaneprázdněný server. Chyby se vrátí při vyrovnávání zatížení systému. Díky zpracování těchto chyb pomocí strategie opakování může vaše aplikace lépe zpracovávat zatížení ve špičce. Strategie opakování jsou podrobněji popsány v následující části.

Když dojde k vyrovnávání zatížení, oddíl se na několik sekund změní do offline režimu. Během období offline systém znovu přiřazuje oddíl na jiný oddílový server. Je důležité si uvědomit, že vaše data nejsou uložená na oddílových serverech. Místo toho oddílové servery obsluhují entity z vrstvy DFS. Vzhledem k tomu, že vaše data nejsou uložená ve vrstvě oddílů, je přesun oddílů na jiné servery rychlý proces. Tato flexibilita výrazně omezuje případné výpadky, ke kterým může vaše aplikace docházet.

Strategie opakování

Je důležité, aby vaše aplikace zvládla selhání operací úložiště, aby se zajistilo, že nepřijdete o žádné aktualizace dat. Některá selhání nevyžadují strategii opakování. Například aktualizace, které vrací chybu 401 Neautorizováno, nemají užitek z opakování operace, protože je pravděpodobné, že se stav aplikace mezi opakováními, která chybu 401 vyřeší, nezmění. Chyby, jako je zaneprázdněný server nebo vypršení časového limitu, ale souvisí s funkcemi vyrovnávání zatížení Azure, které poskytují škálovatelnost tabulek. Když uzly úložiště obsluhující vaše entity začnou být horké, Azure vyrovnává zatížení tím, že přesune oddíly do jiných uzlů. Během této doby může být oddíl nepřístupný, což vede k chybám zaneprázdnění serveru nebo vypršení časového limitu. Nakonec se oddíl znovu zaregistruje a obnoví se aktualizace.

Strategie opakování je vhodná pro chyby Zaneprázdněný server nebo Vypršení časového limitu. Ve většině případů můžete z logiky opakování vyloučit chyby na úrovni 400 a některé chyby na úrovni 500. Mezi chyby, které lze vyloučit, patří 501 Není implementováno a Verze HTTP 505 není podporována. Pak můžete implementovat strategii opakování až pro chyby na úrovni 500, jako je zaneprázdněný server (503) a vypršení časového limitu (504).

Pro vaši aplikaci si můžete vybrat ze tří běžných strategií opakování:

• Bez opakování: Žádný pokus o opakování se neuskutečí.
• Oprava zpochybnutí: Operace se opakuje nkrát s konstantní hodnotou zpochyb.
• Exponenciální zpoždování: Operace se opakuje Nkrát s exponenciální hodnotou zpoždování.

Strategie Bez opakování je jednoduchý (a vyhýbavý) způsob zpracování selhání operací. Strategie Bez opakování ale není příliš užitečná. Nevynucování opakovaných pokusů představuje zřejmé riziko, protože data se po neúspěšných operacích neukládají správně. Lepší strategií je použít strategii pevného zásady. poskytuje možnost opakování operací se stejnou dobou zpoždování.

Strategie ale není optimalizovaná pro zpracování vysoce škálovatelných tabulek. Pokud mnoho vláken nebo procesů čeká stejnou dobu, může dojít ke kolizím. Doporučená strategie opakování je strategie, která používá exponenciální zpochybnění, kdy je každý opakovaný pokus delší než poslední pokus. Podobá se algoritmu pro předcházení kolizím, který se používá v počítačových sítích, jako je Ethernet. Exponenciální zpoždování používá náhodný faktor k poskytnutí další odchylky výsledného intervalu. Hodnota zásady je pak omezena na minimální a maximální limity. Následující vzorec lze použít k výpočtu další hodnoty zpochybnění pomocí exponenciálního algoritmu:

y = Rand(0,8z; 1,2z)(2^x-1

y = Min(zmin + y, zmax

Kde:

z = výchozí backoff v milisekundách

zmin = výchozí minimální omezení v milisekundách

zmax = výchozí maximální omezení v milisekundách

x = počet opakování

y = hodnota zpoždování v milisekundách

Multiplikátory 0,8 a 1,2 použité ve funkci Rand (random) vytváří náhodnou odchylku výchozího zásady v rámci ±20 % původní hodnoty. Rozsah ±20 % je přijatelný pro většinu strategií opakování a zabraňuje dalším kolizím. Vzorec lze implementovat pomocí následujícího kódu:

int retries = 1;  
  
// Initialize variables with default values  
var defaultBackoff = TimeSpan.FromSeconds(30);  
var backoffMin = TimeSpan.FromSeconds(3);  
var backoffMax = TimeSpan.FromSeconds(90);  
  
var random = new Random();  
  
double backoff = random.Next(  
    (int)(0.8D * defaultBackoff.TotalMilliseconds),   
    (int)(1.2D * defaultBackoff.TotalMilliseconds));  
backoff *= (Math.Pow(2, retries) - 1);  
backoff = Math.Min(  
    backoffMin.TotalMilliseconds + backoff,   
    backoffMax.TotalMilliseconds);  
  

Souhrn

Aplikace ve službě Azure Table Storage může ukládat obrovské množství dat, protože Table Storage spravuje a přiřazuje oddíly napříč mnoha uzly úložiště. K řízení škálovatelnosti tabulky můžete použít dělení dat. Při definování schématu tabulky plánujte předem, abyste zajistili implementaci efektivních strategií dělení na oddíly. Konkrétně analyzujte požadavky aplikace, data a dotazy předtím, než vyberete hodnoty PartitionKey . Každý oddíl může být znovu přiřazen k různým uzlům úložiště, protože systém reaguje na provoz. Pomocí zátěžového testu oddílu se ujistěte, že tabulka obsahuje správné hodnoty PartitionKey . Tento test vám pomůže určit, kdy jsou oddíly příliš horké, a pomůže vám provést potřebné úpravy oddílů.

Pokud chcete zajistit, aby vaše aplikace zpracovávala občasné chyby a aby vaše data trvalá, použijte strategii opakování se zpochybováním. Výchozí zásady opakování, které používá klientská knihovna Azure Storage, mají exponenciální zpochybnění, které zabraňuje kolizím a maximalizuje propustnost vaší aplikace.