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 source1 che non utilizzava un'interfaccia SQL. La parola NoSQL
potrebbe far pensare che è un movimento contrario all'utilizzo di database2 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
1Open
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 relazionali3 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 (ACID4), 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 columnfamily. 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
aggregazione
12
complicate
di
interrogazione
e
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 strutturati1, semi-strutturati2 e non strutturati3.
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 MapReduce1 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
DBpidia2, 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
