Kontrolní seznam k výkonu a škálovatelnosti pro službu Blob Storage

Microsoft vyvinul řadu osvědčených postupů pro vývoj vysoce výkonných aplikací s úložištěm objektů blob. 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 úložiště objektů blob.

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 Blob Storage.

Cíle škálovatelnosti

Pokud se vaše aplikace blíží nebo překročí 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 ocílech

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, vyhodnoťte svůj scénář a určete, jestli platí některá z následujících podmínek:

• Používáte účty úložiště k ukládání nespravovaných disků a jejich přidávání do virtuálních počítačů? V tomto scénáři Microsoft doporučuje používat spravované disky. Spravované disky se škáluje automaticky a bez nutnosti vytvářet a spravovat jednotlivé účty úložiště. Další informace najdete v tématu Úvod ke spravovaným diskům Azure.
• Používáte pro účely izolace dat jeden účet úložiště na zákazníka? V tomto scénáři Microsoft doporučuje používat kontejner objektů blob pro každého zákazníka místo celého účtu úložiště. Azure Storage teď umožňuje přiřadit role Azure pro jednotlivé kontejnery. Další informace najdete v tématu Přiřazení role Azure pro přístup k datům objektů blob.
• 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ů:

• Pokud vaše aplikace dosáhne cíle transakce, zvažte použití účtů úložiště objektů blob bloku, které jsou optimalizované pro vysoké rychlosti transakcí a nízkou a konzistentní latenci. Další informace najdete v tématu Přehled účtu Azure Storage.
• 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. Zatímco komprimace dat může šetřit šířku pásma a zlepšit výkon sítě, 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í však brá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.

Více klientů, kteří přistupují k jednomu objektu blob současně

Pokud máte velký počet klientů, kteří současně přistupují k jednomu objektu blob, musíte zvážit cíle škálovatelnosti jednotlivých objektů blob i jednotlivých účtů úložiště. Přesný počet klientů, kteří mají přístup k jednomu objektu blob, se liší v závislosti na faktorech, jako je počet klientů, kteří požadují objekt blob současně, velikost objektu blob a síťové podmínky.

Pokud je možné objekt blob distribuovat prostřednictvím sítě CDN, jako jsou obrázky nebo videa obsluhovaná z webu, můžete použít síť CDN. Další informace najdete v části s názvem Distribuce obsahu.

V jiných scénářích, jako jsou vědecké simulace, ve kterých jsou data důvěrná, máte dvě možnosti. Prvním je zastřešovat přístup vaší úlohy tak, aby se k objektu blob přistupovalo během časového období a současně k němu přistupovalo. Případně můžete objekt blob dočasně zkopírovat do několika účtů úložiště, abyste zvýšili celkový počet IOPS na objekt blob a napříč účty úložiště. Výsledky se liší v závislosti na chování vaší aplikace, proto nezapomeňte během návrhu testovat vzory souběžnosti.

Šířka pásma a operace na objekt blob

Jeden objekt blob podporuje až 500 požadavků za sekundu. Pokud máte více klientů, kteří potřebují číst stejný objekt blob a tento limit možná překročíte, zvažte použití účtu úložiště objektů blob bloku. Účet úložiště objektů blob bloku poskytuje vyšší rychlost požadavků nebo vstupně-výstupní operace za sekundu (IOPS).

K distribuci operací s objektem blob můžete použít také síť pro doručování obsahu (CDN), jako je Azure CDN. Další informace o Azure CDN najdete v přehledu Azure CDN.

dělení na části

Pochopení toho, jak Azure Storage rozděluje vaše data objektů blob, je užitečné pro zvýšení výkonu. Azure Storage může poskytovat data v jednom oddílu rychleji než data, která pokrývají více oddílů. Vhodným pojmenováním objektů blob můžete zlepšit efektivitu požadavků na čtení.

Úložiště objektů blob používá schéma dělení na základě rozsahu pro škálování a vyrovnávání zatížení. Každý objekt blob má klíč oddílu, který se skládá z celého názvu objektu blob (account+container+blob). Klíč oddílu slouží k rozdělení dat objektů blob do rozsahů. Rozsahy se pak vyrovnávají zatížení napříč úložištěm objektů blob.

Dělení na základě rozsahu znamená, že zásady vytváření názvů, které používají lexikální řazení (například mypayroll, myperformance, myemployees atd.) nebo časová razítka (log20160101, log20160102, log20160102 atd.) budou mít větší pravděpodobnost, že oddíly budou společně umístěné na stejném serveru oddílů, dokud se vyšší zatížení nevyžaduje, aby byly rozdělené do menších rozsahů. Společné umístění objektů blob na stejném serveru oddílů zvyšuje výkon, takže důležitou součástí vylepšení výkonu je pojmenování objektů blob způsobem, který je nejefektivněji uspořádá.

Například všechny objekty blob v kontejneru můžou obsluhovat jeden server, dokud zatížení těchto objektů blob nevyžaduje další vyrovnávání rozsahů oddílů. Podobně může být skupina mírně načtených účtů s jejich názvy uspořádanými v lexikálním pořadí obsluhována jedním serverem, dokud zatížení jednoho nebo všech těchto účtů nevyžaduje jejich rozdělení na několik serverů oddílů.

Každá operace vyrovnávání zatížení může mít vliv na latenci volání úložiště během operace. Schopnost služby zvládnout náhlé nárůsty provozu do oddílu je omezená škálovatelností jednoho serveru oddílů, dokud se operace vyrovnávání zatížení nenačte a nevyrovná rozsah klíčů oddílu.

Pokud chcete snížit frekvenci těchto operací, můžete postupovat podle některých osvědčených postupů.

• Pokud je to možné, použijte objekt blob nebo velikosti bloků větší než 256 KiB pro účty úložiště úrovně Standard a Premium. Větší objekty blob nebo bloky automaticky aktivují objekty blob bloku s vysokou propustností. Objekty blob bloku s vysokou propustností poskytují vysoce výkonné ingestování, které není ovlivněno pojmenováním oddílů.

• Prohlédněte si zásady pro vytváření názvů účtů, kontejnerů, objektů blob, tabulek a front. Zvažte použití předpony u názvu účtu, kontejneru nebo blob objektu v podobě třímístné hash hodnoty vytvořené pomocí nejvhodnější hash funkce.

• Pokud data uspořádáte pomocí časových razítek nebo číselných identifikátorů, ujistěte se, že nepoužíváte vzor provozu jen pro připojení (nebo pouze před čísly). Tyto vzory nejsou vhodné pro systém dělení na základě rozsahu. Tyto vzory můžou vést k tomu, že veškerý provoz přejde do jednoho oddílu a omezí systém z efektivního vyrovnávání zatížení.

  Pokud máte například každodenní operace, které používají objekt blob s časovým razítkem, jako je například yyyymmdd, veškerý provoz pro danou každodenní operaci se přesměruje do jednoho objektu blob, který obsluhuje jeden server oddílů. Zvažte, jestli limity pro jednotlivé objekty blob a limity pro jednotlivé oddíly vyhovují vašim potřebám, a v případě potřeby zvažte rozdělení této operace na více objektů blob. Podobně platí, že pokud ukládáte data časových řad do tabulek, veškerý provoz může být směrován na poslední část oboru názvů klíčů. Pokud používáte číselná ID, předpona ID pomocí třímístné hodnoty hash. Pokud používáte časové razítko, předpona časového razítka s hodnotou sekund, například ssyyyymmdd. Pokud vaše aplikace pravidelně provádí operace výpisu a dotazování, zvolte funkci hash, která omezuje počet dotazů. V některých případech může být dostatečná náhodná předpona.

• Další informace o schématu dělení používaném ve službě Azure Storage najdete v tématu Azure Storage: Vysoce dostupná cloudová služba úložiště se silnou konzistencí.

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.

Umístění

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 blízkosti 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ě.

Pro širokou distribuci obsahu objektů blob použijte síť pro doručování obsahu, jako je Azure CDN. Další informace o Azure CDN najdete v tématu Azure CDN.

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 neumožňuje JavaScript na stránce hostované webem v jedné doméně provádět určité operace, 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.

Ukládání do mezipaměti

Ukládání do mezipaměti hraje důležitou roli při výkonu. V následujících částech najdete osvědčené postupy ukládání do mezipaměti.

Čtení dat

Obecně platí, že čtení dat jednou je vhodnější než čtení dvakrát. Představte si příklad webové aplikace, která načetla objekt blob 50 MiB ze služby Azure Storage, aby sloužila jako obsah pro uživatele. V ideálním případě aplikace místně ukládá objekt blob do mezipaměti na disk a potom načte verzi uloženou v mezipaměti pro následné požadavky uživatelů.

Jedním ze způsobů, jak se vyhnout načtení objektu blob, pokud nebyl změněn, protože byl uložen v mezipaměti, je kvalifikovat operaci GET s podmíněnou hlavičkou pro dobu úprav. Pokud je čas poslední změny po uplynutí doby, po které byl objekt blob uložen v mezipaměti, pak se objekt blob načte a znovu do mezipaměti. V opačném případě se objekt blob v mezipaměti načte pro optimální výkon.

Můžete se také rozhodnout navrhnout aplikaci tak, aby po načtení objektu blob zůstala po krátkou dobu beze změny. V takovém případě aplikace nemusí zkontrolovat, jestli se během tohoto intervalu změnil objekt blob.

Konfigurační data, vyhledávací data a další data, která aplikace často používá, jsou vhodnými kandidáty pro ukládání do mezipaměti.

Další informace o použití podmíněných hlaviček naleznete v tématu Určení podmíněných hlaviček pro operace služby Blob Service.

Nahrávání dat v dávkách

V některých scénářích můžete agregovat data místně a pak je pravidelně nahrávat v dávce místo okamžitého nahrání jednotlivých částí dat. Předpokládejme například, že webová aplikace uchovává soubor protokolu aktivit. Aplikace může buď nahrát podrobnosti o každé aktivitě, jak se děje s tabulkou (která vyžaduje mnoho operací úložiště), nebo může ukládat podrobnosti o aktivitě do místního souboru protokolu a pak pravidelně nahrávat všechny podrobnosti o aktivitě jako soubor s oddělovači do objektu blob. Pokud má každá položka protokolu velikost 1 kB, můžete do jedné transakce nahrát tisíce položek. Jedna transakce podporuje nahrání objektu blob o velikosti až 64 MiB. Vývojář aplikace musí navrhnout možnost selhání klientského zařízení nebo nahrávání. Pokud je potřeba data aktivit stáhnout po dobu delší než pro jednu aktivitu, doporučuje se použití úložiště objektů blob přes Table Storage.

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í

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 dva v klientském prostředí nebo deset 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 Omezení fondu připojení rozhraní .NET Framework a nové sady 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, které může azure Storage vrátit v daném scénáři, je užitečné pro optimalizaci výkonu. Seznam běžných kódů chyb najdete v tématu Běžné kódy chyb rozhraní REST API.

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 to například může zkusit znovu po 2 sekundách, pak po 4 sekundách, 10 sekundách, pak po 30 sekundách a pak to ú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í.

Chyby připojení 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é se nedají opakovat. 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.

Kopírování a přesouvání objektů blob

Azure Storage nabízí řadu řešení pro kopírování a přesouvání objektů blob v rámci účtu úložiště, mezi účty úložiště a mezi místními systémy a cloudem. Tato část popisuje některé z těchto možností z hlediska jejich vlivu na výkon. Informace o efektivním přenosu dat do úložiště objektů blob nebo z úložiště objektů blob najdete v tématu Volba řešení Azure pro přenos dat.

Rozhraní API pro kopírování objektů blob

Pokud chcete kopírovat objekty blob mezi účty úložiště, použijte operaci Put Block From URL . Tato operace kopíruje data synchronně z libovolného zdroje adresy URL do objektu blob bloku. Put Block from URL Použití operace může výrazně snížit požadovanou šířku pásma při migraci dat mezi účty úložiště. Vzhledem k tomu, že se operace kopírování provádí na straně služby, nemusíte stahovat a znovu nahrávat data.

Pokud chcete kopírovat data ve stejném účtu úložiště, použijte operaci Kopírovat objekt blob . Kopírování dat v rámci stejného účtu úložiště se obvykle rychle dokončí.

Použití AzCopy

Nástroj příkazového řádku AzCopy je jednoduchá a efektivní možnost hromadného přenosu objektů blob do účtů úložiště a mezi účty úložiště. Nástroj AzCopy je optimalizovaný pro tento scénář a dokáže dosáhnout vysokých přenosových rychlostí. AzCopy verze 10 používá Put Block From URL operaci ke kopírování dat objektů blob napříč účty úložiště. Další informace najdete v tématu Kopírování nebo přesouvání dat do služby Azure Storage pomocí nástroje AzCopy v10.

Použití Azure Data Boxu

Pokud chcete importovat velké objemy dat do úložiště objektů blob, zvažte použití řady Azure Data Box pro offline přenosy. Zařízení Data Box dodávaná microsoftem jsou dobrou volbou pro přesun velkých objemů dat do Azure, pokud vás omezuje čas, dostupnost sítě nebo náklady. Další informace najdete v dokumentaci ke službě Azure DataBox.

Distribuce obsahu

Někdy aplikace potřebuje obsluhovat stejný obsah mnoha uživatelům (například ukázkové video produktu použité na domovské stránce webu), které se nachází ve stejné nebo více oblastech. V tomto scénáři použijte síť pro doručování obsahu (CDN), jako je Azure Front Door. Azure Front Door je moderní cloudová síť CDN Od Microsoftu, která poskytuje rychlý, spolehlivý a zabezpečený přístup mezi uživateli a statickým a dynamickým webovým obsahem vašich aplikací po celém světě. Azure Front Door poskytuje obsah služby Blob Storage pomocí globální hraniční sítě Microsoftu se stovkami globálních a místních bodů přítomnosti (PoPs). Síť CDN obvykle podporuje mnohem vyšší limity výchozího přenosu dat než jeden účet úložiště a nabízí vylepšenou latenci pro doručování obsahu do jiných regulárních výrazů.

Další informace o službě Azure Front Door najdete v tématu Azure Front Door.

Použití metadat

Služba Blob service podporuje požadavky HEAD, které můžou zahrnovat vlastnosti objektu blob nebo metadata. Pokud například vaše aplikace potřebuje data exif (vyměnitelného formátu obrázku) z fotky, může fotku načíst a extrahovat. Pokud chcete ušetřit šířku pásma a zvýšit výkon, může aplikace ukládat data Exif v metadatech objektu blob, když aplikace fotku nahraje. Data Exif v metadatech pak můžete načíst pouze pomocí požadavku HEAD. Načítání pouze metadat a ne celého obsahu objektu blob šetří významnou šířku pásma a zkracuje dobu zpracování potřebnou k extrakci dat Exif. Mějte na paměti, že 8 KiB metadat je možné uložit na každý objekt blob.

Aktualizace metadat účtu a kontejneru

Metadata účtu a kontejneru se šíří napříč službou úložiště v oblasti, ve které se účet nachází. Úplné šíření těchto metadat může v závislosti na operaci trvat až 60 sekund. Příklad:

• Pokud rychle vytváříte, odstraňujete a znovu vytváříte účty se stejným názvem účtu ve stejné oblasti, ujistěte se, že čekáte 60 sekund na úplné rozšíření stavu účtu nebo může dojít k selhání vašich požadavků.
• Když vytvoříte uložené zásady přístupu v kontejneru, může trvat až 30 sekund.

Ladění výkonu pro přenosy dat

Když aplikace přenáší data pomocí klientské knihovny Azure Storage, může to mít vliv na rychlost, využití paměti a dokonce i na úspěch nebo selhání požadavku. Pokud chcete maximalizovat výkon a spolehlivost přenosů dat, je důležité být proaktivní při konfiguraci možností přenosu klientské knihovny na základě prostředí, ve kterém vaše aplikace běží. Další informace najdete v tématu Ladění výkonu pro nahrávání a stahování.

Rychlé nahrávání objektů blob

Pokud chcete rychle nahrát objekty blob, nejprve určete, jestli nahráváte jeden nebo mnoho objektů blob. Následující doprovodné materiály vám pomůžou určit správnou metodu, která se má použít v závislosti na vašem scénáři. Pokud pro přenosy dat používáte klientskou knihovnu Azure Storage, další pokyny najdete v tématu Ladění výkonu pro přenosy dat.

Rychlé nahrání jednoho velkého objektu blob

Pokud chcete rychle nahrát jeden velký objekt blob, klientská aplikace může paralelně nahrávat své bloky nebo stránky, přičemž je třeba mít na paměti cíle škálovatelnosti pro jednotlivé objekty blob a účet úložiště jako celek. Klientské knihovny Azure Storage podporují paralelní nahrávání. Klientské knihovny pro jiné podporované jazyky poskytují podobné možnosti.

Rychlé nahrání mnoha objektů blob

Pokud chcete rychle nahrát mnoho objektů blob, nahrajte objekty blob paralelně. Paralelní nahrávání je rychlejší než nahrávání jednoho objektu blob najednou s paralelním nahráváním bloků, protože rozděluje nahrávání do několika oddílů služby úložiště. AzCopy ve výchozím nastavení provádí paralelní nahrávání a doporučuje se pro tento scénář. Další informace najdete v tématu Začínáme s nástrojem AzCopy.

Výběr správného typu objektu blob

Azure Storage podporuje objekty blob bloku, doplňovací objekty blob a objekty blob stránky. Pro daný scénář použití ovlivňuje váš výběr typu objektu blob výkon a škálovatelnost vašeho řešení.

Objekty blob bloku jsou vhodné, pokud chcete efektivně nahrávat velké objemy dat. Například klientská aplikace, která nahrává fotky nebo video do úložiště objektů blob, cílí na objekty blob bloku.

Doplňovací objekty blob se podobají objektům blob bloku v tom, že se skládají z bloků. Při úpravě doplňovacího objektu blob se bloky přidají jenom na konec objektu blob. Doplňovací objekty blob jsou užitečné pro scénáře, jako je protokolování, když aplikace potřebuje přidat data do existujícího objektu blob.

Objekty blob stránky jsou vhodné, pokud aplikace potřebuje provádět náhodné zápisy dat. Disky virtuálních počítačů Azure se například ukládají jako objekty blob stránky. Další informace najdete v tématu Principy objektů blob bloku, doplňovací objekty blob a objekty blob stránky.

Další kroky

• Škálovatelnost a cíle výkonu pro úložiště objektů blob
• Škálovatelnost a výkonnostní cíle pro účty úložiště úrovně Standard
• Kódy stavu a chyb