Controlelijst voor prestaties en schaalbaarheid voor Blob-opslag
Microsoft heeft een aantal bewezen procedures ontwikkeld voor het ontwikkelen van hoogwaardige toepassingen met Blob Storage. Deze controlelijst vermeldt de belangrijkste procedures die ontwikkelaars kunnen volgen om de prestaties te optimaliseren. Neem bij het ontwerpen van uw toepassing en tijdens het gehele proces deze procedures in acht.
Azure Storage bevat schaalbaarheids- en prestatiedoelen voor capaciteit, transactiesnelheid en bandbreedte. Zie Schaalbaarheids Azure Storage prestatiedoelen voor standaardopslagaccounts en Schaalbaarheids- en prestatiedoelen voor Blob Storage voor meer informatie over de schaalbaarheidsdoelen.
Controlelijst
In dit artikel worden bewezen procedures voor prestaties georganiseerd in een controlelijst die u kunt volgen tijdens het ontwikkelen van uw Blob Storage-toepassing.
Schaalbaarheidsdoelen
Als uw toepassing een van de schaalbaarheidsdoelen benadert of overschrijdt, kunnen er meer latenties in of beperkingen voor transacties optreden. Wanneer Azure Storage uw toepassing beperkt, begint de service met het retourneren van de foutcodes 503 (server bezet) of 500 (time-out voor bewerking). Het vermijden van deze fouten door binnen de grenzen van de schaalbaarheidsdoelen te blijven vormt een belangrijk onderdeel van het verbeteren van de prestaties van uw toepassing.
Zie Schaalbaarheids- en prestatiedoelen voor Azure Storage voor meer informatie over de schaalbaarheidsdoelen voor de Queue-service.
Maximumaantal opslagaccounts
Als u het maximum aantal toegestane opslagaccounts voor een bepaalde combinatie van abonnement/regio nadert, evalueert u uw scenario en bepaalt u of een van de volgende voorwaarden van toepassing is:
- Gebruikt u opslagaccounts om niet-beherende schijven op te slaan en deze schijven toe te voegen aan uw virtuele machines (VM's)? Voor dit scenario raadt Microsoft het gebruik van beheerde schijven aan. Beheerde schijven worden automatisch voor u geschaald zonder dat u afzonderlijke opslagaccounts hoeft te maken en beheren. Zie Inleiding tot beheerde Azure-schijven voor meer informatie
- Gebruikt u één opslagaccount per klant voor gegevensisolatie? Voor dit scenario raadt Microsoft aan voor elke klant een blobcontainer te gebruiken in plaats van een volledig opslagaccount. Azure Storage kunt u nu Azure-rollen per container toewijzen. Zie Assign an Azure role for access to blob data (Een Azure-rol toewijzen voor toegang tot blobgegevens) voor meer informatie.
- Gebruikt u meerdere opslagaccounts om sharding uit te voeren om de ingress,egress, I/O-bewerkingen per seconde (IOPS) of capaciteit te verhogen? In dit scenario raadt Microsoft u aan gebruik te maken van verhoogde limieten voor opslagaccounts om zo mogelijk het aantal opslagaccounts te beperken dat is vereist voor uw workload. Neem contact op met Ondersteuning voor Azure om verhoogde limieten voor uw opslagaccount aan te vragen. Zie Grotere opslagaccounts met een hogere schaal voor meer informatie.
Capaciteits- en transactiedoelen
Als uw toepassing de schaalbaarheidsdoelen voor één opslagaccount nadert, kunt u een van de volgende benaderingen overwegen:
- Als uw toepassing het transactiedoel bereikt, kunt u overwegen blok-blobopslagaccounts te gebruiken, die zijn geoptimaliseerd voor hoge transactiesnelheden en lage en consistente latentie. Zie Overzicht van Azure-opslagaccount voor meer informatie.
- Bekijk de workload die ervoor zorgt dat uw toepassing het schaalbaarheidsdoel benadert of overschrijdt. Kunt u het op een andere manier ontwerpen waardoor u minder bandbreedte of capaciteit of minder transacties gebruikt?
- Als uw toepassing een van de schaalbaarheidsdoelen moet overschrijden, maakt u meerdere opslagaccounts en partitioneert u uw toepassingsgegevens over deze meerdere opslagaccounts. Als u dit patroon gebruikt, moet u ervoor zorgen dat u uw toepassing zo ontwerpt, dat u in de toekomst meer opslagaccounts kunt toevoegen voor de taakverdeling. Opslagaccounts zelf hebben geen andere kosten dan uw gebruik in termen van opgeslagen gegevens, gemaakte transacties of overgedragen gegevens.
- Als uw toepassing de bandbreedtedoelen nadert, kunt u de gegevens aan de clientzijde comprimeren om de bandbreedte te verminderen die nodig is om de gegevens naar Azure Storage te verzenden. Hoewel met het comprimeren van gegevens bandbreedte kan worden bespaard en de netwerkprestaties worden verbeterd, kan dit ook negatieve gevolgen voor de prestaties hebben. Evalueer de invloed op de prestaties van de extra verwerkingsvereisten voor de compressie en decompressie van gegevens aan de clientzijde. Houd er rekening mee dat het door het opslaan van gecomprimeerde gegevens lastiger wordt om problemen op te lossen, aangezien het lastiger kan zijn om de gegevens te bekijken met behulp van standaardhulpprogramma's.
- Als uw toepassing de schaalbaarheidsdoelen nadert, moet u ervoor zorgen dat u een exponentieel uitstel gebruikt voor nieuwe pogingen. U kunt het beste voorkomen dat u de schaalbaarheidsdoelen bereikt door de aanbevelingen te implementeren die in dit artikel worden beschreven. Als u echter een exponentieel uitstel gebruikt voor nieuwe pogingen, voorkomt u dat uw toepassing snel opnieuw pogingen onderneemt, waarmee de beperkingen ernstiger kunnen worden. Zie de sectie met de titel Time-out- en server-bezetfouten voor meer informatie.
Meerdere clients die gelijktijdig toegang hebben tot één blob
Als u een groot aantal clients hebt die gelijktijdig toegang hebben tot één blob, moet u rekening houden met schaalbaarheidsdoelen per blob en per opslagaccount. Het exacte aantal clients dat toegang heeft tot één blob, is afhankelijk van factoren zoals het aantal clients dat tegelijkertijd de blob aanvraagt, de grootte van de blob en netwerkomstandigheden.
Als de blob kan worden gedistribueerd via een CDN zoals afbeeldingen of video's die vanaf een website worden gebruikt, kunt u een CDN. Zie de sectie Inhoudsdistributie voor meer informatie.
In andere scenario's, zoals wetenschappelijke simulaties waarbij de gegevens vertrouwelijk zijn, hebt u twee opties. De eerste is het spreiden van de toegang van uw workload, zodat de blob gedurende een bepaalde periode wordt gebruikt versus tegelijkertijd wordt gebruikt. U kunt de blob ook tijdelijk kopiëren naar meerdere opslagaccounts om het totale aantal IOPS per blob en voor opslagaccounts te verhogen. De resultaten variëren afhankelijk van het gedrag van uw toepassing. Test daarom gelijktijdigheidspatronen tijdens het ontwerpen.
Bandbreedte en bewerkingen per blob
Eén blob ondersteunt maximaal 500 aanvragen per seconde. Als u meerdere clients hebt die dezelfde blob moeten lezen en u deze limiet mogelijk overschrijdt, kunt u overwegen een blok-blobopslagaccount te gebruiken. Een blok-blobopslagaccount biedt een hogere aanvraagsnelheid, of I/O-bewerkingen per seconde (IOPS).
U kunt ook een netwerk voor contentlevering (CDN) zoals Azure CDN om bewerkingen op de blob te distribueren. Zie overzicht van Azure CDN voor Azure CDN informatie.
Partitionering
Inzicht in Azure Storage partities van uw blobgegevens is handig om de prestaties te verbeteren. Azure Storage kunnen gegevens sneller in één partitie verwerken dan gegevens die meerdere partities bespannen. Door uw blobs de juiste naam te geven, kunt u de efficiëntie van leesaanvragen verbeteren.
Blob Storage maakt gebruik van een partitieschema op basis van een bereik voor schalen en taakverdeling. Elke blob heeft een partitiesleutel die bestaat uit de volledige blobnaam (account+container+blob). De partitiesleutel wordt gebruikt om blobgegevens te partitioneren in reeksen. De reeksen worden vervolgens verdeeld over Blob-opslag.
Partitionering op basis van een bereik betekent dat naamconventities die lexicale volgorde gebruiken (bijvoorbeeld mypayroll, myperformance, myemployees, enzovoort) of tijdstempels (log20160101, log20160102, log20160102, enzovoort), waarschijnlijker zijn als de partities zich op dezelfde partitieserver bevinden. , totdat een verhoogde belasting vereist dat ze worden gesplitst in kleinere reeksen. Het co-locating van blobs op dezelfde partitieserver verbetert de prestaties, dus een belangrijk onderdeel van prestatieverbetering is het benoemen van blobs op een manier die ze het effectiefst organiseert.
Alle blobs in een container kunnen bijvoorbeeld door één server worden bediend totdat de belasting van deze blobs verdere herverdeling van de partitiebereiken vereist. Op dezelfde manier kan een groep licht geladen accounts met hun namen in lexicale volgorde worden bediend door één server totdat de belasting van een of al deze accounts vereist dat ze worden verdeeld over meerdere partitieservers.
Elke taakverdelingsbewerking kan invloed hebben op de latentie van opslag-aanroepen tijdens de bewerking. De mogelijkheid van de service om een plotselinge burst van verkeer naar een partitie af te handelen, wordt beperkt door de schaalbaarheid van één partitieserver totdat de taakverdelingsbewerking wordt uitgevoerd en het bereik van de partitiesleutel opnieuw wordt verdeeld.
U kunt enkele best practices volgen om de frequentie van dergelijke bewerkingen te verminderen.
Gebruik, indien mogelijk, blob- of blokgrootten groter dan 4 MiB voor Standard-opslagaccounts en groter dan 256 KiB voor Premium Storage-accounts. Grotere blob- of blokgrootten activeren automatisch blok-blobs met hoge doorvoer. Blok-blobs met hoge doorvoer bieden opname met hoge prestaties die niet worden beïnvloed door partitienaamgeving.
Bekijk de naamconventie die u gebruikt voor accounts, containers, blobs, tabellen en wachtrijen. U kunt account-, container- of blobnamen vooraf laten gaan door een hash van drie cijfers met behulp van een hashfunctie die het beste bij uw behoeften past.
Als u uw gegevens organiseert met behulp van tijdstempels of numerieke id's, moet u ervoor zorgen dat u geen alleen-append-verkeerspatroon (of alleen-prepend) gebruikt. Deze patronen zijn niet geschikt voor een partitioneringssysteem op basis van een bereik. Deze patronen kunnen ertoe leiden dat al het verkeer naar één partitie gaat en het systeem wordt beperkt tegen effectief taakverdeling.
Als u bijvoorbeeld dagelijkse bewerkingen hebt die gebruikmaken van een blob met een tijdstempel zoals yyyymmdd, wordt al het verkeer voor die dagelijkse bewerking omgeleid naar één blob, die wordt bediend door één partitieserver. Overweeg of de limieten per blob en per partitie aan uw behoeften voldoen en overweeg deze bewerking indien nodig op te delen in meerdere blobs. En als u tijdreeksgegevens in uw tabellen opgeslagen, kan al het verkeer worden omgeleid naar het laatste deel van de sleutelnaamruimte. Als u numerieke id's gebruikt, moet u de id vooraf laten gaan door een hash van drie cijfers. Als u tijdstempels gebruikt, geeft u het tijdstempel het voorvoegsel met de secondenwaarde, bijvoorbeeld ssyyyyymmdd. Als uw toepassing regelmatig vermeldingen en querybewerkingen uitvoert, kiest u een hash-functie die uw aantal query's beperkt. In sommige gevallen kan een willekeurig voorvoegsel voldoende zijn.
Zie voor meer informatie over het partitieschema dat wordt gebruikt in Azure Storage, Azure Storage: A Highly Available Cloud Storage Service with Strong Consistency.
Netwerken
De beperkingen van het fysieke netwerk van de toepassing kunnen een grote invloed hebben op de prestaties. In de volgende secties worden enkele beperkingen beschreven die gebruikers kunnen tegenkomen.
Netwerkmogelijkheden van de client
De bandbreedte en de kwaliteit van de netwerkkoppeling spelen een belangrijke rol in prestaties van toepassingen, zoals beschreven in de volgende secties.
Doorvoer
Voor bandbreedte is het probleem vaak de mogelijkheden van de client. Grotere Azure-exemplaren hebben NIC's met een grotere capaciteit. U moet dus overwegen een grotere exemplaar of meer VM's te gebruiken als u hogere netwerklimieten voor één computer nodig hebt. Als u Azure Storage opent vanuit een on-premises toepassing, geldt dezelfde regel: zorg ervoor dat u inzicht krijgt in de netwerkmogelijkheden van het clientapparaat en de netwerkverbinding met de Azure Storage-locatie en verbeter deze, indien nodig. U kunt ook uw toepassing zo ontwerpen dat deze binnen deze mogelijkheden kan werken.
Kwaliteit van de koppeling
Net als bij elk netwerkgebruik moet u er rekening mee houden dat de netwerkomstandigheden die fouten en pakketverlies veroorzaken, ervoor zorgen dat de effectieve doorvoer wordt vertraagd. Het gebruik van WireShark of NetMon kan helpen bij het vaststellen van dit probleem.
Locatie
Wanneer u de client dicht bij de server plaatst, levert dit in een gedistribueerde omgeving de beste prestaties op. Als u toegang wilt tot Azure Storage met de laagste latentie, bevindt de beste locatie voor uw client zich in dezelfde Azure-regio. Als u bijvoorbeeld een Azure-web-app hebt die gebruikmaakt van Azure Storage, plaatst u deze beide binnen één regio, zoals US - west of Azië - zuidoost. Wanneer u resources bij elkaar plaatst, vermindert u de latentie en de kosten, omdat het bandbreedtegebruik binnen één regio gratis is.
Als clienttoepassingen toegang krijgen tot Azure Storage, maar niet worden gehost in Azure, zoals apps voor mobiele apparaten of on-premises bedrijfsservices, kan de latentie worden verminderd door het opslagaccount in een regio in de buurt van die clients te plaatsen. Als uw clients breed worden gedistribueerd (bijvoorbeeld sommige in Noord-Amerika en sommige in Europa), kunt u een opslagaccount per regio gebruiken. Deze aanpak is eenvoudiger te implementeren als de gegevens die de app opslaat specifiek zijn voor afzonderlijke gebruikers en als er geen replicatie van gegevens nodig is tussen opslagaccounts.
Voor een brede distributie van blob-inhoud gebruikt u een netwerk voor contentlevering, zoals Azure CDN. Zie Azure CDN voor meer informatie over Azure CDN.
SAS en CORS
Stel dat u code moet machtigen zoals JavaScript dat wordt uitgevoerd in de webbrowser van een gebruiker of in een app op een mobiele telefoon om toegang te krijgen tot gegevens in Azure Storage. Een aanpak is om een servicetoepassing te compileren die als een proxy fungeert. Het apparaat van de gebruiker wordt geverifieerd bij de service, die op zijn beurt toegang tot Azure Storage-resources verleent. Op deze manier kunt u voorkomen dat de sleutels van uw opslagaccount op onveilige apparaten worden weergegeven. Met deze benadering wordt echter een aanzienlijke overhead op de servicetoepassing geplaatst, omdat alle gegevens die worden overgedragen tussen het apparaat van de gebruiker en Azure Storage via de servicetoepassing moeten worden doorgegeven.
U kunt voorkomen dat een servicetoepassing wordt gebruikt als een proxy voor Azure Storage met behulp van Shared Access Signatures (SAS). Met SAS kunt u het apparaat van uw gebruiker in staat stellen om aanvragen rechtstreeks bij Azure Storage in te dienen met behulp van een beperkt toegangstoken. Als een gebruiker bijvoorbeeld een foto wil uploaden naar uw toepassing, kan uw servicetoepassing een SAS genereren en deze verzenden naar het apparaat van de gebruiker. Het SAS-token kan toestemming geven om naar een Azure Storage-resource te schrijven gedurende een opgegeven tijdsinterval, waarna het SAS-token verloopt. Zie Beperkte toegang verlenen tot Azure Storage-resources via SAS (Shared Access Signatures) voor meer informatie over SAS.
Normaal gesproken staat een webbrowser geen JavaScript toe op een pagina die wordt gehost door een website op het ene domein om bepaalde bewerkingen, zoals schrijfbewerkingen, uit te voeren op het andere domein. Op basis van dit beleid, dat bekend staat als 'beleid voor zelfde oorsprong', wordt voorkomen dat een schadelijk script op één pagina de toegang tot gegevens op een andere webpagina kan verkrijgen. Hetzelfde 'beleid voor zelfde oorsprong' kan echter een beperking zijn bij het compileren van een oplossing in de cloud. Cross-Origin Resource Sharing (CORS) is een browserfunctie waarmee het doeldomein van het brondomein afkomstige aanvragen kan doorgeven aan een vertrouwde browser.
Stel bijvoorbeeld dat een webtoepassing die in Azure wordt uitgevoerd een aanvraag voor een resource indient bij een Azure Storage-account. De webtoepassing is het brondomein en het opslagaccount is het doeldomein. U kunt CORS voor elk van de Azure Storage-services configureren om met de webbrowser aanvragen door te geven vanuit het brondomein dat worden vertrouwd door Azure Storage. Zie CORS-ondersteuning (cross-origin resource sharing) voor Azure Storage voor meer informatie over CORS.
Met SAS en CORS kunt u voorkomen dat uw webtoepassing onnodig wordt belast.
Caching
Caching speelt een belangrijke rol in prestaties. In de volgende secties worden de best practices voor caching besproken.
Lezen van de gegevens
Over het algemeen is het beter om gegevens eenmaal te lezen dan twee keer te lezen. Kijk eens naar het voorbeeld van een webtoepassing die een blob van 50 MiB heeft opgehaald uit de Azure Storage als inhoud voor een gebruiker. In het ideale moment wordt de blob door de toepassing lokaal op schijf opgeslagen en wordt vervolgens de in de cache opgeslagen versie opgehaald voor volgende gebruikersaanvragen.
Een manier om te voorkomen dat een blob wordt opgehaald als deze niet is gewijzigd omdat deze in de cache is opgeslagen, is door de GET-bewerking te kwalificeren met een voorwaardelijke header voor de wijzigingstijd. Als de laatste wijziging is na de tijd dat de blob in de cache is opgeslagen, wordt de blob opgehaald en opnieuw in de cache opgeslagen. Anders wordt de blob in de cache opgehaald voor optimale prestaties.
U kunt ook besluiten om uw toepassing te ontwerpen om ervan uit te gaan dat de blob een korte periode ongewijzigd blijft nadat u deze hebt opgehaald. In dit geval hoeft de toepassing niet te controleren of de blob tijdens dat interval is gewijzigd.
Configuratiegegevens, opzoekgegevens en andere gegevens die vaak door de toepassing worden gebruikt, zijn goede kandidaten voor caching.
Zie Specifying conditional headers for Blob service operations (Voorwaardelijke headersopgeven voor Blob service bewerkingen) voor meer informatie over het gebruik van voorwaardelijke headers.
Gegevens in batches uploaden
In sommige scenario's kunt u gegevens lokaal aggregeren en deze vervolgens periodiek uploaden in een batch in plaats van elk stukje gegevens onmiddellijk te uploaden. Stel bijvoorbeeld dat een webtoepassing een logboekbestand met activiteiten bewaart. De toepassing kan details van elke activiteit uploaden terwijl het gebeurt met een tabel (waarvoor veel opslagbewerkingen zijn vereist), of de toepassing kan activiteitsgegevens opslaan in een lokaal logboekbestand en vervolgens periodiek alle activiteitsdetails uploaden als een bestand met scheidingstekens naar een blob. Als elke logboekinvoer 1 kB groot is, kunt u duizenden vermeldingen in één transactie uploaden. Eén transactie ondersteunt het uploaden van een blob van maximaal 64 MiB. De ontwikkelaar van de toepassing moet ontwerpen voor de mogelijkheid van fouten met client-apparaten of uploads. Als de activiteitsgegevens gedurende een tijdsinterval moeten worden gedownload in plaats van voor één activiteit, wordt het gebruik van Blob Storage aanbevolen via Table Storage.
.NET-configuratie
Als u het .NET Framework gebruikt, worden in deze sectie verschillende snelle configuratie-instellingen weergegeven die u kunt gebruiken om belangrijke verbeteringen in de prestaties aan te brengen. Als u andere talen gebruikt, controleert u of er soortgelijke concepten van toepassing zijn in de taal die u hebt gekozen.
.NET Core gebruiken
Ontwikkel uw Azure Storage-toepassingen met .NET Core 2.1 of hoger om te profiteren van de betere prestaties. Het gebruik van .NET Core 3.x wordt aanbevolen als dat mogelijk is.
Raadpleeg de volgende blogberichten voor meer informatie over betere prestaties in .NET Core:
De standaardverbindingslimiet verhogen
In .NET verhoogt de volgende code de standaardverbindingslimiet (meestal twee in een clientomgeving of tien in een serveromgeving) naar 100. Normaal gesproken moet u de waarde instellen op ongeveer het aantal threads dat door uw toepassing wordt gebruikt. Stel de verbindingslimiet in voordat u verbindingen opent.
ServicePointManager.DefaultConnectionLimit = 100; //(Or More)
Zie de documentatie om te bepalen hoe u de verbindingslimiet kunt instellen voor andere programmeertalen.
Zie voor meer informatie het blogbericht Webservices: Gelijktijdige verbindingen.
Minimumaantal threads verhogen
Als u synchrone aanroepen gebruikt in combinatie met asynchrone taken, kunt u misschien beter het aantal threads in de threadpool verhogen:
ThreadPool.SetMinThreads(100,100); //(Determine the right number for your application)
Zie de methode ThreadPool.SetMinThreads voor meer informatie.
Niet-gebonden parallelle uitvoering
Parallelle uitvoering kan ideaal zijn voor de prestaties, maar wees voorzichtig met het gebruik van een ongebonden parallelle uitvoering, wat betekent dat er geen limiet wordt afgedwongen voor het aantal threads of parallelle aanvragen. Zorg ervoor dat u parallelle aanvragen beperkt tot het uploaden of downloaden van gegevens, om toegang te krijgen tot meerdere partities in hetzelfde opslagaccount of om toegang te krijgen tot meerdere items in dezelfde partitie. Als parallelle uitvoering niet is gebonden, kan uw toepassing de mogelijkheden van het clientapparaat of de schaalbaarheidsdoelen van het opslagaccount overschrijden, wat resulteert in langere latenties en bandbreedtebeperking.
Clientbibliotheken en hulpprogramma's
Gebruik altijd de nieuwste clientbibliotheken en hulpprogramma's van Microsoft voor de beste prestaties. Azure Storage-clientbibliotheken zijn beschikbaar in diverse talen. Azure Storage biedt ook ondersteuning voor PowerShell en Azure CLI. Microsoft ontwikkelt deze clientbibliotheken en hulpprogramma's actief met het oog op de prestaties, houdt ze up-to-date met de nieuwste serviceversies en zorgt ervoor dat ze een groot aantal van de bewezen uitvoeringspraktijken intern verwerken.
Servicefouten afhandelen
Azure Storage retourneert een fout wanneer de service een aanvraag niet kan verwerken. Voor het optimaliseren van de prestaties is het handig om inzicht te hebben in de fouten die door Azure Storage in een bepaald scenario kunnen worden geretourneerd.
Time-out- en server-bezetfouten
Azure Storage kan uw toepassing beperken als deze de schaalbaarheidslimieten nadert. In sommige gevallen kan Azure Storage mogelijk geen aanvragen verwerken vanwege een tijdelijke omstandigheid. In beide gevallen kan de service de fout 503 (server bezet) of 500 (time-out) retourneren. Deze fouten kunnen zich ook voordoen als de service gegevenspartities opnieuw moet verdelen voor een hogere doorvoer. De clienttoepassing moet meestal de bewerking opnieuw uitvoeren die een van deze fouten heeft veroorzaakt. Als Azure Storage echter uw toepassing beperkt omdat deze de schaalbaarheidsdoelen overschrijdt of als de service om een andere reden zelfs niet aan de aanvraag kan voldoen, kunnen agressieve nieuwe pogingen het probleem erger maken. Het gebruik van een beleid voor opnieuw proberen met exponentieel uitstel wordt aanbevolen. De clientbibliotheken zijn standaard ingesteld op dit gedrag. Uw toepassing kan bijvoorbeeld na 2 seconden een nieuwe poging doen, daarna na 4 seconden, daarna na 10 seconden, daarna na 30 seconden, en vervolgens volledig opgeven. Op deze manier vermindert uw toepassing de belasting van de service aanzienlijk, in plaats van verergerend gedrag te vertonen dat kan leiden tot aanvraagbeperking.
Bij connectiviteitsfouten kunnen onmiddellijk nieuwe pogingen worden gedaan, omdat ze niet het gevolg zijn van een beperking en naar verwachting tijdelijk zijn.
Fouten waarbij geen nieuwe pogingen mogelijk zijn
Bij de clientbibliotheken is bij het afhandelen van nieuwe pogingen bekend bij welke fouten opnieuw kan worden geprobeerd en welke niet. Als u echter de Azure Storage REST API rechtstreeks aanroept, zijn er enkele fouten waarbij u geen nieuwe pogingen moet ondernemen. Bijvoorbeeld, de fout 400 (ongeldige aanvraag) geeft aan dat de clienttoepassing een aanvraag heeft verzonden die niet kan worden verwerkt omdat deze niet in de verwachte vorm is opgemaakt. Als deze aanvraag opnieuw wordt verzonden, resulteert dit steeds in hetzelfde antwoord, zodat het zinloos is om een nieuwe poging te ondernemen. Als u de REST API Azure Storage rechtstreeks aanroept, moet u rekening houden met mogelijke fouten en of er nieuwe pogingen moeten worden gedaan.
Zie Status en foutcodes voor meer informatie over Azure Storage-foutcodes.
Blobs kopiëren en verplaatsen
Azure Storage biedt een aantal oplossingen voor het kopiëren en verplaatsen van blobs binnen een opslagaccount, tussen opslagaccounts en tussen on-premises systemen en de cloud. In deze sectie worden enkele van deze opties beschreven in termen van de invloed ervan op de prestaties. Zie Een Azure-oplossing kiezen voor gegevensoverdracht voor informatie over het efficiënt overdragen van gegevens naar of van Blob Storage.
API's voor het kopiëren van blobs
Als u blobs wilt kopiëren tussen opslagaccounts, gebruikt u de bewerking Put Block From URL. Met deze bewerking worden gegevens synchroon gekopieerd van een URL-bron naar een blok-blob. Het gebruik Put Block from URL van de bewerking kan de vereiste bandbreedte aanzienlijk verminderen wanneer u gegevens migreert tussen opslagaccounts. Omdat de kopieerbewerking aan de servicezijde plaatsvindt, hoeft u de gegevens niet te downloaden en opnieuw te uploaden.
Als u gegevens binnen hetzelfde opslagaccount wilt kopiëren, gebruikt u de bewerking Blob kopiëren. Het kopiëren van gegevens binnen hetzelfde opslagaccount wordt doorgaans snel voltooid.
AzCopy gebruiken
Het AzCopy-opdrachtregelprogramma is een eenvoudige en efficiënte optie voor bulksgeplaatste overdracht van blobs naar, van en tussen opslagaccounts. AzCopy is geoptimaliseerd voor dit scenario en kan hoge overdrachtssnelheden bereiken. AzCopy versie 10 gebruikt de bewerking Put Block From URL om blobgegevens te kopiëren tussen opslagaccounts. Zie Gegevens kopiëren of verplaatsen naar een Azure Storage behulp van AzCopy v10voor meer informatie.
Gebruik Azure Data Box
Voor het importeren van grote hoeveelheden gegevens in Blob Storage kunt u overwegen om de Azure Data Box voor offlineoverdrachten te gebruiken. Door Microsoft geleverde Data Box zijn een goede keuze voor het verplaatsen van grote hoeveelheden gegevens naar Azure wanneer u wordt beperkt door tijd, netwerkbeschikbaarheid of kosten. Zie de Documentatie voor Azure DataBox voor meer informatie.
Inhoudsdistributie
Soms moet een toepassing dezelfde inhoud leveren aan veel gebruikers (bijvoorbeeld een productdemovideo die wordt gebruikt op de startpagina van een website), die zich in dezelfde of meerdere regio's bevindt. In dit scenario gebruikt u een Content Delivery Network (CDN), zoals Azure CDN om blob-inhoud geografisch te distribueren. In tegenstelling tot een Azure Storage-account dat zich in één regio bevindt en die geen inhoud met lage latentie aan andere regio's kan leveren, gebruikt Azure CDN servers in meerdere datacenters over de hele wereld. Daarnaast biedt een CDN ondersteuning voor veel hogere limieten voor egress dan één opslagaccount.
Zie Azure CDN voor meer informatie over Azure CDN.
Metagegevens gebruiken
De Blob service ondersteuning voor HEAD-aanvragen, die blobeigenschappen of metagegevens kunnen bevatten. Als uw toepassing bijvoorbeeld de exif-gegevens (exchangeable image format) van een foto nodig heeft, kan deze de foto ophalen en uitpakken. Om bandbreedte te besparen en de prestaties te verbeteren, kan uw toepassing de Exif-gegevens opslaan in de metagegevens van de blob wanneer de toepassing de foto uploadt. Vervolgens kunt u de Exif-gegevens in metagegevens ophalen met behulp van alleen een HEAD-aanvraag. Het ophalen van alleen metagegevens en niet de volledige inhoud van de blob bespaart aanzienlijke bandbreedte en vermindert de verwerkingstijd die nodig is om de Exif-gegevens te extraheren. Houd er rekening mee dat 8 KiB metagegevens per blob kan worden opgeslagen.
Upload blobs snel maken
Als u blobs snel wilt uploaden, moet u eerst bepalen of u één blob of veel wilt uploaden. Gebruik de onderstaande richtlijnen om de juiste methode te bepalen, afhankelijk van uw scenario.
Upload snel één grote blob maken
Als u snel één grote blob wilt uploaden, kan een clienttoepassing de blokken of pagina's parallel uploaden, rekening houdend met de schaalbaarheidsdoelen voor afzonderlijke blobs en het opslagaccount als geheel. De Azure Storage clientbibliotheken ondersteunen gelijktijdig uploaden. U kunt bijvoorbeeld de volgende eigenschappen gebruiken om het aantal gelijktijdige aanvragen op te geven dat is toegestaan in .NET of Java. Clientbibliotheken voor andere ondersteunde talen bieden vergelijkbare opties.
- Stel voor .NET de eigenschap BlobRequestOptions.ParallelOperationThreadCount in.
- Roep voor Java/Android de methode BlobRequestOptions.setConcurrentRequestCount(final Integer concurrentRequestCount) aan.
Upload blobs snel maken
Als u snel veel blobs wilt uploaden, uploadt u blobs parallel. Gelijktijdig uploaden is sneller dan het uploaden van één blob tegelijk met parallelle blokuploads, omdat het uploaden over meerdere partities van de opslagservice verspreidt. AzCopy voert standaard gelijktijdige uploads uit en wordt aanbevolen voor dit scenario. Zie Aan de slag met AzCopy voor meer informatie.
Het juiste type blob kiezen
Azure Storage ondersteunt blok-blobs, toevoegende blobs en pagina-blobs. Voor een bepaald gebruiksscenario heeft uw keuze van het blobtype invloed op de prestaties en schaalbaarheid van uw oplossing.
Blok-blobs zijn geschikt als u grote hoeveelheden gegevens efficiënt wilt uploaden. Een clienttoepassing die bijvoorbeeld foto's of video's uploadt naar Blob Storage, is gericht op blok-blobs.
Blobs voor het samenvoegen zijn vergelijkbaar met blok-blobs omdat ze bestaan uit blokken. Wanneer u een toegevoegde blob wijzigt, worden blokken alleen aan het einde van de blob toegevoegd. Toevoeg-blobs zijn handig voor scenario's zoals logboekregistratie, wanneer een toepassing gegevens moet toevoegen aan een bestaande blob.
Pagina-blobs zijn geschikt als de toepassing willekeurige schrijfingen op de gegevens moet uitvoeren. Schijven van virtuele Azure-machines worden bijvoorbeeld opgeslagen als pagina-blobs. Zie Understanding block blobs, append blobs, and page blobs (Blok-blobs, blobs toevoegen en pagina-blobs) voor meer informatie.