Checklista för prestanda och skalbarhet för Blob Storage
Microsoft har utvecklat ett antal beprövade metoder för att utveckla högpresterande program med Blob Storage. Den här checklistan identifierar viktiga metoder som utvecklare kan följa för att optimera prestanda. Tänk på dessa metoder när du utformar ditt program och under hela processen.
Azure Storage har skalbarhets- och prestandamål för kapacitet, transaktionsfrekvens och bandbredd. Mer information om Azure Storage för skalbarhet finns i Skalbarhets- och prestandamål för standardlagringskonton och Skalbarhets- och prestandamål för Blob Storage.
Checklista
Den här artikeln organiserar beprövade prestandametoder i en checklista som du kan följa när du utvecklar ditt Blob Storage-program.
Skalbarhetsmål
Om ditt program närmar sig eller överskrider något av skalbarhetsmålen kan det uppstå längre transaktionsfördröjningar eller begränsningar. När Azure Storage begränsar programmet börjar tjänsten returnera felkoderna 503 (servern är upptagen) eller 500 (åtgärdens tidsgräns). Att undvika dessa fel genom att hålla sig inom gränserna för skalbarhetsmålen är en viktig del av att förbättra programmets prestanda.
Mer information om skalbarhetsmål för Kötjänst finns i Azure Storage skalbarhets- och prestandamål.
Maximalt antal lagringskonton
Om du närmar dig det maximala antalet lagringskonton som tillåts för en viss kombination av prenumeration/region ska du utvärdera ditt scenario och avgöra om något av följande villkor gäller:
- Använder du lagringskonton för att lagra ohanterade diskar och lägga till diskarna till dina virtuella datorer (VM)? I det här scenariot rekommenderar Microsoft att du använder hanterade diskar. Hanterade diskar skalas automatiskt utan att du behöver skapa och hantera enskilda lagringskonton. Mer information finns i Introduktion till Azure Managed Disks
- Använder du ett lagringskonto per kund för dataisolering? I det här scenariot rekommenderar Microsoft att du använder en blobcontainer för varje kund i stället för ett helt lagringskonto. Azure Storage nu kan du tilldela Azure-roller per container. Mer information finns i Tilldela en Azure-roll för åtkomst till blobdata.
- Använder du flera lagringskonton för att sharda för att öka in- och utgående, I/O-åtgärder per sekund (IOPS) eller kapacitet? I det här scenariot rekommenderar Microsoft att du använder ökade gränser för lagringskonton för att minska antalet lagringskonton som krävs för din arbetsbelastning om det är möjligt. Kontakta Azure Support om du vill begära ökade gränser för ditt lagringskonto. Mer information finns i Meddelande om större lagringskonton i högre skala.
Kapacitets- och transaktionsmål
Om ditt program närmar sig skalbarhetsmålen för ett enda lagringskonto kan du överväga att använda någon av följande metoder:
- Om ditt program når transaktionsmålet bör du överväga att använda blockbloblagringskonton, som är optimerade för höga transaktionsfrekvenser och låg och konsekvent svarstid. Mer information finns i kontoöversikten för Azure Storage.
- Fundera över den arbetsbelastning som gör att ditt program närmar sig eller överskrider skalbarhetsmålet. Kan du utforma den annorlunda för att använda mindre bandbredd eller kapacitet eller färre transaktioner?
- Om ditt program måste överskrida något av skalbarhetsmålen skapar du flera lagringskonton och partitionera programdata över de olika lagringskontona. Om du använder det här mönstret måste du utforma programmet så att du kan lägga till fler lagringskonton i framtiden för belastningsutjämning. Storage-konton har ingen annan kostnad än din användning när det gäller lagrade data, transaktioner eller data som överförs.
- Om ditt program närmar sig bandbreddsmålen bör du överväga att komprimera data på klientsidan för att minska den bandbredd som krävs för att skicka data till Azure Storage. Komprimering av data kan spara bandbredd och förbättra nätverkets prestanda, men det kan också ha negativa effekter på prestanda. Utvärdera prestandapåverkan från ytterligare bearbetningskrav för datakomprimering och dekomprimering på klientsidan. Tänk på att det kan vara svårare att lagra komprimerade data eftersom det kan vara svårare att visa data med hjälp av standardverktyg.
- Om ditt program närmar sig skalbarhetsmålen ser du till att du använder en exponentiell backoff för återförsök. Det är bäst att försöka undvika att nå skalbarhetsmålen genom att implementera rekommendationerna som beskrivs i den här artikeln. Men om du använder en exponentiell backoff för återförsök förhindras ditt program från att försöka igen snabbt, vilket kan göra begränsningen sämre. Mer information finns i avsnittet Timeout och Server Busy errors.
Flera klienter som har åtkomst till en enda blob samtidigt
Om du har ett stort antal klienter som har åtkomst till en enda blob samtidigt måste du överväga skalbarhetsmål för både per blob och per lagringskonto. Det exakta antalet klienter som kan komma åt en enda blob varierar beroende på faktorer som antalet klienter som begär bloben samtidigt, storleken på bloben och nätverksförhållanden.
Om bloben kan distribueras via en CDN, till exempel bilder eller videor som betjänas från en webbplats, kan du använda en CDN. Mer information finns i avsnittet Innehållsdistribution.
I andra scenarier, till exempel vetenskapliga simuleringar där data är konfidentiella, har du två alternativ. Det första är att sprida arbetsbelastningens åtkomst så att bloben kan nås under en viss tidsperiod jämfört med när den används samtidigt. Du kan också tillfälligt kopiera bloben till flera lagringskonton för att öka det totala antalet IOPS per blob och mellan lagringskonton. Resultaten varierar beroende på programmets beteende, så se till att testa samtidighetsmönster under utformningen.
Bandbredd och åtgärder per blob
En enskild blob har stöd för upp till 500 begäranden per sekund. Om du har flera klienter som behöver läsa samma blob och du kan överskrida den här gränsen kan du överväga att använda ett blockbloblagringskonto. Ett blockbloblagringskonto ger en högre begärandefrekvens eller I/O-åtgärder per sekund (IOPS).
Du kan också använda ett nätverk för innehållsleverans (CDN) som Azure CDN för att distribuera åtgärder på bloben. Mer information om Azure CDN finns i Azure CDN översikt.
Partitionering
Att förstå Azure Storage partitioner dina blobdata är användbart för att förbättra prestanda. Azure Storage kan hantera data i en enda partition snabbare än data som sträcker sig över flera partitioner. Genom att namnge dina blobar på rätt sätt kan du förbättra effektiviteten för läsbegäranden.
Blob Storage använder ett intervallbaserat partitioneringsschema för skalning och belastningsutjämning. Varje blob har en partitionsnyckel som består av det fullständiga blobnamnet (konto+container+blob). Partitionsnyckeln används för att partitionera blobdata i intervall. Intervallen belastningsutjämnas sedan över Blob Storage.
Intervallbaserad partitionering innebär att namngivningskonventioner som använder lexikal ordning (till exempel mypayroll, myperformance, myemployees osv.) eller tidsstämplar (log20160101, log20160102, log20160102 osv.) är mer sannolika att resultera i att partitionerna sam placeras på samma partitionsserver. , tills ökad belastning kräver att de delas upp i mindre intervall. Samlokalisering av blobar på samma partitionsserver förbättrar prestandan, så en viktig del av prestandaförbättringen är att namnge blobar på ett sätt som organiserar dem så effektivt som möjligt.
Till exempel kan alla blobar i en container betjänas av en enda server tills belastningen på dessa blobar kräver ytterligare ombalansering av partitionsintervallen. På samma sätt kan en grupp med lättlästa konton med deras namn ordnade i lexikal ordning betjänas av en enda server tills belastningen på ett eller alla dessa konton kräver att de delas upp på flera partitionsservrar.
Varje belastningsutjämning kan påverka svarstiden för lagringssamtal under åtgärden. Tjänstens möjlighet att hantera en plötslig trafikbelastning till en partition begränsas av skalbarheten för en enskild partitionsserver tills belastningsutjämningsåtgärden startar och balanserar om partitionsnyckelintervallet.
Du kan följa några metodtips för att minska frekvensen för sådana åtgärder.
Använd om möjligt blob- eller blockstorlekar som är större än 4 MiB för standardlagringskonton och större än 256 KiB för Premium Storage-konton. Större blob- eller blockstorlekar aktiverar automatiskt blockblobar med högt dataflöde. Blockblobar med högt dataflöde ger inmatning med höga prestanda som inte påverkas av namngivning av partitioner.
Granska namngivningskonventionen som du använder för konton, containrar, blobar, tabeller och köer. Överväg att prefixera konto-, container- eller blobnamn med en tresiffrig hash med hjälp av en hash-funktion som passar dina behov bäst.
Om du ordnar dina data med hjälp av tidsstämplar eller numeriska identifierare kontrollerar du att du inte använder ett trafikmönster för endast tillägg (eller endast förberedelse). Dessa mönster är inte lämpliga för ett intervallbaserat partitioneringssystem. Dessa mönster kan leda till att all trafik går till en enda partition och begränsar systemet från effektiv belastningsutjämning.
Om du till exempel har dagliga åtgärder som använder en blob med en tidsstämpel, till exempel yyyymmdd, dirigeras all trafik för den dagliga åtgärden till en enda blob som betjänas av en enda partitionsserver. Överväg om gränserna per blob och per partition uppfyller dina behov och överväg att dela upp den här åtgärden i flera blobar om det behövs. På samma sätt kan all trafik dirigeras till den sista delen av nyckelnamnrymden om du lagrar tidsseriedata i dina tabeller. Om du använder numeriska ID:n ska du prefixa ID:t med en tresiffrig hash. Om du använder tidsstämplar ska du prefixa tidsstämpeln med sekundvärdet, till exempel ssyyyymmdd. Om programmet regelbundet utför list- och frågeåtgärder väljer du en hash-funktion som begränsar antalet frågor. I vissa fall kan ett slumpmässigt prefix vara tillräckligt.
Mer information om partitioneringsschemat som används i Azure Storage finns i Azure Storage: A Highly Available Cloud Storage Service with Strong Consistency.
Nätverk
Programmets fysiska nätverksbegränsningar kan ha en betydande inverkan på prestandan. I följande avsnitt beskrivs några av de begränsningar som användare kan stöta på.
Klientnätverksfunktion
Bandbredden och kvaliteten på nätverkslänken spelar viktiga roller i programprestanda, enligt beskrivningen i följande avsnitt.
Dataflöde
När det gäller bandbredd är problemet ofta klientens funktioner. Större Azure-instanser har nätverkskort med större kapacitet, så du bör överväga att använda en större instans eller flera virtuella datorer om du behöver högre nätverksgränser från en enda dator. Om du använder Azure Storage från ett lokalt program gäller samma regel: förstå nätverksfunktioner på klientenhet och nätverksanslutningen till Azure Storage-platsen och antingen förbättra dem efter behov eller utforma ditt program så att det fungerar inom deras funktioner.
Länkkvalitet
Precis som med all nätverksanvändning bör du tänka på att nätverksförhållanden som resulterar i fel och paketförlust kommer att sakta ned effektivt dataflöde. Att använda WireShark eller NetMon kan vara till hjälp vid diagnostisering av problemet.
Location
I alla distribuerade miljöer ger det bästa resultatet om du placerar klienten nära servern. För att Azure Storage med kortast svarstid är den bästa platsen för din klient inom samma Azure-region. Om du till exempel har en Azure-webbapp som använder Azure Storage, letar du upp dem i en enda region, till exempel USA, västra eller Asien, sydöstra. Att samplacera resurser minskar svarstiden och kostnaden eftersom bandbreddsanvändningen i en enda region är kostnadsfri.
Om klientprogram kommer åt Azure Storage men inte finns i Azure, till exempel mobilappar eller lokala företagstjänster, kan du minska svarstiden genom att placera lagringskontot i en region nära dessa klienter. Om dina klienter är brett distribuerade (till exempel vissa i Nordamerika och vissa i Europa) bör du överväga att använda ett lagringskonto per region. Den här metoden är enklare att implementera om de data som programmet lagrar är specifika för enskilda användare och inte kräver replikering av data mellan lagringskonton.
För bred distribution av blobinnehåll använder du ett nätverk för innehållsdistribution, till exempel Azure CDN. Mer information om Azure CDN finns i Azure CDN.
SAS och CORS
Anta att du behöver auktorisera kod som JavaScript som körs i en användares webbläsare eller i en mobilapp för att komma åt data i Azure Storage. En metod är att skapa ett tjänstprogram som fungerar som proxy. Användarens enhet autentiseras med tjänsten, som i sin tur auktoriserar åtkomst till Azure Storage resurser. På så sätt kan du undvika att exponera dina lagringskontonycklar på osäkra enheter. Den här metoden innebär dock betydande omkostnader för tjänstprogrammet, eftersom alla data som överförs mellan användarens enhet och Azure Storage måste passera genom tjänstprogrammet.
Du kan undvika att använda ett tjänstprogram som proxy för Azure Storage med hjälp av signaturer för delad åtkomst (SAS). Med hjälp av SAS kan du göra så att användarens enhet kan skicka begäranden direkt till Azure Storage med hjälp av en begränsad åtkomsttoken. Om en användare till exempel vill ladda upp ett foto till ditt program kan tjänstprogrammet generera en SAS och skicka den till användarens enhet. SAS-token kan ge behörighet att skriva till en Azure Storage resurs under ett angivet tidsintervall, var innan SAS-token upphör att gälla. Mer information om SAS finns i Bevilja begränsad åtkomst till Azure Storage resurser med hjälp av signaturer för delad åtkomst (SAS).
Normalt tillåter inte en webbläsare JavaScript på en sida som finns på en webbplats i en domän för att utföra vissa åtgärder, till exempel skrivåtgärder, till en annan domän. Den här principen kallas för principen för samma ursprung och förhindrar att ett skadligt skript på en sida får åtkomst till data på en annan webbsida. Principen för samma ursprung kan dock vara en begränsning när du skapar en lösning i molnet. Resursdelning för korsande ursprung (CORS) är en webbläsarfunktion som gör att måldomänen kan kommunicera med webbläsaren om att den litar på begäranden som kommer från källdomänen.
Anta till exempel att en webbapp som körs i Azure gör en begäran om en resurs till ett Azure Storage konto. Webbprogrammet är källdomänen och lagringskontot är måldomänen. Du kan konfigurera CORS för någon av Azure Storage-tjänsterna för att kommunicera med webbläsaren om att begäranden från källdomänen är betrodda av Azure Storage. Mer information om CORS finns i CORS-stöd (Cross-origin resource sharing) för Azure Storage.
Både SAS och CORS kan hjälpa dig att undvika onödig belastning på webbappen.
Cachelagring
Cachelagring spelar en viktig roll i prestanda. I följande avsnitt beskrivs metodtips för cachelagring.
Läsa data
I allmänhet är det bättre att läsa data en gång än att läsa dem två gånger. Överväg exemplet på ett webbprogram som har hämtat en 50 MiB-blob från Azure Storage att fungera som innehåll för en användare. Helst cachelagrar programmet bloben lokalt till disk och hämtar sedan den cachelagrade versionen för efterföljande användarbegäranden.
Ett sätt att undvika att hämta en blob om den inte har ändrats sedan den cachelagrades är att kvalificera GET-åtgärden med ett villkorsstyrd huvud för ändringstid. Om tiden för senaste ändring är efter den tidpunkt då bloben cachelagrades hämtas bloben och cachelagras igen. Annars hämtas den cachelagrade bloben för optimala prestanda.
Du kan också välja att utforma ditt program för att anta att bloben förblir oförändrad under en kort period efter att den har hämtas. I det här fallet behöver programmet inte kontrollera om bloben ändrades under det intervallet.
Konfigurationsdata, uppslagsdata och andra data som ofta används av programmet är bra kandidater för cachelagring.
Mer information om hur du använder villkorsstyrda huvuden finns i Ange villkorliga huvuden för Blob Service-åtgärder.
Ladda upp data i batchar
I vissa fall kan du aggregera data lokalt och sedan regelbundet ladda upp dem i en batch i stället för att ladda upp varje databit omedelbart. Anta till exempel att en webbapp sparar en loggfil med aktiviteter. Programmet kan antingen ladda upp information om varje aktivitet när det sker till en tabell (vilket kräver många lagringsåtgärder), eller så kan det spara aktivitetsinformation till en lokal loggfil och sedan regelbundet ladda upp all aktivitetsinformation som en avgränsad fil till en blob. Om varje loggpost är 1 kB i storlek kan du ladda upp tusentals poster i en enda transaktion. En enda transaktion stöder uppladdning av en blob på upp till 64 MiB i storlek. Programutvecklaren måste utforma för risken för klientenhets- eller uppladdningsfel. Om aktivitetsdata behöver laddas ned under ett tidsintervall i stället för för en enda aktivitet rekommenderas bloblagring framför Table Storage.
.NET-konfiguration
Om du använder .NET Framework här avsnittet flera snabbkonfigurationsinställningar som du kan använda för att göra betydande prestandaförbättringar. Om du använder andra språk kontrollerar du om liknande begrepp gäller på det språk du valt.
Använda .NET Core
Utveckla dina Azure Storage med .NET Core 2.1 eller senare för att dra nytta av prestandaförbättringar. Användning av .NET Core 3.x rekommenderas när det är möjligt.
Mer information om prestandaförbättringar i .NET Core finns i följande blogginlägg:
Öka standardanslutningsgränsen
I .NET ökar följande kod standardanslutningsgränsen (som vanligtvis är två i en klientmiljö eller tio i en servermiljö) till 100. Normalt bör du ange värdet till ungefär det antal trådar som används av ditt program. Ange anslutningsgränsen innan du öppnar några anslutningar.
ServicePointManager.DefaultConnectionLimit = 100; //(Or More)
Information om andra programmeringsspråk finns i dokumentationen för att fastställa hur anslutningsgränsen ska anges.
Mer information finns i blogginlägget Webbtjänster: Samtidiga anslutningar.
Öka det minsta antalet trådar
Om du använder synkrona anrop tillsammans med asynkrona uppgifter kanske du vill öka antalet trådar i trådpoolen:
ThreadPool.SetMinThreads(100,100); //(Determine the right number for your application)
Mer information finns i metoden ThreadPool.SetMinThreads.
Obegränsad parallellitet
Parallellitet kan vara bra för prestanda, men var försiktig med att använda obegränsad parallellitet, vilket innebär att det inte finns någon gräns för antalet trådar eller parallella begäranden. Se till att begränsa parallella begäranden för att ladda upp eller ladda ned data, få åtkomst till flera partitioner i samma lagringskonto eller komma åt flera objekt i samma partition. Om parallellitet är obegränsad kan programmet överskrida klientenhetens funktioner eller lagringskontots skalbarhetsmål, vilket resulterar i längre svarstider och begränsningar.
Klientbibliotek och verktyg
Använd alltid de senaste klientbiblioteken och verktygen från Microsoft för bästa prestanda. Azure Storage klientbibliotek är tillgängliga för en mängd olika språk. Azure Storage också stöd för PowerShell och Azure CLI. Microsoft utvecklar aktivt dessa klientbibliotek och verktyg med prestanda i åtanke, håller dem uppdaterade med de senaste tjänstversionerna och ser till att de hanterar många av de beprövade prestandametoderna internt.
Hantera tjänstfel
Azure Storage returnerar ett fel när tjänsten inte kan bearbeta en begäran. Att förstå de fel som kan returneras av Azure Storage i ett visst scenario är användbart för att optimera prestanda.
Timeout- och server upptagen-fel
Azure Storage kan begränsa programmet om det närmar sig skalbarhetsgränserna. I vissa fall kan Azure Storage inte hantera en begäran på grund av ett tillfälligt tillstånd. I båda fallen kan tjänsten returnera felet 503 (servern är upptagen) eller 500 (timeout). Dessa fel kan också inträffa om tjänsten balanserar om datapartitioner för att möjliggöra högre dataflöde. Klientprogrammet bör vanligtvis försöka utföra åtgärden igen som orsakar något av dessa fel. Men om Azure Storage begränsning av ditt program på grund av att det överskrider skalbarhetsmålen, eller även om tjänsten inte kunde skicka begäran av någon annan anledning, kan aggressivt återförsök göra problemet värre. Vi rekommenderar att du använder en återförsöksprincip för exponentiell back off och klientbiblioteken använder det här beteendet som standard. Programmet kan till exempel försöka igen efter 2 sekunder, sedan 4 sekunder, sedan 10 sekunder, sedan 30 sekunder och sedan ge upp helt. På så sätt minskar programmet avsevärt belastningen på tjänsten, i stället för att försämra beteendet som kan leda till begränsning.
Anslutningsfel kan försökas igen omedelbart, eftersom de inte är resultatet av begränsning och förväntas vara tillfälliga.
Fel som inte kan försökas igen
Klientbiblioteken hanterar återförsök med en medvetenhet om vilka fel som kan göras på nya försök och vilka som inte kan det. Men om du anropar Azure Storage REST API direkt finns det vissa fel som du inte bör försöka igen. Ett 400-fel (felaktig begäran) anger till exempel att klientprogrammet skickade en begäran som inte kunde bearbetas eftersom den inte fanns i det förväntade formuläret. När du skickar om den här begäran får du samma svar varje gång, så det finns ingen anledning att försöka igen. Om du anropar Azure Storage REST API bör du vara medveten om potentiella fel och om de ska göras igen.
Mer information om Azure Storage finns i Status och felkoder.
Kopiera och flytta blobar
Azure Storage ett antal lösningar för att kopiera och flytta blobar i ett lagringskonto, mellan lagringskonton och mellan lokala system och molnet. I det här avsnittet beskrivs några av dessa alternativ vad gäller deras inverkan på prestanda. Information om effektiv överföring av data till eller från Blob Storage finns i Välja en Azure-lösning för dataöverföring.
API:er för blobkopiering
Om du vill kopiera blobar mellan lagringskonton använder du åtgärden Put Block From URL (Placera block från URL). Den här åtgärden kopierar data synkront från en URL-källa till en blockblob. Användningen av Put Block from URL åtgärden kan avsevärt minska den bandbredd som krävs när du migrerar data mellan lagringskonton. Eftersom kopieringen sker på tjänstsidan behöver du inte ladda ned och ladda upp data igen.
Om du vill kopiera data inom samma lagringskonto använder du åtgärden Kopiera blob. Kopiering av data inom samma lagringskonto slutförs vanligtvis snabbt.
Använda AzCopy
Kommandoradsverktyget AzCopy är ett enkelt och effektivt alternativ för massöverföring av blobar till, från och mellan lagringskonton. AzCopy är optimerat för det här scenariot och kan uppnå höga överföringshastigheter. AzCopy version 10 använder åtgärden för Put Block From URL att kopiera blobdata mellan lagringskonton. Mer information finns i Kopiera eller flytta data till Azure Storage med hjälp av AzCopy v10.
Använda Azure Data Box
När du importerar stora mängder data till Blob Storage bör du överväga att använda Azure Data Box för offlineöverföringar. Microsoft-Data Box-enhet enheter är ett bra alternativ för att flytta stora mängder data till Azure när du har begränsad tid, nätverkstillgänglighet eller kostnader. Mer information finns i Azure DataBox-dokumentationen.
Innehållsdistribution
Ibland måste ett program hantera samma innehåll för många användare (till exempel en video med produktdemo som används på webbplatsens startsida), som finns i samma eller flera regioner. I det här scenariot använder du Content Delivery Network (CDN) som Azure CDN distribuera blobinnehåll geografiskt. Till skillnad Azure Storage ett Azure Storage-konto som finns i en enda region och som inte kan leverera innehåll med låg fördröjning till andra regioner, använder Azure CDN servrar i flera datacenter runt om i världen. Dessutom kan en CDN normalt stödja mycket högre utgående gränser än ett enda lagringskonto.
Mer information om Azure CDN finns i Azure CDN.
Använda metadata
Blob-tjänsten stöder HEAD-begäranden, som kan innehålla blobegenskaper eller metadata. Om ditt program till exempel behöver Exif-data (exchangeable image format) från ett foto kan det hämta fotot och extrahera det. För att spara bandbredd och förbättra prestanda kan programmet lagra Exif-data i blobens metadata när programmet laddar upp fotot. Du kan sedan hämta Exif-data i metadata med hjälp av endast en HEAD-begäran. Att endast hämta metadata och inte hela innehållet i bloben sparar betydande bandbredd och minskar bearbetningstiden som krävs för att extrahera Exif-data. Tänk på att 8 KiB med metadata kan lagras per blob.
Upload blobar snabbt
Om du vill ladda upp blobar snabbt måste du först avgöra om du ska ladda upp en blob eller många. Använd vägledningen nedan för att fastställa rätt metod att använda beroende på ditt scenario.
Upload en stor blob snabbt
Om du snabbt vill ladda upp en enda stor blob kan ett klientprogram ladda upp dess block eller sidor parallellt, med tanke på skalbarhetsmålen för enskilda blobar och lagringskontot som helhet. De Azure Storage klientbiblioteken stöder uppladdning parallellt. Du kan till exempel använda följande egenskaper för att ange antalet samtidiga begäranden som tillåts i .NET eller Java. Klientbibliotek för andra språk som stöds ger liknande alternativ.
- För .NET anger du egenskapen BlobRequestOptions.ParallelOperationThreadCount.
- För Java/Android anropar du metoden BlobRequestOptions.setConcurrentRequestCount(final Integer concurrentRequestCount).
Upload många blobar snabbt
Om du vill ladda upp många blobar snabbt laddar du upp blobar parallellt. Att ladda upp parallellt är snabbare än att ladda upp enskilda blobar i taget med parallella blockuppladdningar eftersom det sprider uppladdningen över flera partitioner i lagringstjänsten. AzCopy utför uppladdningar parallellt som standard och rekommenderas för det här scenariot. Mer information finns i Kom igång med AzCopy.
Välja rätt typ av blob
Azure Storage har stöd för blockblobar, tilläggsblobbar och sidblobar. För ett visst användningsscenario påverkar ditt val av blobtyp lösningens prestanda och skalbarhet.
Blockblobar är lämpliga när du vill ladda upp stora mängder data effektivt. Till exempel skulle ett klientprogram som laddar upp foton eller video till Blob Storage rikta in sig på blockblobar.
Tilläggsblobar liknar blockblobar eftersom de består av block. När du ändrar en tilläggsblob läggs block endast till i slutet av bloben. Tilläggsblobar är användbara för scenarier som loggning när ett program behöver lägga till data i en befintlig blob.
Sidblobar är lämpliga om programmet behöver utföra slumpmässiga skrivningar på data. Till exempel lagras virtuella Azure-datordiskar som sidblobar. Mer information finns i Förstå blockblobar, tilläggsblobar och sidblobar.