Linee guida per la progettazione di tabelle
La progettazione di tabelle per l'uso con il servizio tabelle di archiviazione di Azure è molto diversa dalle considerazioni di progettazione per un database relazionale. Questo articolo descrive le linee guida per la progettazione di una soluzione di servizio tabelle in grado di supportare in modo efficiente le operazioni di lettura e scrittura.
Progettare una soluzione di servizio tabelle efficiente per le operazioni di lettura
- Progettazione per l'esecuzione di query in applicazioni di lettura elevata. Quando si progettano le tabelle, considerare le query (soprattutto quelle sensibili alla latenza) eseguite prima di pensare a come aggiornare le entità. Ciò comporta in genere una soluzione efficiente e ad alte prestazioni.
- Specificare PartitionKey e RowKey nelle query.Le query punto, ad esempio queste sono le query del servizio tabelle più efficienti.
- È consigliabile archiviare copie duplicate di entità. L'archiviazione tabelle è conveniente, quindi è consigliabile archiviare più volte la stessa entità (con chiavi diverse) per consentire query più efficienti.
- Valutare la denormalizzazione dei dati. L'archiviazione tabelle è conveniente, quindi è consigliabile denormalizzare i dati. Ad esempio, archiviare le entità di riepilogo in modo che le query per aggregare i dati debbano accedere a una singola entità.
- Usare valori chiave composta. Le uniche chiavi disponibili sono PartitionKey e RowKey. Ad esempio, per abilitare percorsi alternativi per l'accesso con chiave alle entità, ad esempio, utilizzare valori chiave composti.
- Usare la proiezione di query. È possibile ridurre la quantità di dati trasferiti attraverso la rete usando query che selezionano solo i campi necessari.
Progettare una soluzione di servizio tabelle efficiente per le operazioni di scrittura
- Non creare partizioni ad accesso frequente. Scegliere le chiavi che consentono di distribuire le richieste in più partizioni in qualsiasi momento.
- Evitare picchi nel traffico. Regolare il traffico in un periodo di tempo ragionevole ed evitare picchi nel traffico.
- Non creare necessariamente una tabella separata per ogni tipo di entità. Quando sono necessarie transazioni atomiche tra tipi di entità, è possibile archiviare questi più tipi di entità nella stessa partizione nella stessa tabella.
- Prendere in considerazione la velocità effettiva massima che è necessario ottenere. È necessario tenere presente le destinazioni di scalabilità per il servizio tabelle e assicurarsi che la progettazione non li superi.
Questa guida contiene esempi in cui vengono messi in pratica tutti questi principi.