Scuola Politecnica e delle Scienze di Base
Corso di Laurea in Ingegneria Informatica
Elaborato finale in Basi di Dati
NoSQL database: la soluzione Oracle.
Anno Accademico 2013/2014
Candidato:
Alfonso Di Martino
matr. N46000185
Alla mia famiglia, che mi ha dato i
mezzi, la fiducia e il sostegno per
raggiungere questo traguardo.
A Te, che mi hai cambiato la vita.
Indice
NoSQL database: la soluzione Oracle...................................................................................................I
Indice .............................................................................................................................................III
Introduzione......................................................................................................................................4
Capitolo 1: Dal modello relazionale a NoSQL.................................................................................7
1.1 Il modello relazionale.............................................................................................................7
1.1.1 Il concetto di scalabilità : verticale e orizzontale.................................... ................ 8
1.2 Il Teorema CAP e le proprietà BASE dei NoSQL.................................................................9
1.3 Il nuovo trend : NoSQL........................................................................................................11
1.3.1 Big Users ............................................................................................... .............. 12
1.3.2 Big Data.................................................................................................. .............. 13
1.4 Tassonomia dei sistemi NoSQL...........................................................................................15
1.4.1 Key-value...............................................................................................
1.4.2. Column family........................................................................................
1.4.3 Documents-oriented...............................................................................
1.4.4 Graph.....................................................................................................
.............. 15
.............. 16
.............. 17
.............. 17
Capitolo 2 : Oracle NoSQL Database............................................................................................19
2.1 Introduzione .........................................................................................................................19
2.2 L'architettura di Oracle NoSQL Database............................................................................20
2.2.1 Il lato Server........................................................................................... .............. 21
2.2.2 Il lato Client............................................................................................. .............. 22
2.2.3 Esempio di inserimento di un record...................................................... .............. 24
2.3 Oracle NoSQL Data Model.................................................................................................25
2.3.1 Chiavi e Valori........................................................................................ .............. 25
2.3.2 Politiche di Consistenza......................................................................... .............. 26
2.3.3 Politiche di Durabilità.............................................................................. .............. 27
2.4 API, CRUD e Iteratori..........................................................................................................27
2.5 Oracle NoSQL Database nella “soluzione Oracle” per Big Data........................................29
Conclusioni.....................................................................................................................................31
Bibliografia.....................................................................................................................................32
Introduzione
La crescita esplosiva nell'utilizzo di internet, il boom globale dei social media, come
Facebook (che conta da solo oltre 1 miliardo di iscritti), lo sviluppo e utilizzo sempre più
massiccio di applicazioni mobile e servizi di cloud computing, hanno portato alla luce la
necessità di avere nuovi strumenti e tecnologie per il mantenimento e l'analisi (spesso in
tempo reale) di un volume di dati costantemente in crescita, fortemente variabile e in
costante mutamento, indicati come Big Data.
Prendiamo come esempio i social, come Facebook e Twitter, con i loro like, condivisioni,
twett e retwett, producono dati che possono essere analizzati per estrarre informazioni sui
comportamenti sociali, singoli e collettivi, sulle tendenze musicali, politiche o di mercato.
Un altro esempio significativo è dato dai sempre più utilizzati servizi di cloud computing,
che permettono a un numero molto grande e variabile di utenti di archiviare qualsiasi tipo
di risorsa in rete e accedervi in ogni momento da un qualsiasi dispositivo, oppure usare
programmi che non sono istallati direttamente sui propri dispositivi, ma direttamente
online (es. Google Drive) o semplicemente utilizzare un servizio on-demand per accedere
a risorse messe a disposizione, gestendo in modo efficace e dinamico l'affluenza.
L'afflusso continuo di informazioni, eterogenee e continuamente volubili, la necessità di
analizzare in tempo reale grandi quantità di dati e la necessità di scalare, dinamicamente e
soprattutto in orizzontale piuttosto che in verticale, ha portato i tradizionali database
relazionali a non essere più l'unico modello da prendere in considerazione, in quanto
pongono forti limiti sulla scalabilità orizzontale e sulla efficiente gestione di gigantesche
banche di dati contenti informazioni non strutturate.
Da qui l'esigenza di avere un modello dei dati più flessibile, che possa evolvere e
arricchirsi in base alle esigenze e ai nuovi tipi di dati, che sia ottimizzato per essere
4
distribuito e fornire alte prestazioni per elaborazioni su volumi di dati molto grandi e
richieste di servizi da parte di un gran numero di utenti.
Queste sono le motivazioni che hanno portato alla nascita di nuovi modelli di dati, che si
sono allontanati dal classico modello relazionale, ossia si sono “evoluti” adattandosi alle
esigenze del nuovo web, che vanno sotto il nome di NoSQL.
Il termine NoSQL fu utilizzato per la prima volta da Carlo Strozzi nel 1998 per indicare un
suo pacchetto software ben definito, basato sul modello relazionale e che non utilizzasse il
linguaggio SQL per la formulazione di query. Lui stesso differenzia il suo termine NoSQL
da quello che oggi è un movimento che non utilizza SQL poiché il modello di base non è
relazionale, preferendo indicare tali modelli più propriamente come “NOREL” [1].
Lo stesso termine fu poi riutilizzato nel 2009 da Eric Evans, dipendente di Rackspace,
durante un evento organizzato per discutere di database distribuiti open source, usato per
etichettare quelle basi di dati spesso non relazionali e distribuite [2].
La mia breve introduzione a quella che è la tematica del mio elaborato, ossia analizzare e
inquadrare in un certo modo quello che è il concetto di “database NoSQL”, andando poi a
dare ampio spazio, nella seconda parte della trattazione, a quella che è la soluzione offerta
da Oracle, sicuramente non è ancora esaustiva di tutte quelle che sono le problematiche
legate ai database relazionali in relazione a quelli che sono i nuovi obbiettivi nello studio
delle informazioni provenienti dal web, che hanno poi portato alla ricerca di nuove strade
e in particolare al movimento NoSQL.
Però possiamo già inquadrare alcuni elementi fondamentali come:
grandezza del dataset dell'ordine dei petabyte e exabyte o oltre;
grande varietà di dati su cui lavorare, non sempre completi;
necessità di avere una distribuzione delle informazioni su più nodi;
5
6
Capitolo 1: Dal modello relazionale a NoSQL.
1.1 Il modello relazionale
Il modello relazionale fu introdotto nel 1970 da Ted Codd del Centro ricerche IBM in un
suo celebre articolo, Codd 1970. Il modello venne subito apprezzato per la sua semplicità
e le sue basi matematiche: esso usa il concetto di relazione matematica come componente
elementare e ha il suo fondamento teorico nella teoria degli insiemi e nella logica dei
predicati del primo ordine [3].
Nel modello relazionale il database risulta essere una collezione di relazioni, rappresentate
visivamente come tabelle, ogni riga è detta tupla e l'intestazione di ogni colonna attributo,
avente un valore appartenente a un dominio definito per il tipo di attributo.
Nell'ambito dei sistemi relazionali, assume una fondamentale importanza il concetto di
transazione, e affinché sia garantita l'integrità della base di dati, sono state definite e
devono essere rispettate dalle transazioni, le cosiddette proprietà ACID:
A (atomicità) : tutte le operazioni di una transazione devono essere considerate
come una sola operazione elementare, quindi o vengono eseguite tutte o nessuna.
C (consistenza) : ogni transazione deve agire sulla base di dati in modo corretto,
lasciando la stessa nello stesso stato iniziale consistente.
I (isolamento) : una transazione deve essere eseguita in modo indipendente rispetto
a eventuali altre esecuzioni di transazioni concorrenti.
D (durabilità) : una volta che la transazione si è conclusa con successo, il risultato
di tale transazione deve essere permanente sulla base di dati.
7
Figura 1.1 - Il modello relazionale
I valori contenuti nella tabella assumono significato di informazione quando sono associati
all'attributo definito come intestazione della colonna.
Caratteristica del modello relazionale è la frammentazione delle informazioni in più
tabelle, anche se queste si riferiscono al medesimo oggetto. Questo si traduce in una
necessità di aggregare le informazioni di diverse tabelle per soddisfare le query, attraverso
operazioni tipicamente definite di JOIN, che sfruttano le cosiddette chiavi esterne o
foreign keys che mettono in relazione tabelle differenti.
Capiamo subito che questa necessità di “aggregare” si traduce in un problema alquanto
rilevante quando ho a che fare con tabelle che crescono sempre più: per questo è
fortemente sconsigliato avere tabelle molto grandi, perché ci sarebbero problemi di
gestione anche con sistemi computazionali molto potenti.
1.1.1 Il concetto di scalabilità : verticale e orizzontale
La scalabilità è una caratteristica di un sistema che ne indica la capacità di crescere o
decrescere in risposta all'aumento o decremento del carico di lavoro in modo adeguato.
Possiamo avere due tipologie :
•
Scalabilità verticale, dove si effettua un upgrade delle risorse hardware, per
esempio del server , ossia lo si potenzia in termini di CPU, memorie ecc.
8
•
Scalabilità orizzontale, dove invece che potenziare l'hardware, se ne aggiunge di
nuovo, ossia si aggiungono nuovi nodi.
Figura 1.2 - Scalabilità Verticale vs Scalabilità Orizzontale
La scalabilità verticale è quella su cui i database relazionali si sono sempre basati,
arrivando ad avere server così potenti da poter gestire da soli migliaia di utenti
contemporaneamente. Tutto questo ha però un limite, altamente superato nel momento in
cui internet è diventato un fenomeno globale, portando così alla luce la necessità di avere
un sistema distribuito che permettesse la parallelizzazione delle operazioni e un
bilanciamento del carico di lavoro, in modo tale da avere performance molto alte anche
con picchi di affluenza molto alti.
Da qui l'esigenza di scalare in orizzontale piuttosto che in verticale, ma questo modo di
fare è in conflitto con alcune restrizioni dovute alle ACID, in quanto ci sarebbero problemi
legati alla consistenza dei dati.
1.2 Il Teorema CAP e le proprietà BASE dei NoSQL
Il teorema CAP fu presentato da Eric Brewer nel 2000 durante l'evento “Principles of
Distributed Computing“ , il quale afferma che per un sistema informatico distribuito non
possono valere contemporaneamente le proprietà di:
•
Consistency (Coerenza) : dopo una modifica dei dati, la propagazione degli stessi
permetterà nella prossima operazione di lavorare su dati aggiornati, ossia tutti i
9
nodi vedono sempre gli stessi dati;
•
Availability (Disponibilità) : il sistema è sempre pronto a rispondere a qualsiasi
richiesta;
•
Partition Tolerance (Tolleranza al partizionamento) : il sistema continua a
lavorare anche se alcuni nodi non sono più raggiungibili.
Figura 1.3 - CAP Theorem
Nel caso dei tradizionale RDBMS, si rinuncia alla Partition Tolerance a favore di
Coerenza e Disponibilità, da qui l'esigenza di forzare in un unico nodo tutti i dati richiesti
per una transazione, a discapito della scalabilità.
Per quanto riguarda le proprietà BASE, queste sono necessarie poiché forniscono una
versione “rilassata” delle ACID, nel caso in cui si favorisca la replicazione dei dai per
aumentare la scalabilità orizzontale e la disponibilità dei dati, il tutto a discapito della
consistenza.
BASE = Basically Available , Soft state , Eventual consistency.
•
Basically Available : nei sistemi NoSQL si predilige la disponibilità del dato e
questo si ottiene andando a replicare il dato stesso su un gran numero di nodi;
10
•
Soft state : al contrario della Consistenza delle ACID, lo stato del sistema può
variare nel tempo.
•
Eventually consistency : non si danno garanzie sul quando i dati raggiungeranno
uno stato consistente; questo perché il sistema deve essere sempre pronto a
rispondere e le modifiche si propagano in maniera asincrona tra i nodi.
1.3 Il nuovo trend : NoSQL
Con il termine NoSQL (Not Only SQL) indichiamo un movimento che si discosta dal
tradizionale concetto di database relazionale (o RDBMS) per i quali la memorizzazione
dei dati è legata alla definizione di un modello tabellare rigido e l'interrogazione è
effettuata utilizzando il linguaggio SQL.
Lo sviluppo dei sistemi NoSQL si basa su queste quattro caratteristiche [4]:
•
open-source : caratteristica che è alla base del movimento, volta a promuovere
l'utilizzo e lo sviluppo delle tecnologie NoSQL;
•
non-relational : non abbiamo la definizione di uno schema fisso come nel caso dei
sistemi relazionali. Infatti molte volte si parla di schemaless;
•
distributed : la capacità di distribuire e replicare su molti nodi i dati, aumentando
la possibilità di avere sempre disponibili i dati e aumentare la fault tolerance;
•
horizontally scalable : nativamente pensati per scalare orizzontalmente,
condizione richiesta per casi d'uso che coinvolgono Big Users e Cloud Computing.
Nel corso della trattazione ci siamo già più volte avvicinati a quelle che sono le
problematiche che hanno portato colossi di internet come Google, Amazon, Facebook , ad
abbandonare il classico modello relazionale e ad investire nella ricerca e sviluppo dei
NoSQL, utilizzati per un numero crescente di casi d'uso, scelta dovuta a quattro nuovi
megatrend tra loro correlati : Big User, Big Data, The Internet of Things, Cloud
Computing [5].
11
1.3.1 Big Users
Nel recente passato, 1.000 utenti che utilizzassero giornalmente un applicazione era già un
numero molto alto e arrivare a 10.000 era un caso veramente eccezionale. Oggi i numeri
sono veramente cresciuti: si parla di 3 miliardi di persone che si collegano a internet,
spendendo oltre 35 miliardi di ore al mese online (dati del 2014). Però non sono questi i
numeri che preoccupano gli sviluppatori: è molto più importante e critica la gestione e di
migliaia di utenti simultanei e l'imprevedibile aumento o calo, in modo molto rapido, di
affluenza.
Figura 1.4 - I numeri dei "Big User"
Le ragioni di questo fluttuare dell'affluenza possono essere delle più disparate:
•
una nuova app, che diventa subito popolare e acquista in pochissimo tempo
milioni di utenti;
•
in periodi che precedono le festività, come Natale, Pasqua o San Valentino si
registrano picchi enormi di visite agli e-commerce;
•
utenti che usano spesso un'applicazione, come un social, altri che ne fanno un uso
più raro o unico.
Con i modelli relazionali è veramente difficile progettare e ottenere una scalabilità così
elevata e fortemente dinamica, mantenendo alto il grado di performance: ci si rivolge ai
NoSQL, che sono progettati per essere distribuiti e scale out.
Infatti si utilizzano un gruppo di server, fisici o virtuali, per memorizzare dati e operazioni
di supporto, e per scalare si aggiunge al cluster un nuovo server, capace di soddisfare una
12
richiesta di ben 10.000 utenti.
Tale approccio risulta essere anche più economico rispetto allo scaling up (più diventa
complesso il server, più è costoso), che avrà comunque un limite oltre il quale il server
relazionale dovrà scalare in due o più server, introducendo una enorme complessità per lo
sviluppo dell'applicazione e database dovuto alle limitazioni intrinseche dei sistemi
relazionali.
Inoltre, lo scaling offerto dai sistemi NoSQL è invisibile all'applicazione, che continua a
vedere un singolo database (distribuito).
1.3.2 Big Data
I Big Data sono diventati un punto cruciale per lo sviluppo e la fortuna di molte aziende,
che hanno e stanno investendo molto nelle tecnologie capaci di analizzare questi dati al
fine di ricavare modelli sui quali fare importanti scelte di business.
Il termine Big Data si riferisce spesso a queste tipologie di dati [6]:
•
Dati Enterprise : informazioni sui clienti da sistemi CRM, dati transazionali ERP,
transazioni via web, dati di contabilità generale;
•
Dati generati da sensori o macchine : CDR (Call Detail Record), weblogs, sensori,
telecamere o rilevatori meteorologici, GPS, ecc;
•
Dati sociali : flussi di feedback di clienti, tutto ciò che è prodotto dai social e così
via.
Quello che sicuramente salta agli occhi è la dimensione enorme di tutti questi dati, ma
questa non è l'unica caratteristica dei Big Data. Infatti si parla di Big Data se valgono le
“3V” [7], ossia:
•
Varietà : non stiamo trattando solo informazioni tradizionali, ma anche e
soprattutto dati semi-strutturati o non strutturati, in formato testuale, audio, video,
streaming, provenienti da sensori, social network o blog, e tanto altro ancora.
•
Volume : parliamo di informazioni con un volume in continuo aumento, dai
terabyte ai petabyte fino ai zetabyte (ossia un miliardo di TB).
13
Figura 1.5 – Big Data: le 3 V .
•
Velocità : riferita ai tempi di gestione e analisi, che devono essere sempre più
rapidi, evitando così che i dati diventino obsoleti.
La definizione di Big Data è stata poi arricchita con i concetti supplementari di Veridicità
e Valore, la prima riferita alla correttezza e affidabilità dei dati, la seconda riferita alla
capacità dei dati reperiti di portare un reale beneficio nel processo di analisi.
Gli sviluppatori trovano sempre più interesse nello sfruttare questi dati per arricchire le
loro applicazioni o svilupparne di nuove.
Il problema sta nell'acquisizione e utilizzo dei big data, che richiede un database di tipo
differente, una soluzione altamente flessibile che si adatti facilmente all'arrivo di nuovi tipi
di dati e che non risenta di cambiamenti apportati alla struttura dei contenuti forniti da
terze parti.
La gran parte dei dati sono non strutturati o semi-strutturati e quindi c'è bisogno di
database che li memorizzino in modo efficiente. L'approccio basato su uno scema
rigidamente definito, quello relazionale per intenderci, rende impossibile l'integrazione
14
rapida di nuovi tipi di dati e non è molto efficiente per dati non/semi – strutturati.
Un altro problema è legato al “disadattamento di impedenza” tra l'approccio OO per lo
sviluppo dell'applicazione e la struttura schematica del modello relazionale.
I database NoSQL forniscono soluzioni a questi problemi, perché forniscono un modello
dati più flessibile, schemaless, che organizza meglio i dati di un applicazione e semplifica
la sua interazione con il database.
1.4 Tassonomia dei sistemi NoSQL
Una problematica legata ai sistemi NoSQL è dovuta al fatto che non esiste ancora uno
standard, come per il modello relazionale, in quanto abbiamo diverse soluzioni che usano
protocolli proprietari, rendendo quindi difficile l'eventuale passaggio da un database
all'altro.
Però possiamo
comunque
isolare
caratteristiche
relative
al
tipo
di
memorizzazione, che permettono una loro classificazione. Possiamo riconoscere quattro
macro-categorie: key-value, column family, documents-oriented e graph.
1.4.1 Key-value
Memorizza coppie chiave-valore e la base di dati è vista come una grossa hash table.
La chiave molto probabilmente sarà una stringa multipart, composta per esempio da una
chiave maggiore e una minore, come nel caso di Oracle NoSQL Database, ed è utilizzata
per accedere al dato.
Il valore può essere di qualsiasi tipo, sia
semplice come una stringa o int, oppure
complesso, come un intero oggetto o una
serializzazione di dati di una sessione
web.
Sono utilizzati quando si predilige la
Figura 1.6 - Key-Value stores
15
velocità di accesso al dato, quindi valorizza le operazioni CRUD – create, read, update,
delete – e quando non c'è correlazione tra i dati da memorizzare.
Alcuni esempi sono: Oracle NoSQL Database, DynamoDB, MemcachedDB e Redis.
1.4.2. Column family
Memorizza i dati in righe e colonne, con la particolarità che sono memorizzati per colonna
e non per riga come negli RDBMS.
Le colonne non sono definite a priori e possono essere diverse per ogni riga, aggiunte o
rimosse dinamicamente.
Figura 1.7 - Standard Column Family Storem & Super Column Family Store
Questi tipi di database sfruttano spesso un indicizzazione su due o più livelli: questo
favorisce la velocità di accesso alle informazioni che ci interessano di un determinato
oggetto, favorisce l'aggregazione di dati simili nel tipo e li rende più facilmente
comprimibili, favorisce la distribuzione, anche ordinata, su un numero elevato di nodi e di
un numero elevatissimo di dati.
Infatti si parla di mappa ordinata, multi-dimensionale, persistente, indicizzata per row key,
column key e timestamp (permette il versioning dei dati).
Sono molto utilizzati nel campo dei Big Data in quanto forniscono un modello organizzato
e flessibile.
Alcuni esempi sono: Cassandra, Hypertable, Hbase.
16
1.4.3 Documents-oriented
Sono molto simili ai Key-Value, con la differenza che il valore è sempre un documento,
spesso in formato BSON o JSON.
I documenti JSON (Javascript Object Notation) permettono di avere una memorizzazione
“schemaless” dei dati, da intendere come flessibilità della struttura e non come totale
assenza di organizzazione, che c'è ed è di tipo gerarchico.
Figura 1.8 – Dalle tabelle al documento.
Adatti in situazioni dove la struttura dei dati può variare frequentemente o posso avere dati
incompleti.
Alcuni esempi sono: MongoDB, CouchDB, Couchbase Server.
1.4.4 Graph
Memorizza strutture a grafo costituite da nodi e archi, dove ogni nodo può essere, per
esempio, un oggetto e l'arco tra due nodi rappresenta la relazione tra di essi.
Questa soluzione predilige le relazioni
tra entità piuttosto che le entità stesse,
infatti
è
particolarmente
indicato
quando ho a che fare con dati
fortemente connessi e voglio avere
una
struttura
performante
conoscere le relazioni tra i dati.
Figura 1.8 - Graph Stores.
17
per
Nodi e archi possono memorizzare coppie chiave-valore e gli algoritmi realizzati per lo
scorrimento del grafo rendono la soluzione altamente performante.
Rappresenta la struttura ideale per la gestione di alcuni aspetti tipici dei social, dove ho
relazioni del tipo “amico di” , “piace a” , “amici in comune” e così via.
Alcuni esempi sono : Neo4J, OrientDB, Infinite Graph.
18
Capitolo 2 : Oracle NoSQL Database
2.1 Introduzione
Il grande affermarsi delle tecnologie NoSQL per affrontare problematiche come Big Data,
Big User e Internet of Things, ha portato anche Oracle, leader nel settore della gestione e
memorizzazione dei dati con il suo Oracle Server o Oracle Database (che è un RDBMS), a
sviluppare e realizzare una piattaforma NoSQL.
Parliamo di Oracle NoSQL Database, piattaforma rilasciata nel 2011, in due versioni,
COMMUNITY e ENTERPRISE.
Oracle NoSQL Database (ONDB) è un database key-value distribuito, progettato per
essere altamente disponibile ed estremamente scalabile, con livelli prevedibili di
throughput e latenza, richiedendo minima interazione amministrativa [8].
Come per gli altri modelli NoSQL ci si focalizza sulla scalabilità orizzontale e semplici
funzioni per la gestione dei dati.
A differenza degli altri, invece, abbiamo [9]:
•
un prodotto maturo, collaudato sul campo e di qualità. ONDB si basa sul motore di
archiviazione e tecnologia di replica di Berkeley DB Java Edition, il quale vanta
oltre un decennio di applicazione per casi d'uso mission-critical in aziende come
Amazon o LinkedIn;
•
è l'unico NoSQL sviluppato e supportato da un'azienda leader nella fornitura di
database;
•
una strumento capace di integrarsi con gli altri prodotti Oracle, come Oracle
Database che è uno dei più famosi e utilizzati RDBMS;
•
fornisce
caratteristiche
uniche
come
transazioni
bilanciamento dinamico per l'archiviazione sui nodi.
19
ACID
configurabili
e
Le transazioni ACID permettono uno sviluppo più semplice delle applicazioni, il
bilanciamento dinamico si traduce in distribuzione robusta, coerente e scalabile per
la base di dati;
•
ONDB permette un throughput elevato, ma soprattutto garantisce un throughput e
una latenza prevedibile, grazie a politiche di sgombero cache e raccolta parametri
“spazzatura” Java, altamente ottimizzate e automatiche. Altri sistemi hanno in
questo punto notevoli limitazioni, ossia quando si parla di prevedibilità e gestione
delle prestazioni, soprattutto quando si tratta di ripulire il sistema, compattare e
raccolta dei rifiuti Java;
•
semplicità di implementazione e gestione del database;
•
la piattaforma è stata fortemente testata, eseguendo test di benchmark
standardizzati, con carichi di lavoro e configurazioni hardware differenti.
2.2 L'architettura di Oracle NoSQL Database
La piattaforma Oracle NoSQL Database si forma su due parti principali: Server e Client
[10],[11].
Figura 2.1 - Architettura Client - Server di ONDM
Dalla figura si può notare che il client (libreria Java o C) è integrato nell'applicazione e le
fornisce le chiamate API. Il server è distribuito su più nodi di storage logici, ognuno
associato a un centro di stoccaggio dei dati in una macchina fisica o virtuale.
20
2.2.1 Il lato Server.
Il server è distribuito in più nodi di storage o archiviazione. Uno Storage Node (SN) è
tipicamente una macchina fisica, con una propria memoria persistente, CPU, memoria
centrale e indirizzo IP.
Figura 2.2 - Struttura lato server : Nodi Storage e Nodi Replica.
Ciascun nodo archiviazione serve uno o più nodi replica, appartenenti a un gruppo di
replica, tutti contenenti gli stessi dati. Per ogni gruppo di replica viene designato un nodo
master che gestisce tutte le operazioni di modifica dei dati (create, update, delete) mentre
gli altri nodi replica effettuano solo operazioni di lettura.
Nel caso in cui il master fallisce, viene eletto a master un altro nodo appartenente allo
stesso gruppo di replica, tramite protocollo Paxos.
In figura 2.2 abbiamo una struttura con 30 gruppi di replica (0-29), ognuno con fattore di
replica (RF) pari a 3, ossia un gruppo di replica con 3 nodi (un master e due repliche) e si
sviluppa su due data center; RF=3 garantisce il funzionamento in lettura anche nel caso di
guasto di due nodi simultaneamente. Ovviamente tale parametro RF può variare a seconda
21
del grado di robustezza e affidabilità che vogliamo dare all'applicazione.
Analizzando sempre la struttura di figura 2.2 , si può notare che sono stati assegnati al data
center più grande due nodi replica, mentre al più piccolo uno solo (vale per ogni gruppo di
replica). Questo tipo di configurazione ci può far pensare al fatto che l'applicazione utilizzi
sempre i dati del data center maggiore, attingendo dal data center minore solo in caso di
guasto del maggiore.
I 30 gruppi di replica sono memorizzati su 30 nodi di storage distribuiti sui due data
center.
I nodi replica supportano le Oracle NoSQL Database API chiamate dai client, ottenendo
dati o scrivendo i dati direttamente dal sistema di storage log-structured, che fornisce
performance di scrittura eccezionale pur mantenendo bassa latenza in lettura grazie
all'indicizzazione.
Oracle NoSQL Database utilizza le repliche per garantire alta disponibilità dei dati, anche
in caso di guasti simultanei di nodi repliche.
Aumentare il fattore di replica permette soprattutto di diminuire la latenza in lettura,
aumentare in numero di nodi di storage permette un throughput e una capacità di
immagazzinamento maggiori per il sistema.
2.2.2 Il lato Client.
Il client o Client Driver è un file Java che esporta l' API per le applicazioni. Esso mantiene
anche una copia della “topologia” e la Replication Group State Table (RGST) ossia una
tabella di stato del gruppo di replica.
La topologia mappa efficientemente le chiavi per le partizioni e dalle partizioni dei gruppi
di replica. Per ogni gruppo replica, include il nome host del nodo di archiviazione che
ospita ogni nodo di replica del gruppo, il nome del servizio associato con i nodi di replica
e il data center in cui ogni nodi risiede. La topologia viene caricata durante
l'inizializzazione del client o del nodo di replica e può essere successivamente aggiornata
22
dall'amministratore nel caso di cambiamenti.
La RGST è utilizzata del client prevalentemente per due scopi:
•
identificare il nodo master del
gruppo di replica, in modo da
poter
inviare
richieste
di
scrittura al master;
•
bilanciamento del carico di
Figura 2.3 - Replication Group State Table.
lettura su tutti i nodi replica del
gruppo;
Dal momento che la RGST è una struttura dati critica condivisa, ogni client e nodo replica
ne mantiene una propria copia, evitando un singolo punto di fallimento. Entrambi
effettuano una RequestDispatcher che utilizza la RGST per inviare richieste di scrittura al
master e richieste di lettura allo specifico nodo dello specifico gruppo di replica.
La RGST è dinamica e ha bisogno di manutenzione continua. Ogni nodo replica esegue un
thread, chiamato Replication Node State Update thread, per la manutenzione della propria
RGST.
Il thread di aggiornamento, così come la RequestDispatcher, raccolgono informazioni sui
nodi di replica remoti, compreso lo stato attuale del nodo nel suo gruppo di replica, il
tempo dell'ultima interazione con successo avvenuta con il nodo, il tempo medio di
risposta e la lunghezza attuale della coda di richieste. Inoltre l' Update thread mantiene le
connessioni di rete e ristabilisce quelle interrotte.
Tutta la manutenzione è fatta al di fuori del ciclo di richieste/risposta del
RequestDispacher per minimizzare l'impatto delle connessioni interrotte sulla latenza.
23
2.2.3 Esempio di inserimento di un record.
Per capire in che modo interagiscono Applicazione, Client Driver e Server distribuito,
possiamo esaminare il caso di inserimento di una coppia chiave-valore “Katana-sword”.
(1) L'applicazione invoca il metodo putIfAbsent(“Katana”,”sword”) per effettuare una
richiesta di scrittura al database.
(2) Il Client Driver applica una
funzione
hash
alla
chiave
Katana per calcolare il valore
dell' ID di una partizione che
sarà
selezionata
tra
quelle
prefissate.
(3)
Il Client Driver consulta la
Partition Table per associare
all'
ID
gruppo
della
partizione
di
il
replica
corrispondente.
Figura 2.4 – Inserimento di “Katana-sword”
(4) Selezionato il gruppo di replica si accede alla sua RGST.
(5) Per ogni gruppo di replica, la RGST contiene le informazioni dei nodi replica ad esso
appartenenti, come il Tipo (master o replica) , il Tempo di risposta e l' Host.
(6) A seconda del tipo di operazione (lettura/scrittura) e delle informazioni contenute nella
RGST che identificano il tipo di nodo e il carico di lavoro, si seleziona il nodo al quale
inviare la richiesta. Nel nostro caso verrà selezionato il nodo master e a lui sarà inoltrata la
richiesta di scrittura.
(7) Il nodo selezionato esegue l'operazione. Nel caso della scrittura, il nodo master effettuerà la
memorizzazione della coppia chiave-valore se e solo se la chiave non esiste ancora e la
propagazione avverrà appena possibile. Nel caso in cui la chiave è già presente, l'operazione
non viene conclusa e ritorna un errore.
24
2.3 Oracle NoSQL Data Model.
Nella sua forma più semplice, ONDB implementa una mappa di chiavi definite dall'utente
(generalmente stringhe) a elementi di dati opachi. Per ogni coppia chiave-valore viene
registrata la versione, anche se viene mantenuta nello store solo l'ultima versione.
ONDB utilizza il meccanismo single-master replication : il nodo master ha sempre la
versione più aggiornata per i dati relativi a una singola chiave, mentre in sola lettura, le
repliche potrebbero fornire versioni meno aggiornate. L'applicazione può comunque
utilizzare il numero di versione per garantire la consistenza delle operazioni di scritturalettura-modifica.
2.3.1 Chiavi e Valori.
Come già anticipato, ONDB è una piattaforma key-value store, che memorizza quindi
coppie chiave-valore.
La chiave è una stringa multipart, costruita come concatenazione di una Major Key Path e
una Minor Key Path, specificate a livello applicativo. Tutti i record che si riferiscono alla
stessa Major Key Path sono memorizzati nello stesso nodo e l'indicizzazione è effettuata
applicando una funzione hash all'intera chiave. L' hashing della chiave permette un ottima
distribuzione delle stesse chiavi sui nodi e allo stesso tempo una ricerca molto veloce.
Se come esempio prendiamo un'applicazione che memorizza profili utente, come Major
Key Path posso prendere il nome-profilo e come Minor Key Path gli altri componenti di
tale profilo, come indirizzo, numero di telefono o mail.
Essendo l'applicazione a gestire la composizione e interpretazione delle chiavi, diverse
Major Key Path possono avere strutture Minor Key Path completamente differenti.
Ritornando all'esempio di prima, si potrebbero archiviare nello stesso store sia il profilo
utente che applicativo, mantenendo per ognuno un diverso Minor Key Path.
Il valore può essere qualsiasi cosa, un tipo base come int e string, o molto più complesso.
ONDB supporta la serializzazione Avro che ci da un formato dati binario estremamente
25
compatto e utilizzando JSON permette di definire uno schema per il contenuto del valore
del record, che può anche evolvere.
2.3.2 Politiche di Consistenza.
In generale quando parliamo di NoSQL, parliamo di eventuale consistenza, come definito
nelle proprietà BASE. Non è il caso di ONDB, che invece fornisce diversi livelli di
consistenza a seconda di quanto richiesto dall'applicazione.
Figura 2.5 – Politiche di Consistenza.
In figura possiamo notare:
•
none consistency : per applicazioni che possono lavorare anche su dati incoerenti si
offre bassa consistenza, così si restituiscono valori più efficientemente ma non
sempre aggiornati.
•
time-based consistency / version-based consistency : nel primo caso la consistenza
è riferita rispetto a un certo tempo, nel secondo rispetto a una certa versione del
dato stesso.
•
absolute consistency : per applicazioni che hanno bisogno di lavorare con il valore
più recente associato a una data chiave.
Avere una flessibilità di questo tipo permette agli sviluppatori di dare il necessario grado
di garanzia ai dati avendo comunque ottimi parametri di latenza e scalabilità.
26
2.3.3 Politiche di Durabilità.
ONDB fornisce anche una gamma di politiche di durabilità, che danno garanzie sullo stato
del sistema dopo un fallimento improvviso.
Da un lato abbiamo il caso in cui l'applicazione blocca le richieste di scrittura fino a
quando non saranno aggiornate tutte le repliche, dall'altro lato si permette di servire una
nuova richiesta di scrittura non appena quella corrente viene registrata, anche se non è
ancora stata propagata sulle repliche.
Naturalmente nel primo caso avrò dati scritti sempre correttamente, sempre persistenti e
recuperabili anche nel caso di fallimenti multipli, il tutto a discapito della disponibilità e
delle prestazioni.
Nel secondo caso
avrò altissime prestazioni in scrittura senza però garanzie sulla
durabilità, in quanto se ho un fallimento sul master prima che questo propaghi le
modifiche sulle repliche, il nuovo master, che verrà eletto, non è detto che sia a
conoscenza della modifica e quindi ho avuto perdita di informazioni. .
Tra i due estremi abbiamo poi una notevole gamma di soluzioni, regolate specificando
quando la scrittura deve essere fatta su disco e il numero di repliche che devono essere
coinvolte (nessuna, tutte, un certo numero).
2.4 API, CRUD e Iteratori.
ONDB fornisce delle semplici API in linguaggio C o Java per le operazioni base di Create,
Read, Update, Delete (CRUD) , che permettono un'integrazione della piattaforma
all'interno dell'applicazione molto semplice. Le librerie includono anche il supporto Avro
per la serializzazione e de-serializzazione dei record chiave-valore.
Per la creazione e aggiornamento sono forniti diversi metodi put : putIfAbsent implementa
la creazione (se la chiave è assente) e putIfPresent che invece implementa
l'aggiornamento. Il solo metodo put implementerà la creazione se la chiave non è presente,
altrimenti l'aggiornamento.
L'operazione di aggiornamento andrà a memorizzare una nuova “versione” della coppia
27
chiave-valore : l' API fornisce il metodo putIfVersion che permette alle applicazioni di
implementare consistenza semantica in lettura-modifica-scrittura.
Per la cancellazione si utilizza il metodo delete o la sua versione condizionata
deleteIfVersion , che cancellano una coppia chiave-valore dal database (nel secondo caso
una certa versione specificata).
Per recuperate record dal database si utilizza il metodo get.
Figura 2.6 - Codice di semplici operazioni CRUD.
Sono supportati anche due tipi di iterazione: iterazione non-ordinata su record e iterazione
ordinata all'interno della stessa Major Key Path.
Nel caso di iterazione non-ordinata sull'intero store, il risultato è non transazionale poiché
si opera a livello read-committed, ossia nel risultato avrò solo coppie chiave-valore scritte
persistentemente nel database, ma non ci sono garanzie sulla consistenza semantica di tutte
le coppie.
L'API supporta sia il ritorno singolo di coppie chiave-valore, utilizzando diversi metodi
“storeIterator”, sia il ritorno di un insieme di coppie-chiave valore all'interno di Major Key
Path usando vari metodi “multiGetIterator”.
28
2.5 Oracle NoSQL Database nella “soluzione Oracle” per Big Data.
Oracle Corporation definisce il suo Oracle NoSQL Database come un database che non è
general-purpose, bensì è stato sviluppato per affrontare uno specifico set di problemi di
gestione dati e per integrarsi in modo semplice con gli altri prodotti Oracle [11].
Questo permette di inserire ONDB all'interno di qualsiasi soluzione di classe enterprise
per la gestione dei dati.
Figura 2.7 - Ecosistema della gestione dati.
La figura mostra proprio come ONDB si integra con il resto dell'intero ecosistema di
gestione dei dati, rendendo disponibile agli sviluppatori e ai clienti i proprio punti di forza,
al minimo costo in termini di integrazione manuale, poiché la soluzione è stata sviluppata
già da Oracle.
La soluzione offerta da Oracle fa si che il database relazionale (Oracle Database) e non
(Oracle NoSQL Database) si “completino a vicenda” : da un lato abbiamo dati e
applicazioni che si basano sul database relazionale e che hanno magari bisogno di
meccanismi di query complesse, dall'altro abbiamo la necessità di gestire grandi volumi di
dati semplici, strutturati e semi/non strutturati.
Oracle fornisce meccanismi che permettono di spostare dati da Oracle NoSQL DB a
29
Oracle DB per essere analizzati, o viceversa per consentire lo sviluppo di applicazioni
web-based e che sfruttano grandi volumi di dati in modo estremamente veloce [9].
La tecnologia NoSQL è tipicamente accostata ai Big Data, soprattutto nell'acquisizione.
Oracle Corporation fornisce un intero sistema ingegnerizzato, hardware e software, per
acquisire, organizzare e analizzare i Big Data; stiamo
parlando di Oracle Big Data
Appliance.
Figura 2.8 - Acquisizione, organizzazione e analisi dei Big Data.
Nell'intero processo, Oracle NoSQL DB si occupa di acquisire i dati semplici provenienti
dalla rete globale, archiviando le coppie chiave-valore distribuite nei suoi nodi di storage.
Su questi dati su possono effettuare analisi statistiche semplici utilizzando direttamente
processi di Hadoop MapReduce che potrebbero essere utili all'applicazione.
Nel caso in cui si vogliono effettuare operazioni di analisi più complesse, si spostano i dati
in un data warehouse Oracle e si sfrutta un set più ricco di processi e funzionalità.
Lo spostamento dei dati da Oracle NoSQL DB verso il data warehouse può avvenire
usando Oracle Data Integrator o usando funzioni SQL di MapReduce che permetto a
Oracle DB di estrarre dati direttamente da una sorgente esterna [12] .
30
Conclusioni
In questo elaborato è stata fatta una panoramica sui database NoSQL e sulla soluzione
offerta da Oracle Corporation in tale ambito con Oracle NoSQL Database.
I database NoSQL sono stati presentati andando a valutare alcuni casi d'uso che rendono le
soluzioni sviluppate sul modello relazionale generalmente non performanti, come
l'acquisizione e organizzazione dei Big Data o la gestione dei Big Users.
Nel caso dei Big Data, le limitazioni del modello relazionale sono molteplici, dalla
definizione tabellare rigida per i dati, che rende impossibile una veloce integrazione di
nuovi attributi, non è adatta a memorizzare dati semi/non strutturati magari incompleti e
comunque sconsigliata nel caso di strutture che diventano molto grandi, alla necessità di
effettuare JOIN per risolvere query che interessano attributi sparsi su più tabelle a causa
della normalizzazione.
Nel caso dei Big Users si è sottolineata la necessità di avere una soluzione che sia
altamente scalabile, orizzontalmente piuttosto che verticalmente, così da adattarsi in modo
rapido e dinamico alle improvvise variazioni di richieste.
Nel proporre le soluzioni fornite dai database NoSQL si è data anche una classificazione
in quattro categorie, sottolineando per ognuna i punti di forza e i più noti prodotti
software.
Nella seconda parte ci si è soffermati sulla soluzione di Oracle Corporation per database
NoSQL, analizzandone l'architettura, il modello dei dati, le API fornite e le
personalizzazioni possibili nell'abito della consistenza e durabilità.
Nell'ultimo paragrafo è stata fatta una panoramica dei possibili utilizzi di Oracle NoSQL
DB all'interno di un più complesso sistema di gestione dei dati, accennando ai meccanismi
e strumenti che lo compongono e alla soluzione di classe enterprise per l'acquisizione e
organizzazione dei Big Data fornita da Oracle Big Data Appliance.
31
Bibliografia
[1]
http://www.strozzi.it/cgi-bin/CSA/tw7/I/en_US/NoSQL/
[2]
http://www.rackspace.com/blog/nosql-ecosystem/
[3]
R. A. Elmasri , S. B. Navathe, Sistemi di basi di dati, 4a edizione, Pearson, 2004,pg. 131.
[4]
http://nosql-databases.org/
[5]
Why NoSQL? , Couchbase, http://www.couchbase.com/nosql-resources/what-is-no-sql
[6]
Oracle: Big Data for Enterprise, Oracle White Paper, Ottobre 2011
[7]
Big Data : Riconoscerli, gestirli, analizzarli.
[8]
http://www.oracle.com/technetwork/database/database-
http://www.ecos2k.it/allegati/BigData.pdf
technologies/nosqldb/learnmore/nosql-database-data-sheet-498054.pdf
[9]
Oracle White Paper— NoSQL and SQL Introspective: Oracle NoSQL Database 11g Release 2
[10] Oracle NoSQL DB Basic structure and working mechanism by Chao Huang, Sr. Manager, Oracle
[11] Oracle White Paper - Oracle NoSQL Database , Settembre 2011
[12] Intervista Oracle – Big Data Management, Marzo 2012
32
