20

Jun

Windows Azure – Strategie di Storage pt.4 – Avanzate e versioni di storage

Utilizziamo un esempio del training kit per spiegare meglio un contesto in cui è più comodo, meno costoso e più performante utilizzare lo storage REST (in particolare l’Azure Table Storage) per implementare una applicazione Twitter-oriented.

Supponiamo di voler salvare i dati relativi al mondo Twitter; in standard SQL partiremo così:

image

Potremo poi normalizzare un pò, come sotto, ma nonostante tutto avremmo uno storage che per una grande mole di utenza, avrebbe una singola tabella richiesta migliaia di volte al secondo.

image

Perchè non utilizzare il table storage partizionando i dati per utente di riferimento?

image

Scenari di upgrade

Con Azure Table Storage non c’è schema fisso per i dati, non c’è un database relazionale a cui vincolarsi e il dato, seppur apparentemente strutturato, segue uno schema fluido che può variare nel tempo. Si può pensare meglio alle tables come una serie di coppie Nome/Valore per ogni record inserito o da inserire.

Per questo motivo, versioni “differenti” di storage (con campi aggiunti) non creano problemi alla logica applicativa. Infatti una procedura che cercherà di leggere un subset dei dati totali, non avrà nessun problema a farlo. La procedura “versione 2” che invece vorrà usare un set più esteso di dati, potrà continuare a lavorare autonomamente come in figura:

image

Comunque rimane buona norma segnalare la versione di un record, in modo da permettere in un qualsiasi momento l’aggiornamento dei dati di una versione alla versione successiva, completando i dati mancanti.

by Roberto Freato on 6/20/2011
Post archive