Elenco di controllo di prestazioni e scalabilità dell'archiviazione BLOB
Microsoft ha sviluppato una serie di procedure comprovate per lo sviluppo di applicazioni ad alte prestazioni con l'archiviazione BLOB. Questo elenco di controllo identifica le procedure chiave che gli sviluppatori possono seguire per ottimizzare le prestazioni. Tenere presenti queste procedure durante la progettazione dell'applicazione e durante tutto il processo.
Archiviazione di Azure ha degli obiettivi di scalabilità per la capacità, la frequenza di transazioni e la larghezza di banda. Per altre informazioni sugli obiettivi di scalabilità Archiviazione di Azure, vedere Obiettivi di scalabilità e prestazioni per gli account di archiviazione standard e obiettivi di scalabilità e prestazioni per l'archiviazione BLOB.
Elenco di controllo
Questo articolo organizza le procedure comprovate per le prestazioni in un elenco di controllo che è possibile seguire durante lo sviluppo dell'applicazione di archiviazione BLOB.
Obiettivi di scalabilità
Se l'applicazione raggiunge o supera uno o più obiettivi di scalabilità, può verificarsi un aumento delle latenze o delle limitazioni della transazione. Quando Archiviazione di Azure limita l'applicazione, il servizio inizia a restituire i codici di errore "503 Server occupato" o "500 Timeout operazione". Evitare questi errori rispettando i limiti degli obiettivi di scalabilità è una parte importante del miglioramento delle prestazioni dell'applicazione.
Per altre informazioni sugli obiettivi di scalabilità per il Servizio di accodamento, vedere Obiettivi di scalabilità e prestazioni per Archiviazione di Azure.
Numero massimo di account di archiviazione
Se si sta raggiungendo il numero massimo di account di archiviazione consentiti per una determinata combinazione di sottoscrizioni/aree, valutare lo scenario e determinare se si applica una delle condizioni seguenti:
- Si usano gli account di archiviazione per archiviare i dischi non gestiti e aggiungere tali dischi alle macchine virtuali? Per questo scenario, Microsoft consiglia di usare dischi gestiti. I dischi gestiti vengono ridimensionati automaticamente e senza la necessità di creare e gestire singoli account di archiviazione. Per altre informazioni, vedere Introduzione ai dischi gestiti di Azure
- Si usa un account di archiviazione per cliente allo scopo dell'isolamento dei dati? Per questo scenario, Microsoft consiglia di usare un contenitore BLOB per ogni cliente, anziché un intero account di archiviazione. Archiviazione di Azure ora consente di assegnare ruoli di Azure per ogni contenitore. Per altre informazioni, vedere Assegnare un ruolo di Azure per l'accesso ai dati BLOB.
- Si usano più account di archiviazione per partizionare per aumentare l'ingresso, l'uscita, le operazioni di I/O al secondo o la capacità? In questo scenario, se possibile Microsoft consiglia di sfruttare l'innalzamento dei limiti degli account di archiviazione per ridurre il numero di account di archiviazione necessari per il carico di lavoro. Contattare il supporto di Azure per richiedere l'espansione dei limiti dell'account di archiviazione.
Obiettivi di capacità e transazioni
Se l'applicazione sta raggiungendo gli obiettivi di scalabilità per un singolo account di archiviazione, valutare uno dei seguenti approcci:
- Se l'applicazione raggiunge la destinazione della transazione, prendere in considerazione l'uso di account di archiviazione BLOB in blocchi, ottimizzati per frequenze di transazioni elevate e la latenza bassa e coerente. Per altre informazioni, vedere Panoramica dell'account di archiviazione di Azure.
- Esaminare di nuovo il carico di lavoro che causa il raggiungimento o il superamento dell'obiettivo di scalabilità da parte dell'applicazione. È possibile progettarlo in modo diverso in modo che usi una quantità minore di larghezza di banda o capacità o un minor numero di transazioni?
- Se l'applicazione deve superare uno degli obiettivi di scalabilità, creare più account di archiviazione e partizionare i dati dell'applicazione tra questi account di archiviazione. Se si usa questo modello, assicurarsi di progettare l'applicazione in modo da aggiungere altri account di archiviazione in futuro per il bilanciamento del carico. Gli stessi account di archiviazione non hanno costi aggiuntivi rispetto a quelli per l'uso, ossia associati ai dati archiviati, alle transazioni effettuate o ai dati trasferiti.
- Se l'applicazione sta raggiungendo gli obiettivi di larghezza di banda, valutare la compressione dei dati sul lato client per ridurre la larghezza di banda necessaria a inviare i dati ad Archiviazione di Azure. La compressione dei dati, pur consentendo di risparmiare larghezza di banda e migliorare le prestazioni di rete, può avere anche degli effettivi negativi sulle prestazioni. Valutare gli effetti sulle prestazioni dei requisiti di elaborazione aggiuntivi per la compressione e la decompressione dei dati sul lato client. Tenere presente che l'archiviazione dei dati compressi può rendere più difficile la risoluzione dei problemi perché ostacola la visualizzazione dei dati usando gli strumenti standard.
- Se l'applicazione sta raggiungendo gli obiettivi di scalabilità, assicurarsi di usare un backoff esponenziale per i tentativi. È consigliabile provare a evitare di raggiungere gli obiettivi di scalabilità implementando i consigli descritti in questo articolo. Tuttavia, l'uso di un backoff esponenziale per i tentativi impedisce all'applicazione di riprovare rapidamente, cosa che potrebbe peggiorare la limitazione. Per altre informazioni, vedere la sezione intitolata Errori di timeout e server occupato.
Più client che accedono a un singolo BLOB contemporaneamente
Se si ha un numero elevato di client che accedono contemporaneamente a un singolo BLOB, è necessario considerare sia gli obiettivi di scalabilità per BLOB che per account di archiviazione. Il numero esatto di client che possono accedere a un singolo BLOB varia a seconda di fattori quali il numero di client che richiedono il BLOB contemporaneamente, le dimensioni del BLOB e le condizioni di rete.
Se il BLOB può essere distribuito tramite una rete CDN, ad esempio immagini o video forniti da un sito Web, è possibile usare una rete CDN. Per altre informazioni, vedere la sezione intitolata Distribuzione del contenuto.
In altri scenari, ad esempio simulazioni scientifiche in cui i dati sono riservati, sono disponibili due opzioni. Il primo consiste nello sfalsare l'accesso del carico di lavoro in modo che l'accesso al BLOB venga eseguito in un periodo di tempo rispetto all'accesso simultaneo. In alternativa, è possibile copiare temporaneamente il BLOB in più account di archiviazione per aumentare le operazioni di I/O al secondo totali per BLOB e tra account di archiviazione. I risultati variano a seconda del comportamento dell'applicazione, quindi assicurarsi di testare i modelli di concorrenza durante la progettazione.
Larghezza di banda e operazioni per BLOB
Un singolo BLOB supporta fino a 500 richieste al secondo. Se si dispone di più client che devono leggere lo stesso BLOB e si potrebbe superare questo limite, prendere in considerazione l'uso di un account di archiviazione BLOB in blocchi. Un account di archiviazione BLOB in blocchi offre una frequenza di richieste superiore o operazioni di I/O al secondo (IOPS).
È anche possibile usare una rete per la distribuzione di contenuti (RETE CDN), ad esempio Rete CDN di Azure per distribuire le operazioni nel BLOB. Per altre informazioni sulle Rete CDN di Azure, vedere panoramica di Rete CDN di Azure.
Partizionamento
Comprendere in che modo Archiviazione di Azure partizionare i dati DEL BLOB è utile per migliorare le prestazioni. Archiviazione di Azure può gestire i dati in una singola partizione più rapidamente rispetto ai dati che si estendono su più partizioni. Assegnando un nome appropriato ai BLOB, è possibile migliorare l'efficienza delle richieste di lettura.
L'archiviazione BLOB usa uno schema di partizionamento basato su intervalli per il ridimensionamento e il bilanciamento del carico. Ogni BLOB ha una chiave di partizione costituita dal nome completo del BLOB (account+contenitore+BLOB). La chiave di partizione viene usata per partizionare i dati BLOB in intervalli. Gli intervalli vengono quindi caricati con bilanciamento del carico nell'archivio BLOB.
Il partizionamento basato su intervallo indica che le convenzioni di denominazione che usano l'ordinamento lessicale (ad esempio, mypayroll, myperformance, myemployees e così via) o timestamp (log20160101, log20160102, log20160102 e così via) è più probabile che le partizioni si trovino nello stesso server di partizione fino a quando non è necessario che vengano suddivisi in intervalli più piccoli. La condivisione dell'individuazione di BLOB nello stesso server di partizione migliora le prestazioni, quindi una parte importante del miglioramento delle prestazioni comporta la denominazione dei BLOB in modo da organizzarli in modo più efficace.
Ad esempio, tutti i BLOB in un contenitore possono essere serviti da un singolo server fino a quando il carico di questi BLOB richiede un ulteriore bilanciamento degli intervalli di partizione. Analogamente, un gruppo di account caricati in modo leggero con i relativi nomi disposti in ordine lessicale può essere gestito da un singolo server fino a quando il carico su uno o tutti questi account richiede la suddivisione tra più server di partizione.
Ogni operazione di bilanciamento del carico può incidere negativamente sulla latenza delle chiamate di archiviazione durante l'operazione. La capacità del servizio di gestire un improvviso burst di traffico verso una partizione è limitata dalla scalabilità di un singolo server di partizione fino all'avvio dell'operazione di bilanciamento del carico e ribilancia l'intervallo di chiavi di partizione.
Alcune procedure consigliate consentono di ridurre la frequenza di queste operazioni.
Se possibile, usare dimensioni blob o blocchi superiori a 256 KiB per gli account di archiviazione Standard e Premium. Le dimensioni di BLOB o blocchi maggiori attivano automaticamente BLOB in blocchi a velocità effettiva elevata. I BLOB in blocchi a velocità effettiva elevata forniscono inserimenti ad alte prestazioni che non sono interessati dalla denominazione delle partizioni.
Esaminare le convenzioni di denominazione usate per account, contenitori, BLOB, tabelle e code. Considerare la possibilità di anteporre ai nomi degli account, dei contenitori o dei blob un hash di tre cifre, mediante la funzione di hashing più adatta alle esigenze.
Se si organizzano i dati usando timestamp o identificatori numerici, assicurarsi di non usare un modello di traffico di sola accodamento (o solo anteporre). Questi modelli non sono adatti per un sistema di partizionamento basato su intervalli. Questi modelli possono portare a tutto il traffico che passa a una singola partizione e limita il sistema dal bilanciamento del carico in modo efficace.
Ad esempio, se si dispone di operazioni giornaliere che usano un BLOB con un timestamp, ad esempio aammmmgg, tutto il traffico per tale operazione giornaliera viene indirizzato a un singolo BLOB, gestito da un singolo server di partizione. Valutare se i limiti per BLOB e i limiti per partizione soddisfano le esigenze e prendere in considerazione l'interruzione di questa operazione in più BLOB, se necessario. Analogamente, se si archiviano i dati delle serie temporali nelle tabelle, tutto il traffico può essere indirizzato all'ultima parte dello spazio dei nomi della chiave. Se si usano ID numerici, anteporre all'ID un hash a tre cifre. Se si usano timestamp, anteporre il timestamp con il valore dei secondi, ad esempio ssyymmdd. Se l'applicazione esegue regolarmente operazioni di elenco ed esecuzione di query, scegliere una funzione hash che limita il numero di query. In alcuni casi, un prefisso casuale può essere sufficiente.
Per altre informazioni sullo schema di partizionamento usato in Archiviazione di Azure, vedere Archiviazione di Azure: Servizio di archiviazione cloud a disponibilità elevata con coerenza assoluta.
Rete
I vincoli fisici della rete dell'applicazione possono avere effetti significativi sulle prestazioni. Le sezioni seguenti descrivono alcune limitazioni che gli utenti possono incontrare.
Capacità della rete client
La larghezza di banda e la qualità del collegamento di rete svolgono ruoli importanti nelle prestazioni dell'applicazione, come descritto nelle sezioni seguenti.
Velocità effettiva
Per la larghezza di banda il problema dipende spesso dalle capacità del client. Le istanze di Azure più grandi possono avere schede di interfaccia di rete con capacità più elevate ed è quindi opportuno prendere in considerazione l'uso di un'istanza più grande o di più macchine virtuali se è necessario che un singolo computer abbia limiti di rete più elevati. Se si accede Archiviazione di Azure da un'applicazione locale, si applica la stessa regola: comprendere le funzionalità di rete del dispositivo client e la connettività di rete al percorso di Archiviazione di Azure e migliorarle in base alle esigenze o progettare l'applicazione per funzionare entro le relative funzionalità.
Qualità del collegamento
Come per qualsiasi utilizzo di rete, tenere presente che le condizioni di rete che causano errori e perdita di pacchetti rallentano la velocità effettiva effettiva. L'uso di WireShark o NetMon può contribuire a diagnosticare il problema.
Ufficio
In qualsiasi ambiente distribuito, il posizionamento del client accanto al server offre le prestazioni migliori. Per accedere all'archiviazione di Azure con la minor latenza possibile, è opportuno posizionare il client nella stessa area di Azure. Ad esempio, se si ha un'app Web di Azure che usa Archiviazione di Azure, posizionare entrambi in un'unica area, ad esempio Stati Uniti occidentali o Asia sudorientale. Il posizionamento delle risorse nella stessa area riduce latenza e costi, in quanto l'utilizzo della larghezza di banda in un'unica area è gratuito.
Se le applicazioni client accedono Archiviazione di Azure ma non sono ospitate in Azure, ad esempio app per dispositivi mobili o servizi aziendali locali, l'individuazione dell'account di archiviazione in un'area vicina a tali client può ridurre la latenza. Se i client sono distribuiti in un'area ampia (ad esempio, alcuni in America del Nord e altri in Europa), è opportuno usare un account di archiviazione per ogni area. Questo approccio è più semplice da implementare se i dati archiviati dall'applicazione sono specifici per i singoli utenti e non richiedono la replica dei dati tra gli account di archiviazione.
Per una distribuzione generale del contenuto BLOB, usare una rete per la distribuzione di contenuti, ad esempio Rete CDN di Azure. Per altre informazioni sulla rete CDN di Azure, vedere rete CDN di Azure.
SAS e CORS
Si supponga che sia necessario autorizzare il codice, ad esempio JavaScript, che viene eseguito nel Web browser dell'utente o in un'app per telefoni cellulari per accedere ai dati in Archiviazione di Azure. Un approccio consiste nel creare un'applicazione di servizio che funga da proxy. Il dispositivo dell'utente esegue l'autenticazione con il servizio, che a sua volta autorizza l'accesso alle risorse di Archiviazione di Azure. In questo modo si evita di esporre le chiavi dell'account di archiviazione in dispositivi non sicuri. Questo approccio causa tuttavia un sovraccarico significativo dell'applicazione di servizio, perché tutti i dati trasferiti tra il dispositivo dell'utente e Archiviazione di Azure devono passare attraverso l'applicazione di servizio.
È possibile evitare di usare un'applicazione di servizio come proxy per Archiviazione di Azure usando firme di accesso condiviso. Con le firme di accesso condiviso è possibile consentire al dispositivo dell'utente di indirizzare le richieste direttamente ad Archiviazione di Azure usando un token con accesso limitato. Ad esempio, se un utente vuole caricare una foto nell'applicazione, l'applicazione di servizio può generare una firma di accesso condiviso e inviarla al dispositivo dell'utente. Il token di firma di accesso condiviso può concedere l'autorizzazione per scrivere in una risorsa di Archiviazione di Azure per un intervallo di tempo specificato, dopo la scadenza del token di firma di accesso condiviso. Per altre informazioni sulla firma di accesso condiviso, vedere Concedere accesso limitato alle risorse di archiviazione di Azure tramite firme di accesso condiviso.
In genere, un Web browser non consente a JavaScript in una pagina ospitata da un sito Web in un dominio di eseguire determinate operazioni, ad esempio le operazioni di scrittura, in un altro dominio. Noto come criterio di corrispondenza dell'origine, questo criterio impedisce a uno script dannoso in una pagina di ottenere l'accesso ai dati in un'altra pagina Web. Tuttavia, i criteri di corrispondenza dell'origine possono costituire una limitazione quando si compila una soluzione nel cloud. La condivisione di risorse tra le origini è una funzionalità del browser che consente al dominio di destinazione di comunicare con il browser di cui reputa attendibili le richieste originate nel dominio di origine.
Si supponga, ad esempio, che un'applicazione Web in esecuzione in Azure faccia una richiesta di una risorsa a un account di Archiviazione di Azure. L'applicazione Web è il dominio di origine e l'account di archiviazione è il dominio di destinazione. È possibile configurare la condivisione di risorse tra le origini per qualsiasi servizio di Archiviazione di Azure in modo che comunichi con il Web browser che le richieste provenienti dal dominio di origine siano ritenuti attendibili da Archiviazione di Azure. Per altre informazioni sulla condivisione di risorse tra le origini, vedere Supporto della condivisione delle risorse tra le origini (CORS) per Archiviazione di Azure.
Entrambe le tecnologie SAS e CORS possono aiutare a evitare carichi non necessari nell'applicazione Web.
Memorizzazione nella cache
La memorizzazione nella cache svolge un ruolo importante nelle prestazioni. Le sezioni seguenti illustrano le procedure consigliate per la memorizzazione nella cache.
Lettura dei dati
In generale, leggere i dati una volta è preferibile leggerli due volte. Si consideri l'esempio di un'applicazione Web che ha recuperato un BLOB MiB da 50 miB dal Archiviazione di Azure per fungere da contenuto a un utente. Idealmente, l'applicazione memorizza nella cache il BLOB in locale su disco e quindi recupera la versione memorizzata nella cache per le richieste utente successive.
Un modo per evitare di recuperare un BLOB se non è stato modificato perché è stato memorizzato nella cache consiste nel qualificare l'operazione GET con un'intestazione condizionale per il tempo di modifica. Se l'ora dell'ultima modifica è dopo l'ora in cui il BLOB è stato memorizzato nella cache, il BLOB viene recuperato e memorizzato nuovamente nella cache. In caso contrario, il BLOB memorizzato nella cache viene recuperato per ottenere prestazioni ottimali.
È anche possibile decidere di progettare l'applicazione per presupporre che il BLOB rimanga invariato per un breve periodo dopo il recupero. In questo caso, l'applicazione non deve controllare se il BLOB è stato modificato durante tale intervallo.
I dati di configurazione, i dati di ricerca e altri dati usati di frequente dall'applicazione sono buoni candidati per la memorizzazione nella cache.
Per altre informazioni sull'uso delle intestazioni condizionali, vedere Specifica delle intestazioni condizionali per le operazioni del servizio BLOB.
Caricamento di dati in batch
In alcuni scenari è possibile aggregare i dati in locale e quindi caricarli periodicamente in un batch invece di caricare immediatamente ogni parte di dati. Si supponga, ad esempio, che un'applicazione Web mantenga un file di log delle attività. L'applicazione può caricare i dettagli di ogni attività mentre si verifica in una tabella (che richiede molte operazioni di archiviazione) oppure può salvare i dettagli dell'attività in un file di log locale e quindi caricare periodicamente tutti i dettagli dell'attività come file delimitato in un BLOB. Se ogni voce di log ha dimensioni pari a 1 KB, è possibile caricare migliaia di voci in una singola transazione. Una singola transazione supporta il caricamento di un BLOB di dimensioni fino a 64 MiB. Lo sviluppatore dell'applicazione deve progettare per la possibilità di errori di caricamento o dispositivo client. Se i dati dell'attività devono essere scaricati per un intervallo di tempo anziché per una singola attività, è consigliabile usare l'archiviazione BLOB tramite l'archiviazione tabelle.
Configurazione .NET
Per i progetti che usano .NET Framework, questa sezione elenca alcune impostazioni di configurazione rapide che è possibile usare per apportare miglioramenti significativi delle prestazioni. Se si usa un linguaggio diverso da .NET, verificare se si applicano concetti simili nel linguaggio scelto.
Aumento del limite di connessione predefinito
Nota
Questa sezione si applica ai progetti che usano .NET Framework, perché il pool di connessioni è controllato dalla classe ServicePointManager. .NET Core ha introdotto una modifica significativa rispetto alla gestione del pool di connessioni, in cui il pool di connessioni avviene a livello httpClient e le dimensioni del pool non sono limitate per impostazione predefinita. Ciò significa che le connessioni HTTP vengono ridimensionate automaticamente per soddisfare il carico di lavoro. È consigliabile usare la versione più recente di .NET, quando possibile, per sfruttare i miglioramenti delle prestazioni.
Per i progetti che usano .NET Framework, è possibile usare il codice seguente per aumentare il limite di connessione predefinito (in genere due in un ambiente client o dieci in un ambiente server) a 100. Solitamente il valore deve essere impostato basandosi approssimativamente sul numero di thread usato dall'applicazione. Impostare il limite di connessione prima di aprire le connessioni.
ServicePointManager.DefaultConnectionLimit = 100; //(Or More)
Per altre informazioni sui limiti del pool di connessioni in .NET Framework, vedere Limiti del pool di connessioni .NET Framework e il nuovo Azure SDK per .NET.
Per altri linguaggi di programmazione, vedere la documentazione per determinare come impostare il limite di connessione.
Aumentare il numero minimo di thread
Se si usano chiamate sincrone con attività asincrone, è possibile aumentare il numero di thread nel pool di thread:
ThreadPool.SetMinThreads(100,100); //(Determine the right number for your application)
Per altre informazioni, vedere il metodo ThreadPool.SetMinThreads.
Parallelismo non associato
Anche se il parallelismo può essere ottimale per le prestazioni, prestare attenzione all'uso del parallelismo non associato, ovvero non esiste alcun limite applicato al numero di thread o richieste parallele. Assicurarsi di limitare le richieste parallele per caricare o scaricare dati, per accedere a più partizioni nello stesso account di archiviazione o per accedere a più elementi nella stessa partizione. Se il parallelismo non è associato, l'applicazione può superare le capacità del dispositivo client o gli obiettivi di scalabilità dell'account di archiviazione producendo latenze più lunghe e limitazioni.
Librerie e strumenti client dell'archiviazione
Per ottenere le migliori prestazioni, usare sempre l'ultima versione delle librerie e degli strumenti client forniti da Microsoft. Le librerie client di Archiviazione di Azure sono disponibili per diversi linguaggi. Archiviazione di Azure supporta anche PowerShell e l'interfaccia della riga di comando di Azure. Microsoft sviluppa attivamente questi strumenti e librerie client concentrandosi sulle prestazioni, li mantiene aggiornati con le ultime versioni del servizio e verifica che siano in grado di gestire internamente gran parte delle procedure comprovate relative alle prestazioni.
Suggerimento
Il driver ABFS è stato progettato per superare le carenze intrinseche di WASB. Microsoft consiglia di usare il driver ABFS tramite il driver WASB, perché il driver ABFS è ottimizzato in modo specifico per l'analisi dei Big Data.
Gestire gli errori del servizio
Archiviazione di Azure restituisce un errore quando il servizio non è in grado di elaborare una richiesta. La comprensione degli errori che possono essere restituiti da Archiviazione di Azure in un determinato scenario è utile per ottimizzare le prestazioni. Per un elenco dei codici di errore comuni, vedere Codici di errore comuni dell'API REST.
Errori di timeout e server occupato
Archiviazione di Azure può limitare l'applicazione se raggiunge i limiti di scalabilità. In alcuni casi, Archiviazione di Azure potrebbe non riuscire a gestire una richiesta a causa di una condizione temporanea. In entrambi i casi, il servizio può restituire un errore 503 (Server occupato) o 500 (Timeout). Questi errori possono verificarsi anche se il servizio esegue il ribilanciamento delle partizioni di dati per consentire una maggiore velocità effettiva. L'applicazione client in genere deve ripetere l'operazione che ha causato uno di questi errori. Tuttavia, se Archiviazione di Azure limita l'applicazione perché supera gli obiettivi di scalabilità o anche se il servizio non è in grado di soddisfare la richiesta per qualche altro motivo, i tentativi aggressivi potrebbero peggiorare il problema. È consigliabile l'uso di criteri di ripetizione del backoff esponenziale, ovvero il comportamento predefinito nelle librerie client. Ad esempio, l'applicazione può riprovare l'operazione dopo 2 secondi, 4 secondi, 10 secondi, 30 secondi, dopo di che non effettua altri tentativi. Piuttosto che peggiorare il problema, in questo modo si riduce notevolmente il carico dell'applicazione sul servizio che potrebbe condurre alla limitazione della larghezza di banda della rete.
Gli errori di connettività possono essere ritentati immediatamente, perché non sono il risultato della limitazione e dovrebbero essere temporanei.
Errori irreversibili
Le librerie client gestiscono i tentativi con la consapevolezza degli errori che possono essere ritentati e che non possono essere ritentati. Tuttavia, se si chiama direttamente l'API REST Archiviazione di Azure, ci sono alcuni errori che non è consigliabile riprovare. Ad esempio, un errore 400 (richiesta non valida) indica che l'applicazione client ha inviato una richiesta che non è stato possibile elaborare perché non era nel formato previsto. Il nuovo invio di questa richiesta restituisce la stessa risposta ogni volta, quindi non è necessario riprovare. Se si chiama direttamente l'API REST Archiviazione di Azure, tenere presente eventuali errori e verificare se devono essere ritentati.
Per altre informazioni sui codici di errore di Archiviazione di Azure, vedere Stato e codici errore.
Copia e spostamento di BLOB
Archiviazione di Azure offre una serie di soluzioni per la copia e lo spostamento di BLOB all'interno di un account di archiviazione, tra gli account di archiviazione e tra i sistemi locali e il cloud. Questa sezione descrive alcune di queste opzioni in termini di effetti sulle prestazioni. Per informazioni sul trasferimento efficiente dei dati da o verso l'archiviazione BLOB, vedere Scegliere una soluzione di Azure per il trasferimento dei dati.
API di copia BLOB
Per copiare BLOB tra gli account di archiviazione, usare l'operazione Put Block From URL .To copy blobs across storage accounts, use the Put Block From URL operation. Questa operazione copia i dati in modo sincrono da qualsiasi origine URL in un BLOB in blocchi. L'uso dell'operazione può ridurre significativamente la Put Block from URL larghezza di banda necessaria quando si esegue la migrazione dei dati tra gli account di archiviazione. Poiché l'operazione di copia viene eseguita sul lato servizio, non è necessario scaricare e caricare nuovamente i dati.
Per copiare i dati all'interno dello stesso account di archiviazione, usare l'operazione Copia BLOB . La copia dei dati all'interno dello stesso account di archiviazione viene in genere completata rapidamente.
Usare AzCopy
L'utilità della riga di comando AzCopy è un'opzione semplice ed efficiente per il trasferimento bulk di BLOB da, da e tra account di archiviazione. AzCopy è ottimizzato per questo scenario e può ottenere velocità di trasferimento elevate. AzCopy versione 10 usa l'operazione Put Block From URL per copiare i dati BLOB tra gli account di archiviazione. Per altre informazioni, vedere Copiare o spostare dati in Archiviazione di Azure usando AzCopy v10.
Usare Azure Data Box.
Per l'importazione di grandi volumi di dati nell'archivio BLOB, è consigliabile usare la famiglia Azure Data Box per i trasferimenti offline. I dispositivi Data Box forniti da Microsoft sono una buona scelta per spostare grandi quantità di dati in Azure quando si è limitati in base a tempo, disponibilità di rete o costi. Per altre informazioni, vedere la documentazione di Azure DataBox.
Distribuzione di contenuti
A volte un'applicazione deve gestire lo stesso contenuto a molti utenti (ad esempio, un video dimostrativo del prodotto usato nella home page di un sito Web), che si trova nella stessa area o in più aree. In questo scenario usare una rete CDN (rete per la distribuzione di contenuti), ad esempio Frontdoor di Azure. Frontdoor di Azure è la rete CDN cloud moderna di Microsoft che offre accesso rapido, affidabile e sicuro tra gli utenti e il contenuto Web statico e dinamico delle applicazioni in tutto il mondo. Frontdoor di Azure offre il contenuto dell'archiviazione BLOB usando la rete perimetrale globale di Microsoft con centinaia di punti di presenza globali e locali (PoP). Una rete CDN può in genere supportare limiti di uscita molto più elevati rispetto a un singolo account di archiviazione e offre una migliore latenza per la distribuzione di contenuti ad altre regoin.
Per altre informazioni su Frontdoor di Azure, vedere Frontdoor di Azure.
Usare i metadati
Il servizio BLOB supporta le richieste HEAD, che possono includere proprietà o metadati del BLOB. Ad esempio, se l'applicazione richiede i dati exif (formato immagine scambiabile) da una foto, può recuperare la foto ed estrarla. Per risparmiare larghezza di banda e migliorare le prestazioni, l'applicazione può archiviare i dati Exif nei metadati del BLOB quando l'applicazione carica la foto. È quindi possibile recuperare i dati Exif nei metadati usando solo una richiesta HEAD. Il recupero solo dei metadati e non il contenuto completo del BLOB consente di risparmiare larghezza di banda significativa e riduce il tempo di elaborazione necessario per estrarre i dati Exif. Tenere presente che è possibile archiviare 8 KiB di metadati per BLOB.
Aggiornamenti dei metadati dell'account e del contenitore
I metadati dell'account e del contenitore vengono propagati nel servizio di archiviazione nell'area in cui risiede l'account. La propagazione completa di questi metadati può richiedere fino a 60 secondi a seconda dell'operazione. Ad esempio:
- Se si sta creando, eliminando e ricreando gli account con lo stesso nome di account nella stessa area, assicurarsi di attendere 60 secondi affinché lo stato dell'account venga propagato completamente o che le richieste non riescano.
- Quando si stabilisce un criterio di accesso archiviato in un contenitore, l'applicazione dei criteri potrebbe richiedere fino a 30 secondi.
Ottimizzazione delle prestazioni per i trasferimenti di dati
Quando un'applicazione trasferisce i dati usando la libreria client Archiviazione di Azure, esistono diversi fattori che possono influire sulla velocità, sull'utilizzo della memoria e persino sull'esito positivo o negativo della richiesta. Per ottimizzare le prestazioni e l'affidabilità per i trasferimenti di dati, è importante essere proattivi nella configurazione delle opzioni di trasferimento della libreria client in base all'ambiente in cui viene eseguita l'app. Per altre informazioni, vedere Ottimizzazione delle prestazioni per caricamenti e download.
Caricare rapidamente i BLOB
Per caricare rapidamente i BLOB, determinare prima di tutto se si sta caricando un BLOB o molti. Usare le indicazioni seguenti per determinare il metodo corretto da usare a seconda dello scenario. Se si usa la libreria client Archiviazione di Azure per i trasferimenti di dati, vedere Ottimizzazione delle prestazioni per i trasferimenti di dati per altre indicazioni.
Caricare rapidamente un BLOB di grandi dimensioni
Per caricare rapidamente un singolo BLOB di grandi dimensioni, un'applicazione client può caricare i blocchi o le pagine in parallelo, tenendo presenti gli obiettivi di scalabilità per singoli BLOB e l'account di archiviazione nel suo complesso. Le librerie client Archiviazione di Azure supportano il caricamento in parallelo. Le librerie client per altre lingue supportate offrono opzioni simili.
Caricare rapidamente molti BLOB
Per caricare rapidamente più BLOB, caricarli in parallelo. Il caricamento in parallelo è più veloce rispetto al caricamento di singoli BLOB alla volta con caricamenti di blocchi paralleli perché distribuisce il caricamento tra più partizioni del servizio di archiviazione. AzCopy esegue i caricamenti in parallelo per impostazione predefinita ed è consigliato per questo scenario. Per altre informazioni, vedere Introduzione ad AzCopy.
Scegliere il tipo di BLOB corretto
Archiviazione di Azure supporta BLOB in blocchi, BLOB di accodamento e BLOB di pagine. Per uno scenario di utilizzo specifico, la scelta del tipo di BLOB influisce sulle prestazioni e sulla scalabilità della soluzione.
I BLOB in blocchi sono appropriati quando si vogliono caricare in modo efficiente grandi quantità di dati. Ad esempio, un'applicazione client che carica foto o video nell'archivio BLOB è destinata ai BLOB in blocchi.
I BLOB di accodamento sono simili ai BLOB in blocchi in quanto sono costituiti da blocchi. Quando si modifica un BLOB di accodamento, i blocchi vengono aggiunti solo alla fine del BLOB. I BLOB di accodamento sono utili per scenari come la registrazione, quando un'applicazione deve aggiungere dati a un BLOB esistente.
I BLOB di pagine sono appropriati se l'applicazione deve eseguire scritture casuali sui dati. Ad esempio, i dischi delle macchine virtuali di Azure vengono archiviati come BLOB di pagine. Per altre informazioni, vedere Informazioni sui BLOB in blocchi, sui BLOB di accodamento e sui BLOB di pagine.