Gianni Giaccaglini

Tricks & mini applics on WPF
posts - 46, comments - 0, trackbacks - 0

Big Data e NoSQL in Azure. Un’introduzione

 

Big Data e NoSQL in Azure. Un’introduzione

Confessiamolo. Chi, affrontando la prima volta il mondo di Microsoft Azure, non è rimasto sorpreso se non sgomento nel constatare che tale piattaforma supporta in modo limitato database Sql, privilegiando un misterioso sistema NoSQL? Il punto è che tale situazione fa a pugni con il paradigma relazionale con le sue regole di tabelle multiple correlate tra loro in modo razionale e, insiame, in grado di minimizzare le ridondanze. Di primo acchito il nuovo verbo NoSQL si presenta più rozzo.

Successivamente si è acceso il dibattito sui (cosiddetti) Big Data, le enormi basi di dati diffuse sul web. Da tali articoli (ai quali rimando) si apprende che, in realtà, il sistema relazionale, proprio per la sua pignoleria, mal si presta a gestire basi di dati  collocate su macchine virtuali e nodi “sparpagliati” worlwide” (e la ridondanza non conta più troppo, visto che oltretutto ragioni di sicurezza impongono repliche multiple).

Avendo digerito tali concetti, chi scrive è ritornato in Azure rivisitandone l’architettura NoSQL con maggior interesse. Questo post si rivolge a chi muove i primi passi in tale ambiente, nonché a coloro che, anche senza nutrire, al momento, velleità di sviluppo, desidera comunque farsene un’idea.

Il Table Service

Il Table Service, come il suo nome dichiara, è un servizio relativo a tabelle NoSQL, che la piattaforma cloud Microsoft Azure privilegia, in quanto più idoneo a fare da base per applicazioni on-line. Per la cronaca, come testé accennato, 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 per i quali rimando al seguente importante articolo chiarificatore:

http://jimbojw.com/wiki/index.php?title=Understanding_Hbase_and_BigTable

La questione concettuale spinosa è la famosa distinzione fra database row-oriented e database column-oriented. Gli esempi A e B seguenti li ho ripresi dalle prime pagine dell’articolo succitato. Ho osato interpretarli con dati tipici di una tabella anagrafica aggiungendo celle NUL, che l’articolo non prevedeva.

A) Tabella relazionale - database row-oriented

   

COD

Cognome

Prenome

Nome

DataNascita

Età

Salario

1

Rossi

Doria

Carlo

13/05/1980

33

1.200 €

2

Paoli

NUL

Mario

12/07/1975

38

1.500 €

3

Umberti

Zappa

Elena

NUL

NUL

500 €

4

Verdi

NUL

Luigi

05/02/2000

13

NUL

 

Invertendo righe e colonne si ottiene la situazione equivalente, conforme al nuovo paradigma NoSQL, intestazioni a parte (che non è chiaro dove vanno a finire).

B) Modello database column-oriented

1

2

3

4

Rossi

Paoli

Umberti

Verdi

Doria

NUL

Zappa

NUL

Carlo

Mario

Elena

Luigi

13/05/1980

12/07/1975

NUL

05/02/2000

33

38

NUL

13

1.200 €

1.500 €

500 €

NUL

 

L’articolo predetto esordisce ammettendo che i termini “base” e “table” possono creare l’idea errata che si tratti semplicemente di nuove edizioni di fonti relazionali (RDBMS). Il modello è, invece, radicalmente differente. E al centro dell’articolo viene ben specificato che la contrapposizione fra column-oriented e row-oriented è fuorviante, in quanto Hbase e BigTable sono caratterizzate da un insieme di mappe di dati a più livelli, ciascuna delle queli incorpora la mappa sottostante, in un sistema di scatole cinesi o, se si preferisce, di bambole matrioska.

Mi fermo qui. Passando al Table Service di Azure, la sintassi si presenta più semplice e, oltretutto, familiare a chi mastica linguaggio C# (mentre in Hbase e BigTable vige Java). Il modello di Azure si esprime in classi object-oriented. Qui accenno fugacemente che l’accesso si esplica tramite un’API REST basata su http, quindi salto a piè pari diversi passaggi, proponendo senz’altro 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, PartitionKey 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 ampiamente spiegato nel post su Hbase & BigTable,, è una variabile creata automaticamente in base al tempo di creazione/modifica del Prodotto . La qual cosa, come si intuisce, è particolarmente utile qualora si desideri monitorare l’evoluzione e il trend di certi dati per scopi di BI (Business Intelligence) o, come oggi si dice, di Data Analytics.

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 per interpretare il risultato graficamente ho optato per una “brutale” rappresentazione tabellare,  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

 

Qualcuno fra quanti avranno letto il post specifico citato sopra 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 queste sottigliezze. Di fatto, da tale banale schema a mio avviso si possono trarre due considerazioni:

·         per un verso, non è esclusa la possibilità di ricondurre, con qualche pena, una tabella NoSQL ad una di tipo SQL classico gestibile con tradizionali query in linguaggio SQL (per esempio IBM offre strumenti ad hoc);

·         per contro, il piccolo esempio mette in evidenza 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 sottolineato che il ruolo della PartitionKey è strettamente legato alla possibilità di distribuire una Table del genere su una varietà di macchine sparse sul web, nella fattispecie le Virtual Machine (VM) di Azure.

Concludendo

Questo post ha carattere introduttivo, pertanto non aggiungo altro, suggerendo piuttosto a tutti gl’interessati i due manuali qui sotto riportati, necessari per comprendere più da presso e approfondire le peculiarità dell’architettura del servizio NoSQL di Azure,.

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

Print | posted on mercoledì 19 febbraio 2014 17:02 |

Feedback

No comments posted yet.

Post Comment

Title  
Name  
Email
Url
Comment   
Please add 7 and 7 and type the answer here:

Powered by:
Powered By Subtext Powered By ASP.NET