Menu

Big Data e NoSQL: il caso Azure

Big Data e NoSQL: il caso Azure

Questo post fa seguito al precedente, pubblicato su un blog Itware – sezione BigData e Analytics - intitolato “Riflessioni sui Big Data NoSQL” e indirizzato anche ai non addetti circa la natura delle basi di dati NoSQL. Là l’accento era su sistemi BigTable e HBase, qui si esamina l’analogo servizio NoSql della piattaforma Microsoft Azure...

Con Azure la sintassi è quella del linguaggio C#, a parere di chi scrive più facile da comprendere e, comunque, familiare a quanti hanno un minimo di familiarità col mondo .NET e... dintorni cloud.

Il Table Service

La piattaforma cloud Microsoft Azure privilegia questo servizio relativo a tabelle NoSQL, più idoneo a fare da base per applicazioni on-line.  Per la cronaca, al Table Service si accompagna un sistema relazionale, SQL di portata ridotta rispetto all’omologo offline.

L’impianto di Table Service è concettualmente simile a quello dei sistemi BigTable e HBase visti nel precedente post, ma la sintassi si presenta più semplice e, oltretutto, familiare ai programmatori in linguaggio C#. Il modello si esprime in una classe object-oriented. Qui accenno fugacemente che l’accesso si esplica tramite un’API REST basata su http, quindi salto diversi passaggi indicando un esempio tipico che definisce l’equivalente di una (tradizionale) entità Prodotto nel servizio Azure Table, con le sue brave proprietà, da quelle diciamo così, globali, ParetitionKey e RowKey, e quelle “normali”, Nome e Descrizione.

 

[DataServiceKey("PartitionKey", "RowKey")] 

public class Prodotto

{

public string Timestamp{ get; set; }

public string PartitionKey { get; set; }

public string RowKey { get; set; }

public string Nome { get; set; }

public string Descrizione { get; set; }

}

Quanto a Timestamp, mi limito a dire che, come già accennato nel post precedente, è una variabile creata automaticamente in base al tempo di creazione/modifica del Prodotto.

Ed ecco il codice per ottenere una nuova tabella Azure di oggetti Prodotto. Esso crea diverse istanze della classe Prodotto, incluse in un elenco (New List) di Prodotti:

var prodotti =

new List<Prodotto>

{

new Prodotto

{

PartitionKey = "Camicie",

RowKey= "1",

Name = "Camicia R",

Descrizione= "Camicia a righe"

},

new Prodotto

{

PartitionKey = "Camicie",

RowKey = "2",

Name = "Camicia B",

Descrizione = "Camicia bianca"

},

new Prodotto

{

PartitionKey = "Camicie",

RowKey = "3",

Name = "Hawai",

Descrizione = "Camicia a fiori hawaiana"

}

};

NOTA: Il precedente esempio, per semplicità e... pigrizia, è privo della proprietà Timestamp.

Con un non arduo sforzo di fantasia possiamo aggiungere un’ulteriore PartitionKey, diciamo Giacche composta da oggetti Prodotto di Nome a nostro piacimento.  Ne ometto i dettagli operativi, facilmente intuibili, penso.

A questo punto si potrebbe interpretare il risultato secondo lo schema C del predetto post. In alternativa, ho invece optato per una più “brutale” rappresentazione, che peraltro trae spunto e ispirazione nei manuali su Azure da me consultati (v. in fondo a questo articolino):

 

PartitionKey

RowKey

Nome

Descrizione

Camicie

1

Camicia R

Camicia a righe

Camicie

2

Camicia B

Camicia bianca

Camicie

3

Hawai

Camicia hawaiana

Camicie

4

Comune

Giacca normale

Camicie

5

Camicia R

Camicia a righe

Camicie

6

Camicia R

Camicia a righe

Giacche

7

Normale

Giacca tutti giorni

Giacche

8

Sportiva

Giacca sportiva

Giacche

9

Sera

Smoking

Giacche

10

Sera

Smoking

Giacche

11

Sportiva

Giacca sportiva

 

NOTA: qualcuno osserverà che così si perde la rappresentazione di mappe-di-mappe dei sistemi  BigTable e HTable. Oppure anche il NoSQL targato Azure la sottintende?

Mi astengo dal pronunciarmi su siffatte sottigliezze. Di fatto, da tale banale schema a mio avviso si possono trarre due considerazioni:

-  per un verso, la già ventilata possibilità di ricondurre agevolmente una tabella NoSQL ad una di tipo SQL classico;

- per contro, le molte ridondanze che affliggono il modello NoSQL; nel nostro esempio fa eccezione soltanto la RowKey, indispensabile per individuare in modo univoco una tabella.

Va Infine nuovamente sottolineato che il ruolo della PartitionKey è strettamente legato alla possibilità di distribuire una siffatta Table su una varietà di nodi sparpagliati sul web, nella fattispecie le Virtual Machine (VM) di Azure.

Mi fermo qui, suggerendo a chi è interessato a comprendere più da presso questi aspetti nonché a ulteriori approfondimenti sull’architettura del servizio NoSQL di Azure, i due testi qui sotto riportati.

Windows Azure
Programmare peril Cloud Computing
di Fabio Cozzolino
Ed.
FAG

Azure in action
di  Chris Hay,
Brian H. Prince
Ed. Manning Publications Co.
www.manning.com

Ultima modifica ilVenerdì, 10 Gennaio 2014 17:15

Aggiungi commento


Codice di sicurezza
Aggiorna

Torna in alto