Menu

Riflessioni sui Big Data NoSQL: molto più che semplici matrici trasposte...

Riflessioni sui Big Data NoSQL: molto più che semplici matrici trasposte...

Queste noterelle mirano a dare un’idea anche ai non addetti circa la natura delle basi di dati NoSQL. Il fatto è che il materiale sul tema è straripante ma in compenso abbonda pure la confusione, terminologica e concettuale.

Cominciamo da una premessa tanto ovvia quanto indispensabile: quando si parla di "NoSQL", ormai in modo pressoché universale, non si intende più voler dire “Not SQL” ma “Not Only SQL”, con alcune nuove estensioni dello stesso linguaggio SQL che lo portano a superare le sue tradizionali capacità di elaborare unicamente dati disposti in righe e colonne. Su questa faccenda tenterò di pronunciarmi, ahimè senza pretesa di approfondire, al termine di questo intervento.

Tabelle disposte per righe o colonne?

La questione dalla quale desidero partire riguarda la distinzione fra Database row-oriented e Database column-oriented. Gli esempi A e B seguenti li ho ripresi dalle prime pagine di un articolo su NoSQL. Li ho interpretati 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

Tutto qui? Ma santo cielo!, una matrice diretta o inversa che sia resta una matrice.Dov’è la novità?

Per comprendere la faccenda meglio che si può suggerisco invece il link seguente, che punta a un articolo intitolato “Understanding HBase and BigTable” dedicato alle più comuni implementazioni di Big Data di tipo NoSQL.

Il testo 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 rappresentazione Column-oriented vs. Row-oriented è fuorviante, in quanto – sottolineo fin d’ora – 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.

Sintesi dell’articolo

Riporto quasi pari pari i brani seguenti che a loro volta cita le definizioni, simili ma non proprio limpidissime, di Bigtable e HBase: "A Bigtable is a sparse, distributed, persistent multidimensional sorted map. The map is indexed by a row key, column key, and a timestamp; each value in the map is an uninterpreted array of bytes.

Hbase: Users store data rows in labelled tables. A data row has a sortable key and an arbitrary number of columns. The table is stored sparsely, so that rows in the same table can have crazily varying columns, if the user likes."

La seconda definizione, comunque, allude al fatto che il modello NoSQL è studiato in modo da poter sparpagliare i dati su nodi multipli mantenendone la consistenza, superando difficoltà insormontabili del modello RDMS, con la sua marea di tabelline correlate.

Seguono alcune definizioni basilari che qui di seguito riporto sinteticamente.

Map: "An abstract data type composed of a collection of keys and a collection of values, where each key is associated with one value." In notazione JavaScript Object una semplice mappa di soli chiavi/valori è la seguente:

{

"zzzzz": "woot",

"xyz" : "hello",

"aaaab" : "world",

"1" : "x",

"aaaaa" : "y"

}

Salto a piè pari le proprietà persistent, distributed (accennata dianzi e che in particolare si riferisce al sistema Hadoop’s Distributed File System (HDFS), soffermandomi sulla feature Sorted, la cui importanza nei sistemi distribuiti è ben illustrata nell’articolo, di cui riporto l’esempio precedente, impostato correttamente secondo il criterio delle chiavi rigorosamente ordinate:

{

"1": "x",

"aaaaa" : "y"

"aaaab" : "world",

"xyz" : "hello",

"zzzzz": "woot"

}

Il punto crociale: multidimensionalità

In pratica un oggetto BigTable o Hbase si presenta il più delle volte come una mappa di mappe. L’autore prosegue per gradi, ma per draconiana amore di sintesi riporto subito un caso intermedio tipico:

{

// ...

"aaaaa" : {

"A": {

"foo": "y",

"bar": "d"

},

"B": {

"": "w"

}

},

"aaaab": {

"A": {

"foo": "world",

"bar": "domination"

},

"B": {

"": "ocean"

}

},

// ...

}

Anche chi non mastica JavaScript può, con un po’ di pazienza ossia esaminando i contenuti racchiusi fra ciascuna graffa aperta { e chiusa } – che siamo in presenza di mappe a tre livelli: la più esterna comprende le chiavi di riga ordinate e racchiude le mappe di chiave A e B, che a loro volta comprendono i contenuti del tipo“foo”:”World”, “bar”:”domination”, in A, “”:”ocean”. Queste ultime sono le famose colonne di numero variabile, al punto che qualcuna può anche mancare. Per l’esattezza con le colonne non si parla di chiave ma di qualificatore o label. Per quanto ne ho capito questa sottile distinzione è legata a un’importante

REGOLA: Le chiavi di riga e quelle, direi, di gruppo, non possono mancare.

Occorre poi sottolineare che le mappe opzionali (ma, credo, il più delle volte “moralmente” raccomandabili) a livello sovrastante inquadrano le colonne secondo famiglie.In tal modo si coniuga versatilità dei contenuti e un sostanziale rigore, oso dire, strutturale delle basi dati NoSql.

A questo punto ho pensato di ricorrere anziché ai troppo generici dati dell’articolo a quelli più “umani” dell’originaria tabella relazionale A e raffigurarla visivamente (su un foglio Excel, per la cronaca) anziché con la sintassi informatica, interpretandola letteralmente alla luce del codice JSON appena visto:

C) database column-oriented con famiglie di colonne

TabNoSQLRow

Il lettore paziente (tale per antonomasia) noterà anzitutto la scomparsa dell’intestazione COD, che ho arruolato come chiave di riga, la quale in quanto tale è, per così dire, anonima. Per quanto riguarda la ridondanza di intestazioni voglio sperare che, dato che l’articolo in questione si occupa solo di creazione di database, di fatto una struttura-canovaccio “una tantum” sia presente (e distribuita, si capisce).

Pertanto ipotizzo che lo schema precedente si possa in qualche maniera ricondurre grossomodo a quanto segue:

 

Nominativo

Dati anagrafici

Salario

1

Cognome

Prenome

Nome

DataNascita

Età

1.200 €

 

Rossi

Doria

Carlo

13/05/1980

33

 

2

Cognome

Nome

 

DataNascita

Età

1.500 €

 

Paoli

Mario

 

12/07/1975

38

 

3

Cognome

Prenome

Nome

 

Età

500 €

 

Umberti

Zappa

Elena

 

13

 

4

Cognome

Nome

 

DataNascita

 

 

 

Verdi

Luigi

 

05/02/2000

 

 

per cui, su basi del genere, si possa fondare una lingua SQL applicabile a dati NoSQL, come nel linguaggio Big SQL di IBM (http://www.ibm.com/developerworks/library/bd-bigsql/bd-bigsql-pdf.pdf) che consente di manipolare in lingua SQL sia dati SQL classici che NoSQL.

Sia come sia, non va poi dimenticato che i formati BigTable e HBase permettono un’importante marcia in più, ben descritta nell’articolo citato. In due parole essa consente di assegnare a certi dati delle marche (numeriche) progressive affibbiate a valori suscettibili di cambiare nel tempo.

Ultime considerazioni

Da questa chiacchierata emerge che i Big Data in forma NoSQL non si preoccupano di eliminare doppioni con tabelline specifiche richiamate da un codice. Per cui, ad esempio, il codice e il nome di una provincia compaiono reiteratamente. In compenso si possono creare oggetti quasi onnicomprensivi su un certo argomento, il che non è solo necessario per la diffusione “sparsa” ma si traduce in una maggior semplicità della gestione (superato lo choc connesso a ogni novità). Oso inoltre sostenere che anche la BI se ne avvantaggi. Infatti con il modello relazionale nello sviluppare l’analisi multidimensionale risulta caotico incrociare dati, a causa della gran quantità di tabelle che lo contraddistingue, mentre col NoSQL è più agevole ottenere wharehouse con un numero essenziale di tabelle.

Commenti?

Ultima modifica ilLunedì, 23 Dicembre 2013 18:51

Aggiungi commento


Codice di sicurezza
Aggiorna

Torna in alto