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......15 1.4.2. Column family......16 1.4.3 Documents-oriented......17 1.4.4 Graph......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 15 Figura 1.6 - Key-Value stores
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 per conoscere le relazioni tra i dati. Figura 1.8 - Graph Stores. 17
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 ACID configurabili e bilanciamento dinamico per l'archiviazione sui nodi. 19
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 lettura su tutti i nodi replica del Figura 2.3 - Replication Group State Table. 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 della partizione il gruppo di 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. http://www.ecos2k.it/allegati/bigdata.pdf [8] http://www.oracle.com/technetwork/database/databasetechnologies/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