18

Mar

Windows Azure – Storage pt.4 – Tables

Le tabelle nell’Azure Storage si chiamano tali ma non sono gestite come tabelle relazionali. Per ovviare a questo possibile fraintendimento, diciamo subito che esse possono essere viste come una collezione di collezioni Nome-Valore. Mi spiego meglio: se volessi salvare su uno storage permanente una struttura dati che possa essere rappresentata come una tabella, ma che non abbia uno schema fisso di riferimento, come potrei fare?

La soluzione potrebbe essere quella di dire che, per ogni “tupla” inserita sotto questa forma:

Nome Cognome Età Indirizzo Altezza
Roberto Freato 26 Milano 188

venga inserito un oggetto nella collezione “Persone” (la nostra tabella virtuale), che potrebbe verosimilmente essere un Dictionary (le cui chiavi sono i nomi di colonna e i valori i dati). Ovviamente non succede esattamente questo, ma è logicamente una rappresentazione di quello che accade. Starà poi al motore di Windows Azure Storage, al momento di una ipotetica query, proiettare i dati disaggregati in modo che sembrino un dato strutturato, per poi eventualmente wrapparlo in una classe strong-typed nell’API .NET.

Detto questo, il resto è solo architettura, come nella figura sotto:

image

Tramite le API del NS Microsoft.WindowsAzure.StorageClient in connubio con il System.Data.Services.Client è possibile utilizzare l’Azure Storage come una sorgente dati ADO.NET DataServices e più in particoalre tramite oData, con le ovvie considerazioni del caso sulla portabilità della soluzione su molte piattaforme.

Una entità memorizzata in una tabella virtuale dello storage può avere fino a 255 proprietà, ma ne deve possere tre fondamentali (PartitionKey, RowKey, TimeStamp) che sono già presenti nella classe da cui generalmente si eredita (TableServiceEntity). La RowKey è quello che più si avvicina ad una chiave primaria: per cui se state migrando una soluzione dati esistente, vi converrà assegnare la primary key alla RowKey ed il gioco è fatto. Il TimeStamp è il tempo in cui il record viene creato/modificato e la PartitionKey merita invece un capitolo a parte.

PartitionKey

La figura sotto evidenzia come Windows Azure, in base a come si assegnerà la PartitionKey, cercherà di dividere i dati (partizionarli appunto) secondo una logica che non vada assolutamente a “spezzare” insiemi di tuple logicamente “contigue” (in termini di elaborazione, si intende). Perciò, operando su questa proprietà staremo dicendo ad Azure “tutti i record che hanno la stessa PartitionKey tienili nello stesso posto che molto probabilmente le ricerche saranno condotte al massimo su questo subset”.

image

Un esempio di come si scriva una Entity, un contesto Data Services e una query, è sotto:

image

image

image

by Roberto Freato on 3/18/2011
Post archive