Elenco di controllo di prestazioni e scalabilità di Archiviazione tabelle
Microsoft ha sviluppato molte procedure comprovate per lo sviluppo di applicazioni ad alte prestazioni con l'archiviazione tabelle. 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à di Archiviazione di Azure, vedere Obiettivi di scalabilità e prestazioni per gli account di archiviazione standard e Obiettivi di scalabilità e prestazioni per l'archiviazione tabelle.
Elenco di controllo
Questo articolo organizza procedure consolidate per le prestazioni in un elenco di controllo che è possibile seguire durante lo sviluppo dell'applicazione di Archiviazione tabelle.
Obiettivi di scalabilità
Se l'applicazione si avvicina o supera uno degli obiettivi di scalabilità, potrebbe verificarsi un aumento delle latenze delle transazioni o una limitazione. 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 tabelle, vedere Obiettivi di scalabilità e prestazioni per l'archiviazione tabelle.
Numero massimo di account di archiviazione
Se si sta per raggiungere il numero massimo di account di archiviazione consentiti per una determinata combinazione di sottoscrizione/area, si usano più account di archiviazione da partizionare per aumentare il traffico in ingresso, in 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:
- 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. Mentre la compressione dei dati potrebbe risparmiare larghezza di banda e migliorare le prestazioni di rete, può anche avere effetti 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 nuovi 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 ritentare rapidamente, il che potrebbe peggiorare la limitazione delle richieste. Per altre informazioni, vedere la sezione intitolata Errori di timeout e server occupato.
Obiettivi per le operazioni sui dati
Archiviazione di Azure il bilanciamento del carico man mano che il traffico verso l'account di archiviazione aumenta, ma se il traffico presenta picchi improvvisi, potrebbe non essere possibile ottenere immediatamente questo volume di velocità effettiva. Durante i picchi è probabile che si verifichino limitazioni della larghezza di banda della rete e/o timeout, in quanto Archiviazione di Azure esegue automaticamente il bilanciamento del carico della tabella. Un incremento lento in genere produce risultati migliori perché lascia al sistema il tempo di bilanciare il carico in modo corretto.
Entità al secondo (account di archiviazione)
Il limite di scalabilità per l'accesso alle tabelle è di 20.000 entità (1 KB ciascuna) al secondo per un account. In generale ogni entità inserita, aggiornata, eliminata o analizzata viene presa in considerazione ai fini del calcolo per l'obiettivo. Quindi, un inserimento batch che contiene 100 entità conta come 100 entità. Una query che analizza 1000 entità e ne restituisce 5 conta come 1000 entità.
Entità al secondo (partizione)
In una singola partizione l'obiettivo di scalabilità per l'accesso alle tabelle è di 2.000 entità (1 KB ciascuna) al secondo, usando lo stesso conteggio descritto nella sezione precedente.
Rete
I vincoli di rete fisica dell'applicazione potrebbero avere un impatto significativo sulle prestazioni. Le sezioni seguenti descrivono alcune limitazioni che gli utenti potrebbero riscontrare.
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.
Titolo
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 potrebbe 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.
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.
Transazioni batch
Il servizio tabelle supporta le transazioni batch sulle entità che si trovano nella stessa tabella e appartengono allo stesso gruppo di partizioni. Per altre informazioni, vedere la sezione Esecuzione di transazioni di gruppi di entità.
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 2 in un ambiente client o 10 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 Connessione ion di .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. Archiviazione di Azure librerie client sono disponibili per varie lingue. 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.
Gestire gli errori del servizio
Archiviazione di Azure restituisce un errore quando il servizio non è in grado di elaborare una richiesta. Comprendere gli errori restituiti da Archiviazione di Azure in uno scenario specifico è utile per ottimizzare le prestazioni.
Errori di timeout e server occupato
Archiviazione di Azure potrebbe limitare l'applicazione se si avvicina ai limiti di scalabilità. In alcuni casi, Archiviazione di Azure potrebbe non essere in grado di gestire una richiesta a causa di una condizione temporanea. In entrambi i casi, il servizio potrebbe 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 un 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 potrebbe riprovare dopo 2 secondi, quindi 4 secondi, 10 secondi, quindi 30 secondi e quindi rinunciare completamente. 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.
Connessione gli errori possono essere ritentati immediatamente, perché non sono il risultato della limitazione e si prevede che siano temporanei.
Errori irreversibili
Le librerie client gestiscono i tentativi con la consapevolezza degli errori che possono essere ritentati e che non possono essere eseguiti. 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.
Configurazione
In questa sezione vengono elencate diverse impostazioni di configurazione rapide che è possibile usare per migliorare significativamente le prestazioni nel servizio tabelle:
Usa JSON
A partire dalla versione del servizio di archiviazione 2013-08-15, il servizio tabelle supporta l'uso di JSON al posto del formato AtomPub basato su XML per il trasferimento dei dati della tabella. L'uso di JSON consente di ridurre le dimensioni del payload di una percentuale massima del 75% e può migliorare notevolmente le prestazioni dell'applicazione.
Per altre informazioni, vedere il post Microsoft Azure Tables: Introducing JSON (Tabelle di Microsoft Azure: introduzione a JSON) e Payload Format for Table Service Operations (Formato di Payload per operazioni del servizio tabelle).
Disabilitare Nagle
L'algoritmo Nagle viene spesso implementato nelle reti TCP/IP come strumento per migliorare le prestazioni di rete. Tuttavia, non è ottimale in tutte le circostanze ,ad esempio ambienti altamente interattivi. L'algoritmo Nagle ha un impatto negativo sulle prestazioni delle richieste al servizio tabelle di Azure e, se possibile, dovrebbe essere disabilitato.
Schema
La modalità con cui vengono rappresentati i dati e vengono eseguite query su di essi è il fattore singolo più importante che influisce sulle prestazioni del servizio tabelle. Ogni applicazione è diversa, ma in questa sezione vengono descritte alcune procedure comprovate generali relative a:
- Progettazione della tabella
- Query efficaci
- Aggiornamenti dei dati efficaci
Tabelle e partizioni
Le tabella sono divise in partizioni. Ogni entità archiviata in una partizione condivide la stessa chiave di partizione e dispone di una chiave di riga univoca che la identifica all'interno della partizione. Le partizioni offrono dei vantaggi ma introducono anche dei limiti di scalabilità.
- Vantaggi: è possibile aggiornare le entità nella stessa partizione in una singola transazione batch atomica e batch contenente fino a 100 operazioni di archiviazione separate (limite di 4 MB di dimensioni totali). Presupponendo lo stesso numero di entità da recuperare, è anche possibile eseguire query sui dati all'interno di una singola partizione in modo più efficiente rispetto ai dati distribuiti in più partizioni (tuttavia, leggere più avanti per ulteriori consigli sulle query sui dati nelle tabelle).
- Limite di scalabilità: l'accesso alle entità archiviate in una singola partizione non può essere bilanciato perché le partizioni supportano transazioni batch atomiche. Per questo motivo, l'obiettivo di scalabilità per una singola partizione della tabella è inferiore rispetto a quello dell'intero servizio tabelle.
Tenendo conto delle caratteristiche descritte di tabelle e partizioni, adottare i seguenti principi di progettazione:
- Posizionare nella stessa partizione i dati aggiornati o su cui vengono eseguite query più di frequente da parte dell'applicazione client nella stessa unità logica di lavoro. Ad esempio, individuare i dati nella stessa partizione se l'applicazione sta aggregando le scritture o eseguendo operazioni batch atomiche. Inoltre, le query sui dati in una singola partizione possono essere eseguite in modo più efficace con un'unica query rispetto a quelle sui dati in più partizioni.
- Individuare i dati che l'applicazione client non inserisce, aggiorna o esegue query nella stessa unità logica di lavoro (ovvero in una singola query o in un aggiornamento batch) in partizioni separate. Tenere presente che non esiste alcun limite al numero di chiavi di partizione in una singola tabella, quindi la presenza di milioni di chiavi di partizione non è un problema e non influisce sulle prestazioni. Ad esempio, se l'applicazione è un sito Web diffuso con accesso utente, l'uso dell'ID utente come chiave di partizione potrebbe essere una scelta ottimale.
Partizioni critiche
Una partizione ad accesso frequente è una che riceve una percentuale sproporzionata del traffico verso un account e non può essere bilanciata dal carico perché si tratta di una singola partizione. In generale, le partizioni critiche vengono create in uno di questi due modi:
Modelli Solo accodamenti e Solo anteposizioni
In un modello "Solo accodamenti" tutto (o quasi tutto) il traffico verso una determinata chiave di partizione aumenta o diminuisce in base all'ora corrente. Un esempio è quello dell'applicazione che usa la data corrente come chiave di partizione per i dati di log. Questa progettazione comporta tutti gli inserimenti che passano all'ultima partizione nella tabella e il sistema non è in grado di bilanciare correttamente il carico. Se il volume di traffico verso tale partizione supera la destinazione di scalabilità a livello di partizione, comporta una limitazione. È opportuno assicurarsi che il traffico sia inviato a più partizioni per abilitare il bilanciamento del carico delle richieste nella tabella.
Dati con traffico elevato
Se lo schema di partizionamento genera una singola partizione che contiene solo dati molto più usati rispetto ad altre partizioni, è anche possibile che la limitazione venga visualizzata quando tale partizione si avvicina alla destinazione di scalabilità per una singola partizione. È opportuno verificare che lo schema di partizione non generi partizioni singole che raggiungono gli obiettivi di scalabilità.
Query
Questa sezione descrive le procedure comprovate per le eseguire query nel servizio tabelle.
Ambito delle query
Esistono diversi metodi per specificare l'intervallo di entità su cui eseguire query. L'elenco seguente descrive ciascuna opzione per ambito di query.
- Query di tipo punto: una query di tipo punto recupera una sola entità specificando sia la chiave di partizione che la chiave di riga dell'entità da recuperare. Queste query sono efficienti ed è consigliabile usarle quando possibile.
- Query di partizione: una query di partizione è una query che recupera un set di dati che condivide una chiave di partizione comune. In genere la query specifica un intervallo di valori della chiave di riga o un intervallo di valori relativi a una proprietà dell'entità, oltre alla chiave di partizione. Queste query sono meno efficaci delle query di tipo punto e devono essere usate in casi limitati.
- Query di tabella: una query di tabella è una query che recupera un set di entità che non condividono una chiave di partizione comune. Queste query non sono efficienti ed è consigliabile evitarle, se possibile.
Come regola generale, si consiglia di evitare le analisi (query più grandi di una singola entità), ma, se sono necessarie, provare a organizzare i dati in modo che le analisi recuperino i dati necessari senza analizzare o restituire grandi quantità di entità non necessarie.
Densità delle query
Un altro fattore importante in termini di efficacia delle query è il numero di entità restituite rispetto al numero di entità analizzate per trovare il set restituito. Se l'applicazione esegue una query di tabella con un filtro per un valore di proprietà che solo il 1% delle condivisioni dati, la query analizza 100 entità per ogni entità restituita. Gli obiettivi di scalabilità della tabella descritti in precedenza riguardano il numero di entità analizzate e non il numero di entità restituite: una bassa densità di query può causare facilmente la limitazione dell'applicazione da parte del servizio tabelle perché deve analizzare tante entità per recuperare l'entità che si sta cercando. Per altre informazioni su come evitare la limitazione, vedere la sezione intitolata Denormalizzazione.
Limitazione della quantità di dati restituiti
Quando si sa che una query restituisce entità non necessarie nell'applicazione client, è consigliabile usare un filtro per ridurre le dimensioni del set restituito. Anche se le entità non restituite al client continuano a contare sui limiti di scalabilità, le prestazioni dell'applicazione migliorano a causa delle dimensioni ridotte del payload di rete e del numero ridotto di entità che l'applicazione client deve elaborare. Tenere presente che gli obiettivi di scalabilità sono correlati al numero di entità analizzate, quindi una query che filtra molte entità potrebbe comunque comportare limitazioni, anche se vengono restituite poche entità. Per altre informazioni su come rendere efficienti le query, vedere la sezione intitolata Densità delle query.
Se l'applicazione client necessita solo di un set di proprietà limitato dall'entità nella tabella, è possibile usare la proiezione per limitare le dimensioni del set di dati restituito. Come nel caso dei filtri, la proiezione consente di ridurre il carico di rete e l'elaborazione del client.
Denormalizzazione
A differenza dell'uso dei database relazionali, le procedure comprovate per l'esecuzione di query efficaci sui dati della tabella portano alla denormalizzazione dei dati. Ovvero, duplicare gli stessi dati in più entità (una per ogni chiave che è possibile usare per trovare i dati) per ridurre al minimo il numero di entità che una query deve analizzare per trovare i dati necessari al client, invece di dover analizzare un numero elevato di entità per trovare i dati necessari per l'applicazione. Ad esempio, in un sito Web di e-commerce, potresti voler trovare un ordine in base all'ID cliente (dammi gli ordini del cliente) e alla data (dammi ordini in una data). In Table Archiviazione è consigliabile archiviare l'entità (o un riferimento) due volte, una volta con Nome tabella, PK e RK per facilitare la ricerca in base all'ID cliente, una volta per facilitarne la ricerca in base alla data.
Inserire, aggiornare ed eliminare
Questa sezione descrive le procedure comprovate per modificare le entità archiviate nel servizio tabelle.
Batch
Le transazioni batch sono note come transazioni dei gruppi di entità in Archiviazione di Azure. Tutte le operazioni all'interno di una transazione dei gruppi di entità devono essere su una singola partizione in una tabella singola. Dove possibile, usare le transazioni dei gruppi di entità per eseguire inserimenti, aggiornamenti ed eliminazioni in batch. L'uso delle transazioni dei gruppi di entità riduce il numero di round trip dall'applicazione client al server, si limita il numero di transazioni fatturabili (una transazione dei gruppi di entità conta come una singola transazione ai fini della fatturazione e può contenere fino a 100 operazioni di archiviazione) e si abilitano gli aggiornamenti atomici (l'esito positivo o negativo di un processo si applica a tutte le operazioni all'interno della transazione dei gruppi di entità). Gli ambienti con latenze elevate, ad esempio i dispositivi mobili, traggono vantaggio notevolmente dall'uso delle transazioni del gruppo di entità.
Upsert
Usare le operazioni della tabella Upsert quando possibile. Esistono due tipi di Upsert, entrambi più efficaci di una tradizionale operazione di inserimento e aggiornamento:
- InsertOrMerge: usare questa operazione quando si vuole caricare un subset delle proprietà dell'entità, ma non si è certi che l'entità esista già. Se l'entità esiste, questa chiamata aggiorna le proprietà incluse nell'operazione Upsert e lascia tutte le proprietà esistenti così come sono, se l'entità non esiste, inserisce la nuova entità. La procedura è analoga all'uso della proiezione in una query perché è necessario caricare solo le proprietà modificate.
- InsertOrReplace: usare questa operazione quando si vuole caricare un'entità completamente nuova, ma non si è certi che esista già. Usare questa operazione se si è certi che l'entità appena caricata è corretta perché questa sovrascrive completamente l'entità esistente. Ad esempio, si vuole aggiornare l'entità che archivia la posizione corrente di un utente indipendentemente dal fatto che l'applicazione abbia archiviato o meno i dati di posizione per l'utente; la nuova entità location è completa e non sono necessarie informazioni da alcuna entità precedente.
Archiviazione di serie di dati in una singola entità
A volte un'applicazione archivia una serie di dati richiesti di frequente per recuperarli tutti simultaneamente: ad esempio, un'applicazione può tenere traccia dell'utilizzo della CPU nel tempo per tracciare un grafico in sequenza dei dati relativo alle ultime 24 ore. Un approccio prevede un'entità di tabella all'ora, in cui ogni entità rappresenta un'ora specifica e archivia l'utilizzo della CPU per quell'ora. Per tracciare questi dati, l'applicazione deve recuperare le entità che comprendono i dati delle ultime 24 ore.
In alternativa, l'applicazione può archiviare l'utilizzo della CPU per ciascuna ora sotto forma di proprietà separata di una singola entità: per aggiornare le singole ore, l'applicazione può usare una singola chiamata InsertOrMerge Upsert per aggiornare il valore per l'ora più recente. Per tracciare i dati, l'applicazione deve recuperare solo una singola entità invece di 24, aumentando l'efficacia della query. Per altre informazioni sull'efficienza delle query, vedere la sezione ambito query.
Archiviazione di dati strutturati in BLOB
Se si eseguono inserimenti batch e quindi si recuperano insieme intervalli di entità, è consigliabile usare BLOB anziché tabelle. Per spiegarlo efficacemente, si prenda l'esempio di un file di log. È possibile creare in batch e inserire diversi minuti di log, e quindi recuperare diversi minuti di log alla volta. Per motivi di prestazioni, si consiglia in questo caso di usare i BLOB invece delle tabelle perché consentono di ridurre significativamente il numero di oggetti scritti o letti e potenzialmente anche il numero di richieste che occorre effettuare.
Passaggi successivi
Commenti e suggerimenti
Presto disponibile: Nel corso del 2024 verranno gradualmente disattivati i problemi di GitHub come meccanismo di feedback per il contenuto e ciò verrà sostituito con un nuovo sistema di feedback. Per altre informazioni, vedere https://aka.ms/ContentUserFeedback.
Invia e visualizza il feedback per