Scuola Politecnica e delle Scienze di Base Corso di Laurea in Ingegneria Informatica Elaborato finale in Basi di Dati Tecnologie NoSQL: HBase Anno Accademico 2014/2015 Candidato: Daniela Bianco matr. N46001409
Ai miei genitori, per esser stati un assiduo sostegno durante questo percorso. Alla mia dolce metà, per aver camminato al mio fianco.
Indice Indice. III Introduzione.4 Capitolo 1: Sistemi NoSQL...6 1.1Vantaggi e svantaggi.......7 1.2 Confronto con i RDBMS...7 1.3 Base Teorema CAP...9 1.4 Classificazione dei database NoSQL...11 Capitolo 2 : Big Data.14 2.1 Caratteristiche....15 2.2 Gestione dei Big Data..16 2.2.1 Limiti dei RDBMS e nuovi approcci per l elaborazione dei Big Data......16 Capitolo 3: HBase...18 3.1 Modello dei dati...19 3.2 Architettura.. 20 3.3 Caratteristiche..20 3.4 HBASE VS RDBMS...21 3.5 HBASE VS HDFS...21 3.6 Sperimentazione..22 Conclusione...29 Bibliografia....30 Ringraziamenti......31
Introduzione La tesi ha lo scopo di analizzare il mondo dei database non relazionali, che rappresentano un quadro completamente diverso di database, infatti riescono a garantire alte prestazioni ed elaborazioni agili di informazioni su scala massiccia. In altre parole, se in passato non esisteva un modo conveniente per memorizzare e analizzare moli di dati, oggi con questa infrastruttura di database NoSQL si riesce a gestire pesanti richieste di grandi dati. Di fatto è stata la soluzione per gestire alcuni dei più grandi data warehause come Google, Amazon, Facebook, Twitter e tanti altri. Nel primo capitolo verranno discusse le principali caratteristiche dei database NoSQL, i quali saranno poi messi a confronto con i database relazionali. Verrà esposto il teorema CAP e infine verranno introdotte le categorie di database non relazionali. Il secondo capitolo sarà dedicato al concetto di Big Data, descrivendone le caratteristiche e la loro gestione. Infatti l utilizzo di questi Big Data ha permesso di ottenere la massimizzazione e la concretezza del valore delle informazioni, portando molte aziende a sviluppare le loro architetture di gestione dei dati in un sistema di gestione dei Big Data. Quest ultimo si è adeguato a tutte le tipologie di dati provenienti da varie fonti come Hadoop, dati relazionali e NoSQL, assicurando un buon livello di sicurezza e controllo per le informazioni sensibili o regolamentate. In azienda, con i Big Data si assiste ad un cambiamento dei modelli di produzione delle informazioni, ciò ha contribuito a nuove forme di conoscenza aziendale più ampia e profonda degli oggetti (clienti, prodotti, concorrenti, canali, ect.) e degli eventi (ordini, pagamenti, traporti, etc.) di business. 4
Infine nel terzo capitolo verrà preso come caso di studio il database NoSQL HBASE. E un database adatto a molti casi di utilizzo, alcuni tra quali sono: la gestione dei sistemi di messaggistica, come Facebook; l acquisizione di dati raccolti in modo incrementale da varie origini; l esecuzione di query in tempo reale; e l uso di HBase come piattaforma per le applicazioni. Di HBase si focalizzerà l attenzione sul modello dei dati, sull architettura, sulle caratteristiche e come ultimo step verrà illustrato il linguaggio di interrogazione di questo database sia attraverso un interazione con la shell di HBase e sia con l interfaccia web. 5
Capitolo 1: Sistemi NoSQL La rapida evoluzione tecnologica, unita all insoddisfazione del mondo web, dovuta alla rigidità del modello relazionale e all esigenza di grande scalabilità orizzontale, hanno fatto emergere nuove esigenze applicative. Infatti negli ultimi anni sono stati progettati nuovi sistemi, che hanno cercato di aggirare il rigido modello relazionale, aumentando il livello delle prestazioni nella gestione e interrogazione dei dati. Questi sistemi sono stati inglobati sotto il termine NoSQL. Cosa si intende per NoSQL? Il termine NoSQL fu adoperato per la prima volta nel 1998 per una base di dati relazionale open source 1 che non utilizzava un'interfaccia SQL. La parola NoSQL potrebbe far pensare che è un movimento contrario all'utilizzo di database 2 relazionali, ma in realtà il suo acronimo è Not Only SQL che sta a rivelare la presenza di diversi casi d'uso per i quali il modello relazionale rappresenta un esagerazione, ma per tanti altri tale modello è ancora un ottima soluzione. Allora sorge una domanda: perché cercare altri DBMS se esistono quelli relazionali che svolgono bene il loro lavoro? I database NoSQL non solo sono open source, ma sono semplici da adoperare, infatti 1 Open source: la natura open source del database NoSQL significa che è possibile occuparsi di applicazioni di grandi dimensioni con enormi quantità di dati a un prezzo più basso. 2 Database: i database o banche dati sono archivi di dati, in cui le informazione in essi sono ben strutturate in modo da permettere una veloce ricerca al loro interno. Essi consentono la gestione dei dati in termini di inserimento, aggiornamento, ricerca e cancellazione delle informazioni. 6
hanno un paradigma di programmazione ad oggetti, i dati sono riutilizzabili su sistemi diversi e memorizzati nei database NoSQL senza alcun vincolo. Inoltre i database NoSQL sono caratterizzati da scalabilità orizzontale e offrono un meccanismo trasparente all utilizzatore nell assegnazione e nell esecuzione di enormi quantità di dati. Oggi, i database NoSQL sono considerati molto affidabili, questo ha permesso di ampliare il proprio raggio d azione, permettendo di poter conservare dati critici, di poter gestire sia contenuti web, e sia dati relativi alla tracciabilità delle materie prime delle industrie di produzione. 1.1 Vantaggi e svantaggi NoSQL Dalle caratteristiche di questi database NoSQL si possono intravedere sia vantaggi che svantaggi. Se da un lato la scalabilità orizzontale (cioè la capacità di distribuire il carico di lavoro su più nodi, al fine di parallelizzare le operazioni e minimizzare le elaborazioni dei dati sul singolo nodo) offre come vantaggi un costo più basso e una maggiore tolleranza ai guasti, dall altro porta a uno svantaggio in fase di progettazione, perché l applicazione deve supportare questo modello di scalabilità. L assenza di schema, tipica dei database non relazionali, permette sia di velocizzare la fase iniziale di sviluppo di un applicazione e sia di aggiungere nuovi dati a quest ultima mantenendo inalterata l integrità dei dati. Questo ha consentito di rendere i database NoSQL estremamente flessibili, portando anche a un miglioramento della produttività di programmazione. Uno dei problemi principali presenti nei database NoSQL sono sia la mancanza di strumenti per l'analisi e il test delle prestazioni di reporting che l assenza di standardizzazione, quest ultima può causare problemi durante la migrazione dei database. 1.2 Confronto con i RDBMS Fino a pochi anni fa, quando non esisteva ancora qualcosa di più performante, produttivo, 7
scalabile e flessibile di un database relazionale, ovvero i DB NoSQL, i DBMS relazionali giocavano il ruolo di protagonisti. Ma cosa differenzia l uno dall altro? Uno dei primi aspetti che differenzia i database relazionali 3 con quelli NoSQL è che i primi aderiscono ad uno standard de facto, in cui il risultato di richieste realizzate tramite opportune query possono essere visualizzati in ambienti standard. Invece i database NoSQL sono caratterizzati da una interfaccia utente per ogni implementazione, quest ultimo è più adattabile a livello di scalabilità orizzontale. Un RDBMS ricorre ad una scalabilità verticale per consentire di contenere sempre più informazioni, pertanto richiede hardware sempre più performante e costoso. Viceversa i database NoSQL permettono di usare dispositivi molto comuni e non troppo costosi. Se da una parte nasce la necessità nei sistemi relazionali di utilizzare dei JOIN per ricostruire le informazioni da elaborare, dall altra nei sistemi NoSQL si desidera avere la massima libertà per poter modificare ed alterare sia la struttura dei dati che le relazioni che esistono tra loro, così da permettere alle applicazioni che li dovrà elaborare di organizzarli e memorizzarli in formati meno astratti. Un altra differenza sostanziale tra i database relazionali e quelli non relazionali è che, i primi possiedono uno schema rigido, ossia bloccare l intero database, per permettere l aggiunta di un nuovo campo o di una nuova relazione, fino a che la modifica non viene completata. I database NoSQL, al contrario, sono caratterizzati dall'assenza di uno schema rigido consentendo di aggiungere nuovi dati, e nuove relazioni senza la necessità di modificare la struttura del database e senza bloccarne l'accesso. Nei database non relazionali, il processo di migrazione verso un altro database risulta molto più complesso rispetto alle soluzioni relazionali. 3 Database relazionali: permettono di articolare i dati in modo da costruire modelli di raccolta dati complessi, essi si basano su relazioni univoche fra i dati. Tutti i dati sono memorizzati in strutture fisse, dette tabelle, dove sono posti l uno dopo all altro in modo da formare singoli record. Ciascun dato presente nella tabella si trasforma in un informazione vera e propria solo se associato al suo corrispondente attributo, che rappresenta l intestazione della colonna in cui il dato è memorizzato. 8
1.3 Base Teorema CAP I database NoSql non si preoccupano di soddisfare le proprietà acide (ACID 4 ), tipiche dei RDBMS, ma si concentrano sulle proprietà base (BASE). Le proprietà BASE sono state diffuse da Eric Browers e definiscono i requisiti che un sistema deve soddisfare sottostando al teorema di CAP: (B)asically(A)vailable: garantire accessibilità alle informazioni. Infatti si preferisce affidare i dati su più sistemi di salvataggio con un alto grado di replicazione, piuttosto che avere complessi sistemi. Questa distribuzione però non assicura la consistenza dei dati. (S)oft State: cambiamento nel tempo dello stato del sistema. Dato che i dati possono variare nel tempo anche in assenza di modifiche, questo principio lascia allo sviluppatore la scelta di assicurare o meno la consistenza dei dati. (E)ventual consistency: rendere consistente il sistema nel tempo, attraverso opportuni sistemi di recupero della consistenza. Si può notare che i sistemi BASE si focalizzano sulla disponibilità del servizio anziché sulla consistenza, tipica dei RDBMS. Infatti i database non relazionali cercano di fornire una base di dati sempre disponibile ed espandibile a piacere, anche se ciò non permette di garantire dati sempre aggiornati. 4 ACID: (A)tomicity: la transizione è unica nell esecuzione, o viene eseguita completa o nulla. (C)onsistency: l inizio e la fine di una transizione devono portare il sistema in uno stato coerente, in modo da garantire i vincoli di integrità dei dati. (I)solation: ogni transizione è autonoma dalle altre e un suo fallimento non può causare danni ad altre transazioni. (D)urability: quando una transizione richiede un commit, i cambiamenti non dovranno essere persi. 9
Esaminiamo in dettaglio invece i principi del teorema CAP, introdotto anch esso da Eric Browers: (C)onsistency: un sistema coerente permette di salvare un nuovo stato nel sistema, per poi utilizzarlo nelle seguenti operazioni fino alla successiva modifica dello stesso. Pertanto, tutti i client vedono sempre gli stessi dati nello stesso istante. (A)vailability: un sistema è detto continuamente disponibile quando è in grado di fornire una risposta a tutte le richieste ed erogare i propri servizi. (P)artition Tolerance: il sistema continua ad operare anche a fronte di perdita dei messaggi sulla rete e di una comunicazione con il server poco sicura. La negazione della comunicazione è causata soltanto dalla mancanza totale di connettività (total network failure). Tutti e tre i principi, secondo Seth Gilbert e Nancy Lynch, non sono possibili in un sistema informatico distribuito, ma solo due delle tre proprietà possono essere soddisfatte contemporaneamente. Le possibili combinazioni sono: Consistency+Availability (CA) elevata coerenza/alta disponibilità: tutti i nodi sono in contatto tra di loro e i dati devono essere coerenti tra tutti i nodi. Finché tutti i nodi sono attivi, gli utenti possono leggere / scrivere da qualsiasi nodo. Il sistema si blocca se si verifica una partizione della rete. Availability+Partition Tolerance (AP) elevata coerenza/tolleranza alle partizioni: in tutti i nodi del cluster i dati sono conservati in maniera coerente. Assicurando anche tolleranza alle partizione si evita che dati possano desincronizzarsi. Consistency+Partition Tolerance (CP) continua disponibilità/tolleranza alle partizioni: i nodi restano on-line, anche se la loro comunicazione risulta assente; in tutti i nodi non c è nessuna certezza che i dati e i valori relativi alla partizione e alla risoluzione, restino uguali. 10
1.4 Classificazione dei database NoSQL Nel mondo open-source sono state realizzate molti DBMS NoSQL e a seconda della struttura dati con cui si presentano i record di dato, possono essere raggruppati in quattro categorie fondamentali: 1. Column (come Cassandra): suddividono i dati per colonne in contrasto con i database row-oriented, che immagazzinano i dati per righe successive. Questi database column-oriented grazie alla memorizzazione dei valori in colonna consentono di conseguire tempi di risposta migliori, perché vengono letti soltanto i dati di interesse, diminuendo il numero di accessi alle memorie di massa. Si posso anche applicare tecniche di compressione dei dati, poiché ogni colonna è costituita da un solo tipo di dati riducendo l occupazione di spazio. I database che appartengono a questa categoria definiscono il concetto di column- family. Una column-family è un informazione che è presente nello schema e che raggruppa una stessa tipologia di informazioni in un insieme di colonne. I column family si dividono in: Standard column family: in cui la row key (la chiave più esterna ) individua l'aggregato, che a sua volta è costituito da una o più famiglie di colonne dove è possibile trovare diversi valori associati ad una diversa column key. 11
Super colunn family: è un estensione dello Standard Column Family, infatti inserisce un ulteriore livello di indicizzazione (chiamato super column) fra la row key e l insieme delle colonne. Questa chiave viene impiegata per raggruppare attributi correlati fra di loro, riferiti allo stesso aggregato. 2. Key-Value (come Dynamo, Riak): permettono di eseguire query solo sulle chiavi in modo da realizzare un sistema scalabile orizzontalmente, in cui le coppie <chiave:valore> sono assegnate tramite opportuni algoritmi. Ogni chiave è collegata ad un blob binario oscuro (questo nega l esecuzione di query basate sul contenuto del valore), che può includere una qualunque tipologia di dato (stringa di testo, documento, immagine, video, ecc...). L implementazione del modello chiave-valore consentono tipi di valore più complessi come tabelle hash o liste, mentre altri offrono mezzi per scorrere le chiavi. Sebbene questi database offrono ottime prestazioni per certe applicazioni, solitamente non supportano operazioni complicate di interrogazione e aggregazione 12
3. Document Oriented (MongoDB, SimpleDB): permettono di raggruppare gruppi di chiavi in strutture chiamate appunto documenti. Questa tipologia di database consente di compiere delle ricerche, sia sulle chiavi che sui valori, poiché i valori sono costituiti da strutture in formati come xml o json che sono pesanti. A differenza dei database basati su chiave-valore, questi sistemi forniscono interrogazioni e memorizzazione di grandi quantità di informazione 4. Graph Oriented (come Neo4J, AllegroGraph, Pregel): memorizzano le informazioni attraverso strutture a grafi, dove su di esse si effettuano ricerche per accedere ad archi e nodi (i nodi del grafo sono dati che possiedono coppie key/value, gli archi sono le relazioni). Questo tipo di database può essere considerato come un caso particolare di un database orientato ai documenti, questi ultimi rappresentano non solo i nodi, ma anche gli archi. La potenza di questo database è di gestire il passaggio da un nodo all altro sfruttando le relazioni tra nodi. 13
Capitolo 2: Big Data L imponente crescita dei dati, creata da persone (tramite smartphone, card magnetiche o con sensori, ect.), da cose (auto, beni in movimento, etc.) e da eventi (meteo, atterraggio degli aerei, pagamento finanziario, malfunzionamento di un distributore, etc.), unita allo sviluppo del web, hanno portato ad introdurre un nuovo concetto noto come i BigData. Questo fenomeno ha manifestato un bisogno non solo di tecnologie di raccolta ed elaborazione di questi dati, ma anche una maggiore capacità analitica e interpretativa. In primis si è cercato di utilizzare tecnologie e metodologie esistenti (database relazionali, architetture master/slave, etc.), parallelamente si è svolta un attività di ricerca al fine di proporre soluzioni alternative, come i database non relazionali. Ma cosa si intende per Big Data e perché sono diventati così importanti? Il termine Big Data è usato per descrivere un volume enorme di dati strutturati e non strutturati, che è difficile da trattare con tecniche di database e software tradizionali, poiché non riescono a gestire quantità di dati sempre crescenti. Inoltre i Big Data permettono di ottenere grandi benefici sia in ambito economico, garantendo maggiore accuratezza delle analisi del comportamento del mercato e delle informazioni sui clienti, sia finanziario, migliorando la gestione dei rischi e delle frodi assicurative o finanziarie, e sia in ambito scientifico. 14
2.1 Caratteristiche Secondo l analista Doug Laney, i Big Data hanno tre caratteristiche peculiari: Volume: rappresenta la dimensione del dataset. Grazie al valore di questo parametro è possibile capire se un gruppo di dati è da considerarsi Big Data o meno. Tipicamente le dimensioni sono nell ordine dei Petabytes fino all'ordine degli Zettabytes. Velocità: si riferisce alla necessità di comprimere i tempi di gestione e di analisi dei dati, quest ultimi saranno processati a ritmi sostenuti o in tempo reale. Varietà: intesa come molteplicità di fonti o come eterogeneità dei formati dei dati. Infatti i dati possono essere generati da diverse fonti interne o esterne e possono avere diversi formati (database, testo, immagini, video, audio, ect.) riconducibili a tre categorie: dati strutturati 1, semi-strutturati 2 e non strutturati 3. Questo è stato definito come modello delle "3V". Col passare del tempo si è assistito ad un aumento del Volume dei dati, della Velocità e della loro Varietà portando ad una necessità di estendere tale modello con un'ulteriore "V": 1 Dati strutturati: sono quei dati che rispettano regole predefinite quali; tipo di contenuto, lunghezza, formato, etc. Questa tipologia di dati è tipica dei DB relazionali. 2 Dati non strutturati: non seguono gli schemi di un tradizionale database e per questo motivo sono di più difficile interpretazione e richiedono quindi sforzi maggiori per il loro trattamento. 3 Dati semi-strutturati non sono conformi al modello dati di un tipico database ma possono essere divisi in records più o meno strutturati utilizzando dei separatori come i tag semantici. 15
Veridicità: indica l utilità di un dato, intesa come il valore informativo che risulta rilevante ai fini dell analisi decisionale. Successivamente il modello è stato esteso aggiungendo altre caratteristiche: Variabilità: riguarda alla contestualizzazione di un dato. Ogni dato può avere un significato diverso a seconda del contesto in cui esso viene analizzato. Complessità: più è grande la complessità e tanto più grande sarà lo sforzo per estrarre informazioni utili dai dati. 2.2 Gestione dei Big Data La gestione dei Big Data nella maggior parte degli scenari non si basa sulle tradizionali logiche di RDBMS e di SQL, ma su nuove tecniche che cercano di soddisfare efficacemente le esigenze in termini di volumi, velocità e varietà a seconda dei tipi di dati trattati. 2.2.1 Limiti dei RDBMS e nuovi approcci per l elaborazione dei Big Data Dal momento che la dimensione dei dati richiesti da trattare è aumentata enormemente, un RDBMS (Relational Database Management System) non è più considerato come la soluzione appropriata per ogni esigenza del database. Infatti un database relazionale RDBMS non è all'altezza delle esigenze dei Big Data, in quanto un primo limite dei RDBMS è dato dalla difficoltà di gestire questi grandi volumi di dati. Per far fronte a questo, i database relazionali hanno cercato di aggiungere più unità centrali di elaborazione (o CPU) o più memoria al sistema per poter scalare verticalmente. Un altro limite per i database relazionali è causato dall assenza di uno schema flessibile, che ha negato la possibilità di categorizzare i dati non strutturati, i quali sono maggiormente richiesti dai Big Data. Inoltre, essendo la velocità di crescita dei dati molto elevata nei Big Data, un RDBMS non riesce a fronteggiare questi scenari di crescita rapida, dato che è stato progettato per la gestione costante dei dati. 16
Quindi l utilizzo dei database relazionali per la gestione e la memorizzazione dei Big Data risulta da un lato troppo costoso e dall'altro addirittura inefficiente. Per poter processare efficientemente grandi moli di dati in tempi tollerabili, sono state utilizzate tre tecnologie più performanti: database NoSQL, database distribuiti (come Hadoop, Hive) e sistemi MPP (Massive Parallel Processing). Le prime due permettono l uso di hardware a basso costo, una gestione dei fallimenti e l ottimizzazione delle performance via software. I sistemi MMP sono costituiti da un sistema di I/O per ogni processore, e da operazioni suddivise in task paralleli e indipendenti. 17
Capitolo 3: HBase Una categoria di database NoSQL, utile per la gestione di un volume e una varietà di dati, è quella dei database colonnari (le cui caratteristiche sono già state descritte nel paragrafo 1.4). Uno dei database colonnari più diffusi è HBase. HBase è una base dati open source, scalabile e distribuita, caratterizzata da una gestione strutturata di dati sotto forma di tabelle di grandi dimensioni, in modo da garantire coerenza dei dati e tolleranza alle partizioni. Il suo sviluppo si basa sul modello di Google BigTable, infatti sfrutta la memorizzazione di dati distribuiti fornita da Google File System. HBase nasce come parte del progetto Hadoop dell'apache Software Foundation ed eseguito su HDFS (Hadoop Distributed File System), esso può essere usato da MapReduce 1 sia come sorgente e sia come destinazione per i suoi calcoli. Nel corso degli anni, HBase è diventato una scelta di database sempre più popolare per le applicazioni che necessitano di veloce accesso casuali a grandi quantità di dati. 1 MapReduce: è un sistema di elaborazione parallela dei dati. 18
3.1 Modello dei dati Un sistema HBase comprende una serie di tabelle. Ogni tabella è formata da righe, che sono identificate dalla Row Key e contengono un numero arbitrario di colonne. Ogni colonna rappresenta un attributo di un oggetto, molti di questi attributi vengono raggruppati in famiglie di colonna, in modo tale che gli elementi di una famiglia vengono tutti memorizzati insieme. Quindi ogni famiglia è costituita da un numero qualsiasi di colonne e ogni colonna è costituita da un numero qualsiasi di versioni. Il nome di una colonna è dato da un prefisso della famiglia (parte fissa) e da un qualificatore (parte variabile). HBase permette di aggiungere a runtime nuove colonne alle famiglie, in modo da adattarsi alle esigenze applicative. Per poter recuperare un singolo valore da una tabella HBase, bisogna specificare: una RowKey, una ColumnFamily e un timestamp (versione del valore). PICTURE TABLE 19
3.2 Architettura Hbase ha un'architettura di tipo master-slave. Un cluster HBase ha un nodo master, detto HMaster ha il compito di inizializzare il cluster e di assegnare region ai regionserver registrati nel cluster; e uno o più slave, detti HRegionServer il loro compito è di gestire le region e coordinare l'accesso ai dati. Tutte le modifiche per tutte le Regioni, portate da un particolare regionserver sono inserite prima in HLog. C è un HLog per regionserver. Nelle Regioni vengono memorizzate un insieme di righe di una tabella, e quando una tabella diventa troppo grande per essere contenuta in un server, essa può essere partizionata orizzontalmente in più Regioni. All interno di ciascuna Region è presente uno Store per ciascuna column family associata alla tabella. All interno di uno store sono presenti: un MemStore, che si occupa di conservare in RAM le modifiche (che verranno successivamente salvate sul disco) e da zero a più StoreFile che rappresentano dei file su HDFS (ogni file è composto da uno a più blocchi). Poiché più HMaster possono essere presenti contemporaneamente, HBase ha bisogno di un coordinatore esterno (Zookeeperun), per garantire che un solo master sia in esecuzione. 3.3 Caratteristiche HBase offre i seguenti benefici: 20
modello dei dati flessibile; semplici API Java per la realizzazione e la collaborazione con altri sistemi; possibilità di avere un accesso continuo ai dati, grazie all esistenza di più nodi master (fault tolerant); ricerche effettuate quasi in tempo reale (per esempio, la messaggistica); load balancing delle tabelle; replicazione dei dati; letture e scritture casuali; 3.4 HBASE VS RDBMS La differenza principale tra un database colonna-oriented rispetto a un database filaoriented è su come i dati vengono memorizzati sul disco. La massima dimensione dei dati gestita dai database relazionali è sui Terabytes, invece in HBase è di circa centinai di Petabytes. HBase non supporta un linguaggio di interrogazione strutturato come SQL (tipico dei database relazionali), infatti le applicazioni HBase sono scritte in Java. 3.5 HBASE VS HDFS HDFS è un file system distribuito che è adatto per la memorizzazione di file di grandi dimensioni. HBase è costruito sulla base di HDFS, ma mettendoli a confronto presentano alcune differenze: HDFS è più adatto per le operazioni di elaborazioni batch di alta latenza, ciò nega la possibilità di letture e scritture casuali, al contrario HBase è progettato per le operazioni di bassa latenza; l accesso ai dati è consentito attraverso MapReduce (nel HDFS), invece HBase prevede comandi di shell, API Java e Thrift. 21
3.6 Sperimentazione Nei precedenti paragrafi è stata fornita una panoramica sul database HBase, in particolare è stato illustrato il suo modello dei dati utile per poter comprendere l esecuzione dei test effettuati tramite la shell di HBase. Per poter effettuare i test sul nostro database è necessario, dapprima configurare opportunamente il sistema, e solo dopo è possibile avviare la shell HBase mediante il seguente comando:. /hbase shell Di seguito sul terminale, se tutto è andato a buon fine, apparirà il prompt di shell HBase. Per questa sperimentazione si presuppone di popolare il database con il dataset di DBpidia 2, e si è previsto di realizzare una tabella (chiamata PICTURE) per memorizzare i quadri di differenti pittori. La creazione di questa tabella è ottenuta mediante la seguente sintassi: create <table name>, <column family>. In questo caso Author e Opera sono due column family. Con il comando list è possibile elencare le tabelle HBase create: 2 DBpedia: è uno dei più importanti progetti legati al Web semantico, il progetto consiste nella trasposizione in dati strutturati di tutto l enorme patrimonio di conoscenze di Wikipedia, e nel rilascio di queste informazioni sul Web come Linked Open in formato RDF (Resource Description Framework). 22
list <table name>. La shell HBase permette di inserire un valore all interno di una tabella mediante il comando put: put <table name>, <row>, <column family prefix: column qualifier suffix>, <value>. Si può osservare che ciascuna riga della tabella PICTURE è identificata da una row key, la quale contiene le informazioni passate al database ed è costituita in questo caso da un URL. Come qualificatore della column family si è scelto di dare informazioni sul nome, cognome, nazionalità e stile artistico dell autore, mentre invece per l opera si è deciso di specificare nome, data, tecnica e ubicazione. Il comando put ci permette anche di aggiornare un valore già esistente, per farlo basta seguire la stessa sintassi e indicare il nuovo valore: Il conteggio del numero di righe di una tabella è effettuato tramite il comando count: 23
count <table name>. Mediante il comando get è possibile prelevare i contenuti relativi ad una riga: get <table name>, <row>. Oppure specificando sia la column family che il qualificatore si può ottenere il seguente risultato: get <table name>, <row>, <column family>. get <table name>, <row>, <column family: column qualifier>. Per poter visualizzare i dati della tabella creata, basta digitare il comando scan seguito dal nome della tabella: 24
scan <table name>. Con il comando scan si possono estrarre valori da una determinata column family specificando anche un qualificatore della column family. La sintassi è la seguente: scan <table name>, {COLUMNS => column family: column qualifier }. Utilizzando il comando deleteall è possibile eliminare una specifica riga dalla tabella. La regola per la costruzione corretta di questo comando è la seguente: 25
deleteall <table name>, <row>. Con delete si può rimuovere anche un determinato qualificatore della column family, specificando nella sitassi sempre la riga: delete <table name>, <row>, < column family: column qualifier>. Una tabella per essere eliminata, bisogna prima disabilitarla tramite il comando disable e solo dopo digitando drop, la tabella verrà definitivamente rimossa. 26
HBase permette anche di poter interagire attraverso l interfaccia web, digitando il seguente URL nel browser: http: //localhost:60010 27
Attraverso questa interfaccia si possono visualizzare: i Region Server in esecuzione, i master di backup, le tabelle HBase, lo stato del cluster, le statistiche, ect. 28
Ringraziamenti Desidero innanzitutto ringraziare il Prof. Moscato per i preziosi insegnamenti impartiti durante lo svolgimento delle sue lezioni e per l attenzione dedicata al mio elaborato. Inoltre, ringrazio tutti i docenti incontrati durante il mio percorso accademico, da ognuno di essi ho avuto modo di imparare qualcosa, non solo a livello didattico ma anche a livello umano. Un pensiero va ai miei genitori per l apporto morale e economico ai miei studi, oltre che per il grande aiuto che mi hanno sempre dato. Desidero ringraziare le mie sorelle per avermi aiutato in ogni momento e per non aver mai smesso di motivarmi e di supportarmi. Vorrei ringraziare anche Zia Elena, Zio Antonio, che nonostante la distanza hanno sempre avuto un pensiero per me. Un grazie va a Maria, una splendida persona conosciuta all università che è diventata la mia migliore amica. Ringrazio Carmela e Roberta per i bei momenti passati insieme in questi anni di università. Inoltre, esprimo tutta la mia gratitudine ai colleghi d università in modo particolare a Federico, che hanno condiviso con me questo percorso. Infine voglio ringraziare una persona molto importante nella mia vita, per la sua enorme pazienza, per essermi stato sempre vicino, per avermi sempre sostenuta e per aver creduto in me più di chiunque altro. Grazie Carmelo.. 29
Conclusioni Il lavoro di tesi ha fornito la possibilità di valutare la validità dei database NoSQL, i quali negli ultimi anni hanno attirato un gran numero di imprese e aziende, poiché sono in grado di garantire una velocità di esecuzione nell elaborazione di enormi quantità di dati, una scalabilità orizzontale con l aggiunta di nuovi server, e anche la possibilità di gestire migliaia di dati non strutturati senza dipendere da uno schema fisso. La crescita esponenziale del volume di dati generati da utenti, sistemi e sensori, ulteriormente accelerato dalla concentrazione di gran parte di questo volume su sistemi distribuiti, ha ricoperto una grande importanza nel mondo dei Big Data. Infatti questi ultimi hanno assunto una grande rilevanza nella vita di tutti i giorni, permettendo di gestire ingenti quantità di dati in maniera più efficiente e di soddisfare esigenze che prima non potevano trovare un riscontro. Per poter memorizzare e analizzare questi moli di dati, che da sempre ha costituito una problematica non superabile con i database tradizionali, sono state introdotte diverse categorie di database non relazionali. Una delle categorie presa in considerazione in questo elaborato è quella dei database colonnari, in particolare il database HBase, che offre una serie di vantaggi: permette di archiviare una grande quantità di dati offrendo un architettura orientata alla scalabilità, consente l integrazione con MapReduce e HDFS, supporta anche semplici API REST per accedere alle risorse e permette di operare in memoria. Con l utilizzo della shell di HBase si è potuto dimostrare che essa è stabile, veloce e di semplice utilizzo. In definitiva il mondo è in continuo evoluzione e sicuramente nei prossimi anni alcuni di questi database spariranno, mentre altri prenderanno il loro posto, traendo vantaggi dai vari database. 30
Bibliografia [1] https://hbase.apache.org [2] https://otherplus.com/tech/database-nosql/ [3] http://www.megadix.it/files/www.megadix.it/defranciscis_nosql.pdf [4] http://www.ecos2k.it/allegati/bigdata.pdf [5] http://www.cloudera.com/content/cloudera/en/products-and-services/cdh/hbase.html [6] http://www-01.ibm.com/software/data/infosphere/hadoop/data-scientist.html [7] http://akbarahmed.com/category/hbase/ [8] Perego A, Pasini P, Big Data Live: casi di eccellenza, SDA Bocconi 2013 [9] Perego A, Pasini P, Nuove fonti di conoscenza Aziendale e nuovi modelli di management, SDA Bocconi, Dicembre 2012 [10] http://www.tutorialspoint.com/hbase/hbase_installation.htm [11] http://it.wikipedia.org/wiki/big_data 31