Progettazione per la modifica dei dati

Questo articolo esamina le considerazioni relative alla progettazione per ottimizzare inserimenti, aggiornamenti ed eliminazioni. In alcuni casi, sarà necessario valutare il compromesso tra progettazioni che ottimizzano le query e progettazioni che ottimizzano la modifica dei dati, come avviene per le progettazioni per i database relazionali (anche se le tecniche per gestire i compromessi tra progettazioni sono diverse in un database relazionale). La sezione Modelli di progettazione tabella descrive in dettaglio alcuni schemi progettuali per il servizio tabelle ed evidenzia alcuni di questi compromessi. In pratica si vedrà che molte progettazioni ottimizzate per le query delle entità vanno bene anche per la modifica delle entità.

Ottimizzare le prestazioni delle operazioni di inserimento, aggiornamento ed eliminazione

Per aggiornare o eliminare un'entità, è necessario poterla identificare usando i valori PartitionKey e RowKey. In questo senso la scelta di PartitionKey e RowKey per modificare le entità deve seguire criteri simili a quelli usati per la scelta di supportare le query di tipo punto, perché l'obiettivo è identificare le entità nel modo più efficiente possibile. Si vuole evitare di usare una scansione di tabella o di partizione inefficiente per trovare un'entità e poter individuare i valori PartitionKey e RowKey necessari per aggiornarla o eliminarla.

I modelli seguenti nella sezione Modelli di progettazione tabella consentono di ottimizzare le prestazioni delle operazioni di inserimento, aggiornamento ed eliminazione:

• Modello di eliminazione volume elevato - Abilita l'eliminazione di un volume elevato di entità mediante l'archiviazione di tutte le entità per l'eliminazione simultanea nella relativa tabella separata. Per eliminare le entità, eliminare la tabella.
• Modello di serie di dati - Archivia serie di dati complete in un'unica entità per ridurre al minimo il numero di richieste effettuate.
• Modello di entità di grandi dimensioni - Usa più entità fisiche per archiviare entità logiche con più di 252 proprietà.
• Modello di entità di grandi dimensioni - Usa l'archiviazione BLOB per archiviare i valori di proprietà di grandi dimensioni.

Assicurare la coerenza nelle entità archiviate

L'altro aspetto importante che influisce sulla scelta delle chiavi per ottimizzare la modifica dei dati è come assicurare la coerenza usando le transazioni atomiche. È possibile usare una transazione EGT solo per agire sulle entità archiviate nella stessa partizione.

I modelli seguenti nell'articolo Modelli di progettazione tabella consentono la gestione della coerenza:

• Modello di indice secondario di partizione: archiviare più copie di ogni entità usando valori RowKey diversi (nella stessa partizione) per abilitare ricerche rapide ed efficienti e ordinare in modo alternativo usando valori RowKey diversi.
• Modello per indice secondario intrapartizione - Archivia più copie di ogni entità usando valori RowKey diversi in partizioni separate o in tabelle separate per consentire ricerche rapide ed efficienti e ordinamenti alternativi usando valori RowKey diversi.
• Modello per transazioni con coerenza finale - Abilita un comportamento di coerenza finale tra i limiti della partizione o i limiti del sistema di archiviazione usando le code di Azure.
• Modello di entità di indice : gestire le entità di indice per consentire ricerche efficienti che restituiscono elenchi di entità.
• Modello di denormalizzazione - Combina i dati correlati in una singola entità per consentire di recuperare tutti i dati necessari con un sola query di tipo punto.
• Modello di serie di dati - Archivia serie di dati complete in un'unica entità per ridurre al minimo il numero di richieste effettuate.

Per informazioni sulle transazioni del gruppo di entità, vedere la sezione Transazioni del gruppo di entità.

Verificare che la capacità della progettazione per modifiche efficienti consenta query efficienti

In molti casi, una progettazione per query efficienti consente modifiche efficienti, ma è consigliabile valutare sempre se questa condizione si applica a uno specifico scenario. Alcuni dei modelli nell'articolo Modelli di progettazione tabelle valutano in modo esplicito i compromessi tra la query e la modifica delle entità. Inoltre è sempre consigliabile tenere in considerazione il numero di ogni tipo di operazione.

I seguenti modelli nell'articolo Modelli di progettazione tabelle consentono di gestire i compromessi tra la progettazione per query efficienti e la progettazione per una modifica efficiente dei dati:

• Modello per chiave composta - Usa valori RowKey composti per consentire a un client di cercare dati correlati con una sola query di tipo punto.
• Modello della parte finale del log - Recupera le entità n aggiunte più di recente a una partizione in base a un valore RowKey che usa un ordinamento inverso di data e ora.