Nello snippet precedente abbiamo iniziato ad utilizzare il Windows Azure Storage Account per memorizzare file all'interno dello storage destinato ai blob. In questo snippet iniziamo un ragionamento sulle tabelle esposte dal servizio Windows Azure Storage Account.
Se non l'abbiamo già fatto, anche in questo caso possiamo iniziare con l'ottenere una subscription dal portale di Windows Azure. Come abbiamo visto, possiamo accedere ad alcune subscription gratuite, utili a provare le nostre applicazioni sulla piattaforma senza pagare, a patto di non sforare i limiti indicati.
Figura 29. Ottenere la sottoscrizione gratuita
(clic per ingrandire)
La subscription Windows Azure Trial, ad esempio, fornisce gratuitamente 500 MB di spazio di storage e 10.000 transazioni in un mese.
Quindi salvare 500MB di tabelle (o blob o messaggi in coda) sullo Storage Account senza pagare un centesimo e testare la nostra applicazione effettuando 10.000 operazioni gratuite sullo storage al mese. Ogni operazione come creare una tabella, ottenere l'elenco delle entità memorizzate o cancellare una entità, rappresenta una transazione computata nel sistema di billing. Se restiamo al di sotto del numero di transazioni previste dalla subscription il nostro conto, a fine mese, sarà pari a 0 (zero) Euro.
Lo Storage Account, ovvero il servizio legato alla nostra subscription di gestione dello storage, è indipendente dal fatto che l'applicazione venga installata su Windows Azure: le richieste di accesso, infatti, si effettuano via REST/HTTP.
Come abbiamo visto, l'accesso allo Storage avviene sempre utilizzando HTTP (o HTTPS ovviamente), possiamo quindi considerarlo come un servizio di gestione dati via HTTP e accedervi con qualunque client HTTP.
Possiamo attivare il servizio in modo analogo a quanto descritto nella lezione precedente, ricordiamo che possiamo definire un gruppo di nodi affini, per migliorare le performance e che dobbiamo definire un nome univoco per non creare conflitti con i DNS. Scelto il nome e la regione (o l'affinity group) creiamo il nostro spazio di 100 TB dove memorizzare i file.
Creare una tabella
Per inserire entità applicative nello spazio destinato alle Table è sufficiente effettuare una richiesta REST/HTTP di tipo PUT verso l'indirizzo dello Storage Account. Prima di poter eseguire questa richiesta è necessario creare una tabella che contenga queste entità.
Le tabelle non hanno una struttura predefinita e consentono quindi la memorizzazione di entità diverse all'interno della stessa. Ogni tabella rappresenta semplicemente un contenitore di informazioni eterogenee dove memorizzare entità applicative. Ogni operazione sullo storage viene effettuata su 3 nodi fisici in modo da garantire ridondanza del dato.
È possibile creare diverse tabelle all'interno dello Storage Account per organizzare logicamente i dati.
Ogni tabella può anche essere suddivisa in partizioni, fornendo una PartitionKey nella richiesta di scrittura: le partizioni consentono al sistema di load balancing di dividere fisicamente una tabella su nodi diversi nel caso in cui il sistema vada sotto carico. In pratica ogni partizione può essere spostata da un nodo fisico all'altro, indipendentemente dalle altre partizioni della tabella e ovviamente anche dalle altre tabelle, su nodi diversi in base alle necessità. Tutto questo è completamente trasparente per l'applicazione che continuerà a utilizzare l'URI pubblico *.table.windows.net per l'accesso al servizio.
È importante sottolineare da subito che lo storage non è relazionale: ogni tabella vive di vita propria e non possono esistere constraint di integrità referenziale. È anche impossibile eseguire transazioni cross-table (anche cross-partition). Il mondo relazionale esiste su Windows Azure e come abbiamo avuto modo di accenare nel primo snippet, è rappresentato da SQL Azure.
Per evitare di scrivere il codice che lavora a livello REST/HTTP è disponibile una libreria per l'ambiente .NET, così come per Java o PHP, che incapsula i dettagli di "basso" livello fornendo metodi molto semplici come ad esempio CreateTableIfNotExist e fornendo un Data Context lato client su cui effettuare query LINQ e aggiornamenti successivi. La classe Data Context è derivata dalla ben più nota classe Data Context dei WCF Data Services, precedentemente conosciuti (dal SP1 di .NET 3.5, settembre 2008) come ADO.NET Data Services.
Come abbiamo visto per i blob, la libreria .NET utilizza la classe CloudStorageAccount che, leggendo il file di configurazione (ServiceConfiguration.cscfg in una applicazione Windows Azure, o i classici .config di .NET per applicazioni on-premises), si preoccupa di tutti i dettagli di comunicazione verso gli URL utilizzando le chiavi di accesso.
Anche in questo caso, per accedere rapidamente alle nostre tabelle e vederle in azione, ci serviremo del
Windows Azure Management Tool. Ci connettiamo allo Storage Account come abbiamo fatto nella scorsa lezione e esploriamo l'albero dello Storage Explorer per lavorare nello spazio a disposizione.
È possibile connettere lo strumento anche al Storage Emulator locale utilizzando le stesse funzionalità dello Storage Account su Windows Azure. Accedendo alla sezione Table, come si nota dalla figura seguente, è possibile visualizzare l'elenco delle tabelle nella parte alta del pane centrale e, nella parte inferiore gestire i dati delle varie tabelle.
Figura 30. L'elenco della tabelle
(clic per ingrandire)
Contrariamente a quanto si può fare sul servizio di gestione dei blob, non è possibile creare una tabella da questo strumento, in quanto, come abbiamo accennato in precedenza, la tabella non ha una struttura predefinita. Per poter salvare dati nella tabella occorre eseguire una richiesta PUT all'URI del servizio oppure utilizzare il Data Context lato client (che a sua volta esegue la richiesta PUT dietro le quinte).
Nel prossimo snippet vedremo come creare il codice per definire le entità e come inserire e recuperare entità da una Table.
