Kontrolní seznam výkonu a škálovatelnosti pro Table Storage
Microsoft vyvinul mnoho osvědčených postupů pro vývoj vysoce výkonných aplikací s Table Storage. Tento kontrolní seznam identifikuje klíčové postupy, které můžou vývojáři sledovat za účelem optimalizace výkonu. Mějte tyto postupy na paměti při navrhování aplikace a v průběhu celého procesu.
Azure Storage má škálovatelnost a cíle výkonu pro kapacitu, rychlost transakcí a šířku pásma. Další informace o cílech škálovatelnosti služby Azure Storage najdete v tématu Škálovatelnost a výkonnostní cíle pro účty úložiště úrovně Standard a škálovatelnost a výkonnostní cíle pro Table Storage.
Kontrolní seznam
Tento článek organizuje osvědčené postupy pro výkon do kontrolního seznamu, který můžete sledovat při vývoji aplikace Table Storage.
Cíle škálovatelnosti
Pokud vaše aplikace přistupuje nebo překračuje některý z cílů škálovatelnosti, může nastat zvýšená latence transakcí nebo omezování. Když Azure Storage omezí vaši aplikaci, služba začne vracet kódy chyb 503 (Server zaneprázdněn) nebo 500 (vypršení časového limitu operace). Zabránění těmto chybám tím, že zůstanete v mezích cílů škálovatelnosti, je důležitou součástí zvýšení výkonu vaší aplikace.
Další informace o cílech škálovatelnosti pro službu Table Service najdete v tématu Škálovatelnost a výkonnostní cíle pro Table Storage.
Maximální počet účtů úložiště
Pokud se blížíte maximálnímu počtu účtů úložiště povolených pro konkrétní kombinaci předplatného nebo oblasti, používáte k horizontálnímu dělení více účtů úložiště ke zvýšení příchozího přenosu dat, výchozího přenosu dat, vstupně-výstupních operací za sekundu (IOPS) nebo kapacity? V tomto scénáři Microsoft doporučuje, abyste využili zvýšené limity pro účty úložiště, abyste snížili počet účtů úložiště potřebných pro vaši úlohu, pokud je to možné. Obraťte se na podporu Azure a požádejte o zvýšené limity pro váš účet úložiště.
Cíle kapacity a transakcí
Pokud vaše aplikace přistupuje k cílům škálovatelnosti pro jeden účet úložiště, zvažte použití jednoho z následujících přístupů:
- Znovu zvažte úlohu, která způsobí, že vaše aplikace bude přistupovat k cíli škálovatelnosti nebo ji překročit. Můžete ji navrhnout jinak, aby používala menší šířku pásma nebo kapacitu nebo méně transakcí?
- Pokud vaše aplikace musí překročit jeden z cílů škálovatelnosti, vytvořte několik účtů úložiště a rozdělte data aplikace mezi tyto více účtů úložiště. Pokud použijete tento vzor, nezapomeňte navrhnout aplikaci tak, abyste v budoucnu mohli přidat další účty úložiště pro vyrovnávání zatížení. Účty úložiště nemají jiné náklady než vaše využití z hlediska uložených dat, transakcí nebo přenášených dat.
- Pokud se vaše aplikace blíží cílům šířky pásma, zvažte komprimaci dat na straně klienta, abyste snížili šířku pásma potřebnou k odesílání dat do Azure Storage. Komprese dat sice může šetřit šířku pásma a zlepšit výkon sítě, ale může mít také negativní vliv na výkon. Vyhodnoťte dopad na výkon dalších požadavků na zpracování pro kompresi a dekompresi dat na straně klienta. Mějte na paměti, že ukládání komprimovaných dat může ztížit řešení potíží, protože může být obtížnější zobrazit data pomocí standardních nástrojů.
- Pokud se vaše aplikace blíží cílům škálovatelnosti, ujistěte se, že pro opakování používáte exponenciální zpochybňování. Nejlepší je se pokusit vyhnout se dosažení cílů škálovatelnosti implementací doporučení popsaných v tomto článku. Použití exponenciálního omezení opakování ale zabrání vaší aplikaci v rychlém opakování, což by mohlo zhoršit omezování. Další informace najdete v části s názvem Chyby Vypršení časového limitu a Zaneprázdnění serveru.
Cíle pro operace s daty
Zatížení služby Azure Storage se vyrovnává při nárůstu provozu do vašeho účtu úložiště, ale pokud se provoz projevuje náhlým nárůstem, možná nebudete moct tento objem propustnosti získat okamžitě. Očekáváme, že během nárazového nárůstu dojde k omezování nebo vypršení časových limitů, protože Azure Storage automaticky vyrovnává zatížení tabulky. Pomalé zvýrazňování obvykle poskytuje lepší výsledky, protože systém má čas správně vyrovnávat zatížení.
Entity za sekundu (účet úložiště)
Limit škálovatelnosti pro přístup k tabulkám je až 20 000 entit (1 kB každý) za sekundu pro účet. Obecně platí, že každá vložená, aktualizovaná, odstraněná nebo skenovaná entita se počítá do tohoto cíle. Dávkové vložení, které obsahuje 100 entit, by se tedy počítaly jako 100 entit. Dotaz, který prohledá 1 000 entit a vrátí 5, by se spočítá jako 1 000 entit.
Entity za sekundu (oddíl)
V rámci jednoho oddílu je cílem škálovatelnosti pro přístup k tabulkám 2 000 entit (1 kB za sekundu) pomocí stejného počtu, jak je popsáno v předchozí části.
Sítě
Omezení fyzické sítě aplikace můžou mít významný dopad na výkon. Následující části popisují některá omezení, se kterými se můžou uživatelé setkat.
Funkce klientské sítě
Šířka pásma a kvalita síťového propojení hrají důležité role při výkonu aplikace, jak je popsáno v následujících částech.
Propustnost
U šířky pásma je problém často schopností klienta. Větší instance Azure mají síťové karty s větší kapacitou, takže pokud potřebujete vyšší limity sítě z jednoho počítače, měli byste zvážit použití větší instance nebo více virtuálních počítačů. Pokud přistupujete ke službě Azure Storage z místní aplikace, platí stejné pravidlo: seznamte se se síťovými funkcemi klientského zařízení a síťového připojení k umístění Azure Storage a buď je podle potřeby vylepšete, nebo navrhněte aplikaci tak, aby fungovala v rámci svých možností.
Kvalita propojení
Stejně jako u jakéhokoli použití sítě mějte na paměti, že síťové podmínky, které vedou k chybám a ztrátě paketů, zpomaluje efektivní propustnost. S diagnostikou tohoto problému vám může pomoct použití WireSharku nebo NetMonu.
Poloha
V jakémkoli distribuovaném prostředí poskytuje klient blízko serveru nejlepší výkon. Pro přístup ke službě Azure Storage s nejnižší latencí je nejlepší umístění pro vašeho klienta ve stejné oblasti Azure. Pokud máte například webovou aplikaci Azure, která používá Azure Storage, vyhledejte je v jedné oblasti, například v oblasti USA – západ nebo Asie – jihovýchod. Společné umístění prostředků snižuje latenci a náklady, protože využití šířky pásma v rámci jedné oblasti je bezplatné.
Pokud klientské aplikace přistupují ke službě Azure Storage, ale nejsou hostované v Rámci Azure, jako jsou aplikace mobilních zařízení nebo místní podnikové služby, může umístění účtu úložiště v oblasti blízko těchto klientů snížit latenci. Pokud jsou vaši klienti široce distribuovaná (například některé v Severní Amerika a některé v Evropě), zvažte použití jednoho účtu úložiště pro každou oblast. Tento přístup je jednodušší implementovat, pokud jsou data, která jsou úložiště aplikací specifická pro jednotlivé uživatele, a nevyžaduje replikaci dat mezi účty úložiště.
SAS a CORS
Předpokládejme, že potřebujete autorizovat kód, jako je JavaScript, který běží ve webovém prohlížeči uživatele nebo v mobilní aplikaci pro přístup k datům ve službě Azure Storage. Jedním z přístupů je vytvoření aplikace služby, která funguje jako proxy server. Zařízení uživatele se ověřuje ve službě, která pak autorizuje přístup k prostředkům Azure Storage. Tímto způsobem se můžete vyhnout zveřejnění klíčů účtu úložiště na nezabezpečených zařízeních. Tento přístup ale výrazně zatěžuje aplikaci služby, protože všechna data přenášená mezi zařízením uživatele a službou Azure Storage musí projít aplikací služby.
Použití aplikace služby jako proxy serveru pro Azure Storage můžete zabránit pomocí sdílených přístupových podpisů (SAS). Pomocí sdíleného přístupového podpisu můžete povolit, aby zařízení uživatele mohly provádět požadavky přímo do Služby Azure Storage pomocí omezeného přístupového tokenu. Pokud například chce uživatel nahrát fotku do aplikace, může aplikace služby vygenerovat SAS a odeslat ji do zařízení uživatele. Token SAS může udělit oprávnění k zápisu do prostředku služby Azure Storage po zadaný časový interval, po jehož uplynutí platnost tokenu SAS vyprší. Další informace o SAS najdete v tématu Udělení omezeného přístupu k prostředkům Azure Storage pomocí sdílených přístupových podpisů (SAS).
Webový prohlížeč obvykle nepovolí JavaScript na stránce hostované webem v jedné doméně k provádění určitých operací, jako jsou operace zápisu, do jiné domény. Tato zásada označovaná jako zásada stejného původu brání škodlivému skriptu na jedné stránce v získání přístupu k datům na jiné webové stránce. Zásady stejného původu ale můžou být omezením při vytváření řešení v cloudu. Sdílení prostředků mezi zdroji (CORS) je funkce prohlížeče, která cílové doméně umožňuje komunikovat s prohlížečem, kterému důvěřuje požadavkům pocházejícím ze zdrojové domény.
Předpokládejme například, že webová aplikace spuštěná v Azure vytvoří požadavek na prostředek do účtu Azure Storage. Webová aplikace je zdrojová doména a účet úložiště je cílová doména. CORS můžete nakonfigurovat pro libovolnou službu Azure Storage, která bude komunikovat s webovým prohlížečem, kterému služba Azure Storage důvěřuje, že požadavky ze zdrojové domény důvěřují. Další informace o CORS najdete v tématu Podpora sdílení prostředků mezi zdroji (CORS) pro Azure Storage.
Sas i CORS vám můžou pomoct vyhnout se zbytečnému zatížení webové aplikace.
Dávkové transakce
Služba Table Service podporuje dávkové transakce u entit, které jsou ve stejné tabulce a patří do stejné skupiny oddílů. Další informace naleznete v tématu Provádění transakcí skupiny entit.
Konfigurace .NET
V případě projektů používajících rozhraní .NET Framework uvádí tato část několik rychlých nastavení konfigurace, pomocí nichž můžete výrazně zlepšit výkon. Pokud používáte jiný jazyk než .NET, zkontrolujte, jestli se ve zvoleném jazyce používají podobné koncepty.
Zvýšení výchozího limitu připojení
Poznámka:
Tato část se vztahuje na projekty používající rozhraní .NET Framework, protože sdružování připojení je řízeno ServicePointManager třídy. .NET Core zavedl významnou změnu správy fondu připojení, kdy se sdružování připojení provádí na úrovni HttpClient a velikost fondu není ve výchozím nastavení omezená. To znamená, že připojení HTTP se automaticky škálují tak, aby vyhovovala vaší úloze. Pokud je to možné, doporučuje se používat nejnovější verzi .NET, abyste mohli využívat vylepšení výkonu.
U projektů používajících rozhraní .NET Framework můžete pomocí následujícího kódu zvýšit výchozí limit připojení (což je obvykle 2 v klientském prostředí nebo 10 v serverovém prostředí) na 100. Obvykle byste měli nastavit hodnotu na přibližně počet vláken používaných vaší aplikací. Před otevřením připojení nastavte limit připojení.
ServicePointManager.DefaultConnectionLimit = 100; //(Or More)
Další informace o omezeních fondu připojení v rozhraní .NET Framework najdete v tématu o omezeních fondu rozhraní .NET Framework Připojení ion a nové sadě Azure SDK pro .NET.
Informace o nastavení limitu připojení najdete v dokumentaci.
Zvýšení minimálního počtu vláken
Pokud používáte synchronní volání společně s asynchronními úlohami, můžete zvýšit počet vláken ve fondu vláken:
ThreadPool.SetMinThreads(100,100); //(Determine the right number for your application)
Další informace naleznete v ThreadPool.SetMinThreads metoda.
Nevázaný paralelismus
I když může být paralelismus skvělý pro výkon, buďte opatrní při používání nevázaného paralelismu, což znamená, že počet vláken nebo paralelních požadavků není nijak omezený. Nezapomeňte omezit paralelní požadavky na nahrání nebo stažení dat, přístup k více oddílům ve stejném účtu úložiště nebo přístup k více položkám ve stejném oddílu. Pokud je paralelismus nevázaný, může vaše aplikace překročit možnosti klientského zařízení nebo cíle škálovatelnosti účtu úložiště, což vede k delší latenci a omezování.
Klientské knihovny a nástroje
Pro zajištění nejlepšího výkonu vždy používejte nejnovější klientské knihovny a nástroje poskytované Microsoftem. Klientské knihovny Azure Storage jsou k dispozici pro různé jazyky. Azure Storage také podporuje PowerShell a Azure CLI. Microsoft aktivně vyvíjí tyto klientské knihovny a nástroje s ohledem na výkon, udržuje je v aktualizovaném stavu s nejnovějšími verzemi služeb a zajišťuje, aby zvládly řadu osvědčených postupů výkonu interně.
Zpracování chyb služby
Azure Storage vrátí chybu, když služba nemůže zpracovat požadavek. Pochopení chyb vrácených službou Azure Storage v daném scénáři je užitečné pro optimalizaci výkonu.
Chyby vypršení časového limitu a zaneprázdnění serveru
Azure Storage může aplikaci omezovat, pokud se blíží limitům škálovatelnosti. V některých případech nemusí Azure Storage kvůli nějaké přechodné podmínce zpracovat požadavek. V obou případech může služba vrátit chybu 503 (Server Busy) nebo 500 (Timeout). K těmto chybám může dojít také v případě, že služba vyrovnává datové oddíly tak, aby umožňovala vyšší propustnost. Klientská aplikace by měla obvykle opakovat operaci, která způsobuje jednu z těchto chyb. Pokud ale Služba Azure Storage omezuje vaši aplikaci, protože překračuje cíle škálovatelnosti, nebo i když služba nemohla požadavek obsluhovat z nějakého jiného důvodu, může se problém zhoršovat agresivními opakováními. Použití exponenciálních zásad opakování se doporučuje a klientské knihovny se pro toto chování standardně používají. Vaše aplikace se například může opakovat po 2 sekundách, pak po 4 sekundách, 10 sekundách, pak po 30 sekundách a pak se úplně vzdát. Tímto způsobem vaše aplikace výrazně snižuje zatížení služby, místo aby zvýšila chování, které by mohlo vést k omezování.
Připojení chyby citlivosti je možné opakovat okamžitě, protože nejsou výsledkem omezování a očekává se, že budou přechodné.
Chyby, které se nedají opakovat
Klientské knihovny zpracovávají opakování s vědomím, které chyby je možné opakovat a které ne. Pokud ale rozhraní REST API služby Azure Storage voláte přímo, měli byste to zkusit znovu. Například chyba 400 (Chybný požadavek) značí, že klientská aplikace odeslala požadavek, který se nepodařilo zpracovat, protože nebyl v očekávaném formátu. Opětovným odesláním tohoto požadavku se pokaždé zobrazí stejná odpověď, takže při opakování neexistuje žádný bod. Pokud rozhraní REST API služby Azure Storage voláte přímo, mějte na paměti potenciální chyby a to, jestli se mají opakovat.
Další informace o kódech chyb Azure Storage najdete v tématu Stav a kódy chyb.
Konfigurace
Tato část obsahuje několik rychlých nastavení konfigurace, pomocí které můžete ve službě Table Service výrazně zlepšit výkon:
Použití JSON
Počínaje službou úložiště verze 2013-08-15 podporuje služba Table service místo formátu AtomPub založeného na JAZYCE XML pro přenos dat tabulky formát JSON. Použití FORMÁTU JSON může snížit velikost datových částí o až 75 % a výrazně zlepšit výkon vaší aplikace.
Další informace najdete v příspěvku o tabulkách Microsoft Azure: Představujeme formát JSON a datové části pro operace služby Table Service.
Zakázat Nagle
Algoritmus Nagle je široce implementovaný napříč sítěmi TCP/IP jako prostředek ke zlepšení výkonu sítě. Není ale optimální za všech okolností (například vysoce interaktivní prostředí). Algoritmus Nagle má negativní dopad na výkon požadavků na službu Azure Table Service a pokud je to možné, měli byste ho zakázat.
Schéma
Reprezentace a dotazování dat je největší faktor, který ovlivňuje výkon služby Table Service. I když se každá aplikace liší, tato část popisuje některé obecné osvědčené postupy, které se týkají:
- Návrh tabulky
- Efektivní dotazy
- Efektivní aktualizace dat
Tabulky a oddíly
Tabulky jsou rozdělené do oddílů. Každá entita uložená v oddílu sdílí stejný klíč oddílu a má jedinečný klíč řádku pro identifikaci v rámci daného oddílu. Oddíly poskytují výhody, ale také zavádějí omezení škálovatelnosti.
- Výhody: Entity ve stejném oddílu můžete aktualizovat v jediné, atomické dávkové transakci, která obsahuje až 100 samostatných operací úložiště (limit celkové velikosti 4 MB). Za předpokladu, že se má načíst stejný počet entit, můžete také dotazovat data v rámci jednoho oddílu efektivněji než data, která pokrývají oddíly (ale přečtěte si další doporučení k dotazování na data tabulky).
- Omezení škálovatelnosti: Přístup k entitám uloženým v jednom oddílu nemůže být vyrovnává zatížení, protože oddíly podporují atomické dávkové transakce. Z tohoto důvodu je cíl škálovatelnosti pro jednotlivé oddíly tabulky nižší než pro službu Table Service jako celek.
Vzhledem k těmto charakteristikám tabulek a oddílů byste měli přijmout následující principy návrhu:
- Vyhledejte data, která klientská aplikace často aktualizuje nebo dotazuje ve stejné logické jednotce práce ve stejném oddílu. Například vyhledejte data ve stejném oddílu, pokud vaše aplikace agreguje zápisy nebo provádíte atomické dávkové operace. Data v jednom oddílu se také dají efektivněji dotazovat v jednom dotazu než data napříč oddíly.
- Vyhledejte data, která klientská aplikace nevkládá, neaktualizuje nebo dotazuje ve stejné logické jednotce práce (tj. v jednom dotazu nebo dávkové aktualizaci) v samostatných oddílech. Mějte na paměti, že počet klíčů oddílů v jedné tabulce není nijak omezený, takže když máte miliony klíčů oddílů, nejedná se o problém a nebude mít vliv na výkon. Pokud je například vaše aplikace oblíbeným webem s přihlášením uživatele, může být dobrou volbou použití ID uživatele, protože klíč oddílu.
Horké oddíly
Horký oddíl je oddíl, který přijímá nepřiměřené procento provozu do účtu a nemůže být vyrovnává zatížení, protože se jedná o jeden oddíl. Obecně platí, že horké oddíly se vytvářejí jedním ze dvou způsobů:
Vzory Pouze připojení a Předpend Only
Vzor "Pouze připojení" je takový, kdy se veškerý (nebo téměř celý) provoz do daného klíče oddílu zvyšuje a snižuje podle aktuálního času. Předpokládejme například, že vaše aplikace používá aktuální datum jako klíč oddílu pro data protokolu. Výsledkem tohoto návrhu jsou všechny vložení do posledního oddílu tabulky a systém nemůže správně vyrovnávat zatížení. Pokud objem provozu do tohoto oddílu překročí cíl škálovatelnosti na úrovni oddílů, dojde k omezování. Lepší je zajistit, aby se provoz odesílal do více oddílů, aby bylo možné vyrovnávat zatížení požadavků v tabulce.
Data s vysokým provozem
Pokud vaše schéma dělení vede k jednomu oddílu, který má jenom data, která jsou mnohem více používaná než jiné oddíly, můžete také vidět omezování, protože tento oddíl přistupuje k cíli škálovatelnosti pro jeden oddíl. Je lepší zajistit, aby schéma oddílů nepřistupující k cílům škálovatelnosti nepřistupuje k žádnému oddílu.
Dotazování
Tato část popisuje osvědčené postupy pro dotazování služby Table Service.
Rozsah dotazu
Existuje několik způsobů, jak zadat rozsah entit, které se mají dotazovat. Následující seznam popisuje jednotlivé možnosti pro obor dotazu.
- Dotazy bodů:- Dotaz bodu načte přesně jednu entitu zadáním klíče oddílu i klíče řádku entity, která se má načíst. Tyto dotazy jsou efektivní a měli byste je používat všude, kde je to možné.
- Dotazy na oddíly: Dotaz oddílu je dotaz, který načte sadu dat, která sdílí společný klíč oddílu. Dotaz obvykle kromě klíče oddílu určuje rozsah hodnot klíče řádku nebo rozsah hodnot pro určitou vlastnost entity. Tyto dotazy jsou méně efektivní než dotazy typu point a měly by se používat střídmě.
- Dotazy na tabulky: Dotaz tabulky je dotaz, který načte sadu entit, které nesdílely společný klíč oddílu. Tyto dotazy nejsou efektivní a pokud je to možné, měli byste se jim vyhnout.
Obecně se vyhněte kontrolám (dotazy větší než jedna entita), ale pokud je nutné je zkontrolovat, zkuste data uspořádat tak, aby kontroly načítaly data, která potřebujete, aniž byste museli prohledávat nebo vracet velké objemy entit, které nepotřebujete.
Hustota dotazů
Dalším klíčovým faktorem efektivity dotazu je počet vrácených entit v porovnání s počtem entit, které se naskenují za účelem vyhledání vrácené sady. Pokud vaše aplikace provede dotaz tabulky s filtrem pro hodnotu vlastnosti, která obsahuje pouze 1 % sdílených složek dat, dotaz prohledá 100 entit pro každou entitu, kterou vrátí. Cíle škálovatelnosti tabulek, které jsme probírali dříve, souvisí s počtem naskenovaných entit, a ne s počtem vrácených entit: Nízká hustota dotazu může snadno způsobit omezení služby Table Service, protože musí prohledávat tolik entit, aby načetla entitu, kterou hledáte. Další informace o tom, jak se vyhnout omezování, najdete v části s názvem Denormalizace.
Omezení vráceného množství dat
Pokud víte, že dotaz vrací entity, které v klientské aplikaci nepotřebujete, zvažte použití filtru ke zmenšení velikosti vrácené sady. I když se entity nevracené klientovi stále započítávají do limitů škálovatelnosti, výkon vaší aplikace se zlepší kvůli zmenšené velikosti datové části sítě a sníženému počtu entit, které musí vaše klientská aplikace zpracovat. Mějte na paměti, že cíle škálovatelnosti se vztahují k počtu naskenovaných entit, takže dotaz, který vyfiltruje mnoho entit, může stále vést k omezování, i když se vrátí několik entit. Další informace o efektivním vytváření dotazů najdete v části s názvem Hustota dotazů.
Pokud klientská aplikace potřebuje jenom omezenou sadu vlastností z entit v tabulce, můžete pomocí projekce omezit velikost vrácené datové sady. Stejně jako u filtrování pomáhá projekce snížit zatížení sítě a zpracování klientů.
Denormalizace
Na rozdíl od práce s relačními databázemi vedou osvědčené postupy pro efektivní dotazování dat tabulek k denormalizaci dat. To znamená, že duplikování stejných dat ve více entitách (jeden pro každý klíč, který byste mohli použít k vyhledání dat), aby se minimalizoval počet entit, které dotaz musí zkontrolovat, aby se našel data, která klient potřebuje, a nemusel prohledávat velký počet entit, abyste našli data, která vaše aplikace potřebuje. Například na webu elektronického obchodování můžete chtít najít objednávku podle ID zákazníka (dejte mi objednávky tohoto zákazníka) a do data (dejte mi objednávky k datu). Ve službě Table Storage je nejlepší entitu (nebo odkaz na ni) uložit dvakrát – jednou s názvem tabulky, PK a RK, abyste usnadnili hledání podle ID zákazníka, a to jednou, aby se usnadnilo jeho vyhledání podle data.
Vložení, aktualizace a odstranění
Tato část popisuje osvědčené postupy pro úpravu entit uložených ve službě Table Service.
Dávkování
Dávkové transakce se v Azure Storage označují jako transakce skupin entit. Všechny operace v rámci transakce skupiny entit musí být v jednom oddílu v jedné tabulce. Pokud je to možné, použijte transakce skupin entit k provádění vkládání, aktualizací a odstraňování v dávkách. Použití transakcí skupin entit snižuje počet odezvy z klientské aplikace na server, snižuje počet fakturovatelných transakcí (transakce skupiny entit se počítá jako jedna transakce pro účely fakturace a může obsahovat až 100 operací úložiště) a umožňuje atomické aktualizace (všechny operace jsou úspěšné nebo všechny neúspěšné v rámci transakce skupiny entit). Prostředí s vysokou latencí, jako jsou mobilní zařízení, výrazně využívají transakce skupin entit.
Upsert
Kdykoli je to možné, používejte operace Upsert tabulky. Existují dva typy upsertu, z nichž obě můžou být efektivnější než tradiční operace vložení a aktualizace:
- InsertOrMerge: Tuto operaci použijte, pokud chcete nahrát podmnožinu vlastností entity, ale nevíte, jestli už entita existuje. Pokud entita existuje, toto volání aktualizuje vlastnosti zahrnuté v operaci Upsert a ponechá všechny existující vlastnosti tak, jak jsou, pokud entita neexistuje, vloží novou entitu. To se podobá použití projekce v dotazu v tom, že potřebujete nahrát pouze vlastnosti, které se mění.
- InsertOrReplace: Tuto operaci použijte, když chcete nahrát zcela novou entitu, ale nevíte, jestli už existuje. Tuto operaci použijte, pokud víte, že nově nahraná entita je zcela správná, protože zcela přepíše starou entitu. Chcete například aktualizovat entitu, která ukládá aktuální umístění uživatele bez ohledu na to, jestli aplikace dříve uložila data o poloze uživatele; nová entita umístění je dokončená a nepotřebujete žádné informace z žádné předchozí entity.
Ukládání datových řad do jedné entity
Aplikace někdy ukládá řadu dat, která často potřebuje najednou načíst: například aplikace může sledovat využití procesoru v průběhu času, aby vykreslila klouzavý graf dat za posledních 24 hodin. Jedním z přístupů je mít jednu entitu tabulky za hodinu, přičemž každá entita představuje konkrétní hodinu a ukládá využití procesoru pro danou hodinu. K vykreslení těchto dat musí aplikace načíst entity, které uchovávají data z posledních 24 hodin.
Případně může vaše aplikace ukládat využití procesoru pro každou hodinu jako samostatnou vlastnost jedné entity: k aktualizaci každé hodiny může vaše aplikace použít jedno volání InsertOrMerge Upsert k aktualizaci hodnoty za poslední hodinu. Aby aplikace vykreslila data, potřebuje místo 24 načíst jenom jednu entitu, což umožňuje efektivní dotaz. Další informace o efektivitě dotazů najdete v části s názvem Rozsah dotazů.
Ukládání strukturovaných dat do objektů blob
Pokud provádíte dávkové vkládání a načítání oblastí entit dohromady, zvažte použití objektů blob místo tabulek. Dobrým příkladem je soubor protokolu. Můžete dosát několik minut protokolů a vložit je a pak najednou načíst několik minut protokolů. V tomto případě je výkon lepší, pokud místo tabulek používáte objekty blob, protože můžete výrazně snížit počet objektů zapsaných do nebo čtení a také možná počet požadavků, které je potřeba provést.