Scuola Politecnica e delle Scienze di Base
Corso di Laurea in Ingegneria Informatica
Elaborato finale in Basi di Dati
Database NoSQL: Apache Accumulo
Anno Accademico 2015/2016
Candidato:
Marco De Simone
matr. N46001935
Indice
Indice .....................................................................................................................................................I
Introduzione ......................................................................................................................................... 1
Capitolo 1: Database NoSQL............................................................................................................... 2
1.1
Teorema CAP ........................................................................................................................ 3
1.2
Classificazione dei database NoSQL .................................................................................... 4
1.2.1
Key-Value ...................................................................................................................... 5
1.2.2
Document-Oriented ........................................................................................................ 6
1.2.3
Graph .............................................................................................................................. 8
1.2.4
Column-Oriented ......................................................................................................... 10
1.3
Confronto tra database NoSQL e SQL ................................................................................ 11
Capitolo 2: Apache Accumulo ........................................................................................................... 16
2.1 Storia ........................................................................................................................................ 16
2.2 Struttura e componenti ............................................................................................................. 18
2.3 API di Accumulo ..................................................................................................................... 20
2.4 Caratteristiche .......................................................................................................................... 21
2.5 Utilizzi di Apache Accumulo ................................................................................................... 24
Conclusione........................................................................................................................................ 27
Bibliografia ........................................................................................................................................ 28
I
Introduzione
Questo elaborato di laurea tratta i database NoSQL enunciandone le caratteristiche e
gli aspetti più importanti. Il database scelto come oggetto di lavoro è Apache
Accumulo, sviluppato dall’NSA negli anni 2000.
L’elaborato è suddiviso in capitoli, in ognuno dei quali è stato affrontato un argomento
diverso, in particolare nel primo capitolo viene fatta un’introduzione dei database
NoSQL analizzandone la storia e le motivazioni che portarono allo sviluppo dei
database NoSQL. Inoltre viene affrontato il teorema CAP che è alla base del
movimento NoSQL. Successivamente viene fatto un confronto tra i database NoSQL
e i database relazionali o SQL mostrandone le differenze ed elencandone i pregi e i
difetti di entrambe le categorie, inoltre classificando i database NoSQL nelle 4 famiglie
principali si evidenziano come ogni tipologia di database si struttura, come vengono
usati e come vengono gestiti.
Infine nel secondo capitolo si è concentrati sull’analisi del database Apache Accumulo,
descrivendone la storia che ha portato alla sua creazione da parte dell’NSA, le sue
caratteristiche e le sue componenti, le client API e i suoi principali utilizzi.
1
Capitolo 1: Database NoSQL
Il termine “database” è stato per molto tempo associato ai database SQL, meglio
conosciuti come RDBMS. Negli ultimi anni per risolvere le problematiche delle grandi
aziende, come Google, della gestione di grandi quantità di dati prodotti
quotidianamente, si è deciso di sviluppare un nuovo tipo di database che andasse a
superare le limitazioni degli RDBMS, da qui la nascita dei database NoSQL.
NoSQL è l’acronimo di Not Only SQL con cui si vuole andare a sottolineare che la
nuova tecnologia non è del tutto incompatibile con i database SQL (Structured Query
Language), infatti in alcuni casi è possibile utilizzare il linguaggio di quest’ultimi per
interrogare i NoSQL anche se con qualche limitazione.
Il termine NoSQL fu usato per la prima volta nel 1998 per una base di dati relazionale
open source che non usava un'interfaccia SQL. L'autore Carlo Strozzi dichiarò che
"come movimento, NoSQL diparte in modo radicale dal modello relazionale, e quindi
andrebbe chiamato in modo più appropriato NoREL, o qualcosa di simile” [1].
Tuttavia solo a partire dal 2009 questo movimento ha mostrato una rapida crescita,
sono infatti già molte le aziende che decidono di passare a questo tipo di database.
Tra i pionieri troviamo Google con il suo BigTable e Amazon che ha dato vita a
DynamoDB. Entrambi i DB hanno dimostrato la necessità di uscire dai classici schemi
2
relazionali per permettere un'efficiente scalabilità dei loro servizi e soddisfare le
proprie esigenze.
Da questi esperimenti sono nati i primi database NoSQL, ognuno caratterizzato da
strutture dati diverse e altamente ottimizzate, ma che comunque presentano
caratteristiche in comune quali:
- Schema free.
- Gestione di un'enorme quantità̀ di dati garantendone un rapido accesso.
- Facilità di replicazione.
- Utilizzo di api per l'interfacciamento con i più noti linguaggi di sviluppo.
1.1
Teorema CAP
Il teorema CAP, conosciuto anche come teorema di Brewer dal nome di Eric Brewer
che lo presentò nel 2000 alla conferenza “Principle of Distributed Computing”, viene
considerato una pietra miliare del pensiero NoSQL. Ogni lettera dell’acronimo CAP
rappresenta una caratteristica del sistema:
• Consistency (Coerenza): dopo una modifica tutti i nodi del
sistema distribuito riflettono la modifica.
• Availability (Disponibilità): ad una richiesta, il sistema è
sempre in grado di dare una risposta.
3
• Partition Tollerance (Tolleranza al Partizionamento): se le comunicazioni si
interrompono tra due punti del sistema, il sistema non fallisce ma continua ad essere
disponibile.
Questo teorema afferma che “è impossibile per un sistema informatico distribuito
fornire simultaneamente tutte e tre le seguenti garanzie: completa coerenza dei dati,
continua disponibilità e tolleranza alle partizioni” [1], quindi è necessario stabilire di
volta in volta in base ai requisiti quale delle tre garanzie sacrificare. Ad esempio
Amazon con il suo DynamoDB, avendo a che fare con la tolleranza al partizionamento,
ha deciso di sacrificare come garanzia la coerenza prediligendo le caratteristiche AP.
1.2
Classificazione dei database NoSQL
I database NoSQL si diversificano in varie tipologie che possono essere confrontate
secondo parametri specifici quali la scalabilità, la capacità del sistema di accrescere o
decrescere in base alle esigenze, le prestazioni infatti una macchina più potente può
effettuare operazioni più complesse e la consistenza cioè la capacità di eseguire una
transizione senza l’interferenza di altre transizioni per tutta la sua durata. Un’altra
classificazione può essere fatta con il teorema CAP, che come detto precedentemente
4
un database NoSQL non può rispettare contemporaneamente tutte e tre le garanzie
(Consistency, Availability, Partition).
I modelli dei database NoSQL sono riconducibili a 4 grandi famiglie ognuna
caratterizzata con una tipologia di modello di dato. I database spesso non utilizzano
una sola tipologia in modo rigoroso ma spesso accade che vengono utilizzati modelli
compositi [2].
1.2.1 Key-Value
Il modello a chiave valore si basa su una API analoga ad una Map. Il valore è un
oggetto trasparente per il sistema, cioè è possibile fare le query solo sulle chiavi ma
non sui valori; inoltre il modello kay-value è basato sul concetto di associative array,
ossia una semplice struttura in grado di contenere le coppie chiave/valore. La chiave,
come nei database relazionali, è un identificativo univoco grazie al quale è possibile
ricercare ed identificare i dati presenti nel database. Solitamente gli Associative array
sono implementati attraverso Hash Table e consentono le seguenti operazioni:
ADD: Per aggiungere un elemento all’array.
REMOVE: Per eliminare un elemento dall’array.
MODIFY: Per cambiare il valore associato ad una data chiave.
FIND: Per trovare un valore nell’array tramite la chiave.
5
Questo modello consente di estendere le API per permettere transizioni che
coinvolgono più chiavi, ma questa soluzione sarebbe controproducente perché
l’utilità di questo modello è proprio quello di avere coppie chiave-valore non legate
tra loro per avere una maggiore scalabilità orizzontale. Il modello key-value può
risultare semplicistico se paragonato a un classico RDBMS, ma può essere usato in
numerosi ambiti come per esempio in un sito di e-commerce. Un esempio di database
key-value è Cassandra, un DBMS open source utilizzato e sviluppato da Facebook.
1.2.2 Document-Oriented
I sistemi che implementano questo modello possono essere realizzati sopra un
database relazionale o ad oggetti. Questo modello è simile al modello key-value
tranne per il fatto che il valore può essere interpretato e interrogato dal sistema,
inoltre i dati non sono memorizzati in tabelle con campi uniformi ma ogni record è
salvato come documento, il quale possiede determinate caratteristiche dove si
possono aggiungere un qualsiasi numero di campi di qualsiasi lunghezza. I formati
più utilizzati sono XML, YAML, PDF e JSON. Generalmente i DBMS document-
6
oriented utilizzano una o più proprietà degli oggetti per indicizzarli ed è possibile
effettuare delle interrogazioni basate sulle proprietà dell’oggetto.
Ad esempio, se consideriamo una collezione di documenti JSON che rappresentano
gli utenti di un forum, una query potrebbe essere “tutti gli utenti che hanno ‘Java’ tra
i tag dichiarati”, e potrebbe essere espressa tramite un oggetto JSON. A differenza
dei campi delle basi di dati relazionali che possono rimanere vuoti nei sistemi
document-oriented non ci sono campi vuoti. I documenti sono indirizzati nella base
di dati attraverso delle chiavi univoche che vengono inserite all’interno di un indice
che consente un più veloce recupero del documento. Esempi di DBMS orientati ai
documenti sono MongoDB, CouchDB, JackRabbit e TerraStore.
7
1.2.3 Graph
I modelli key-value e documentoriented sono limitati se si
vogliono contenere dati molto
interconnessi.
Per
risolvere
questo problema si utilizza un
altro modello di database NoSQL, il modello a grafo. Un database a grafo lo si può
vedere come un caso particolare del modello orientato ai documenti in cui alcuni
documenti rappresentano le relazioni. Questo modello di database è molto potente
perché l’operazione di attraversamento (graph traversal) stabilisce come passare da
un nodo all’altro utilizzando le relazioni tra i nodi. Ad esempio, se consideriamo il
dominio di un social network in cui abbiamo dei nodi di tipo Utente e una relazione
di tipo Amicizia, un attraversamento del tipo: “Tutti i nodi di tipo Utente collegati
all’utente X tramite la relazione Amicizia con una profondità 2, con ricerca in
ampiezza” implementa la funzione “Altre persone che potresti conoscere…”.
8
Facendo riferimento alla teoria dei grafi, attualmente, i modelli di riferimento per
l’implementazione di basi di dati con questo schema sono due: il property graph
model e il resource description framework graph (RDF), il quale è il modello di
riferimento del Web semantico e i database che lo utilizzano sono anche noti come
Triple Store, Quad Store, o RDF Store. Un database open source a grafo è Neo4j.
9
1.2.4 Column-Oriented
Sebbene il nome possa ricordare le tabelle dei classici RDBMS, nei modelli columnoriented (o tabulari) si parla di dati schemaless. I dati sono memorizzati insieme per
colonna, mantenendo l’organizzazione in righe e colonne. Per evitare la presenza di
dati null, ogni riga può avere un set diverso di colonne che possono essere tolte o
aggiunte in base alle necessità. Per quanto riguarda la struttura dei dati in questo
modello ogni contenuto memorizzato ha una chiave e un documento. Il documento,
non avendo uno schema formale, non prevede nessuna specifica che indichi gli
attributi obbligatori e il loro tipo, quindi sarà composto da un valore oppure da una
serie di tuple nome-valore.
I vantaggi offerti da questo tipo di orientamento si vedono soprattutto in lettura:
• Le query mirano a recuperare valori soltanto da determinate colonne e quindi non
da tutta la riga.
10
• Essendo composte da tipi di dati uniformi, le colonne risultano essere più facili da
comprimere, a vantaggio della velocità di esecuzione. Inoltre è possibile
memorizzare una grande quantità di dati sparsi in un gran numero di server.
Gli svantaggi al contrario sono che a causa della complessità del modello, a parte la
chiave primaria, non è facile effettuare interrogazioni
Un esempio di database che utilizza questo modello è BigTable di Google.
1.3
Confronto tra database NoSQL e SQL
I database NoSQL non sono un rimpiazzo dei database RDBMS tradizionali ma si
possono affiancare o in parte sostituire in base alle proprie necessità. Il confronto tra
database NoSQL e SQL può essere riassunto in 6 parti: [4]
-
Struttura e tipi di dato memorizzati
I database relazionali per contenere i dati richiedono una struttura di attributi ben
definiti a differenza dei database NoSQL che consentono un libero flusso di
operazioni. Questa cosa si traduce in una maggiore semplicità di questi database
11
che permettono di aggiungere nodi a caldo in maniera impercettibile dall’utente
finale. Inoltre scegliendo un database adatto alle classi di oggetti si riducono di
molto i tempi di scambio di informazioni tra le applicazioni e il database stesso.
-
Esecuzione di query
Nei database relazionali tutto ruota intorno al concetto di tabella, ne esiste una
per ogni oggetto da creare. Nelle tabelle svolgono un ruolo fondamentale le
chiavi primarie che permettono di riconoscere univocamente una riga dalle altre.
Tra le tabelle possono esistere delle relazioni inserendo la chiave primaria di una
riga all’interno di un’altra. Per interrogare un DBMS si usa il linguaggio SQL
ed una delle operazioni più comuni è il JOIN cioè un incrocio tra tabelle in
relazione tra loro che permette di ottenere informazioni complete. Questo tipo di
struttura rigida non esiste in NoSQL, in cui le informazioni ora si trovano in
oggetti non strutturati come ad esempio documenti archiviati in collezioni. In
NoSQL sono assenti le relazioni, le informazioni vengono collegate con due
meccanismi: embedding cioè annidare un oggetto all’interno di un altro e
referencing che consiste nell’inserire l’id di un documento all’interno di un altro.
-
Scalabilità
Il termine scalabilità si riferisce alla capacità di un sistema di “crescere” o
diminuire in scala in funzione delle necessità e delle disponibilità. Sia i database
SQL che quelli NoSQL possono essere scalati verticalmente (aumentando le
risorse del sistema). Tuttavia i sistemi NoSQL presentano anche la possibilità di
scalare orizzontalmente creando un cluster di più macchine.
-
Affidabilità
In termini di affidabilità dei dati e della sicurezza dell’esecuzione delle
transazioni i database SQL rappresentano la soluzione migliore a causa della
mancanza di controlli sull’integrità dei dati da parte dei database NoSQL, il
12
compito ricade quindi sull’applicativo che comunica con il database. Per
esempio in un database non relazionale che contiene le informazioni di clienti
con i relativi ordini effettuati, se venisse cancellato un utente tutti gli ordini
relativi rimarrebbero nel database, quindi è compito dell’applicativo cancellare
anche i relativi ordini, cosa che verrebbe gestita automaticamente da un database
SQL.
-
Supporto
La mancanza di uno standard universale per i database NoSQL comporta che
ogni database ha le proprie API e un suo metodo di storing e di accesso ai dati.
Quindi se lo sviluppo di un database venisse interrotto il passaggio ad un altro
database
non
sarebbe
immediato
ma
comporterebbe
alcuni
cambi
all’applicativo. Al contrario i RDBMS adoperando lo standard come SQL
permettono un rapido trasferimento di dati da un database all’altro ed è facile
trovare supporto sia a pagamento che gratuito in caso di problemi grazie al loro
vasto utilizzo.
-
Conservazione di dati complessi ed esigenze nell’esecuzione di query
I database relazionali sono molto più efficienti per l’esecuzione di query
complesse e per le problematiche sulla conservazione dei dati, tanto da
rappresentare la soluzione di riferimento.
In seguito viene mostrata una tabella riassuntiva con le maggiori differenze tra
database SQL e NoSQL.
13
Database SQL
Tipi Un solo tipo (database SQL)
con varianti minori.
Database NoSQL
Tipi differenti come i modelli
key-value, orientato ai
documenti, orientato a colonne
e a grafo.
Storia dello sviluppo Sviluppato negli anni 70 con
Sviluppato negli anni 2000 per
l’avvento delle prime
andare a colmare le limitazioni
applicazioni per la
dei database SQL come la
memorizzazione di dati.
scalabilità, dati multistrutturati e geo-distribuzione.
Esempi MySQL, Postgres, Microsoft
SQL Server, Oracle Database.
Modello di memorizzazione Singoli record (es
dati ‘dipendente’) sono
MongoDB, Cassandra, HBase,
Neo4j
Il modello di memorizzazione
dei dati cambia in base al tipo
memorizzati come righe in
di database utilizzato. Per
tabelle, con ogni colonna che
esempio i database chiave-
memorizza una specifica parte
valore funzionano in un modo
del record (es. ‘manager’,
simile ai database SQL, hanno
‘data assunzione’). I dati
solo due colonne (‘key’ e
correlati sono memorizzati in
‘value’), con delle
differenti tabelle e
informazioni più complesse
successivamente vengono
salvate nella colonna dei
collegati quando vengono
valori. I database orientati a
eseguite query complesse. Per
documenti, invece non
esempio ci può essere una
utilizzano più le tabelle ma
tabella ‘ufficio’ e quando un
salvano le informazioni in
utente vuole conosce
documenti in JSON, XML o in
l’indirizzo di lavoro di un dato
altri formati che possono
dipendente il motore del
nidificare una gerarchia di
database collega le tabelle
valori.
‘dipendente’ e ‘ufficio’.
14
Schema Struttura e i tipi di dati sono
Tipicamente è dinamico, con
fissati in anticipo. Per
alcune regole da rispettare. Le
aggiungere nuovi tipi di dati il
applicazioni possono
sistema deve essere alterato e
aggiungere nuovi campi
durante questo tempo il
rapidamente e dati di tipi
database è offline.
differenti possono essere
salvati insieme se necessario.
Scalabilità Scalabilità verticale, cioè che
Scalabilità orizzontale,
un singolo server può
l’amministratore del sistema
aumentare le proprie
può semplicemente dividere il
prestazioni per soddisfare una
sistema su più macchine o
maggiore richiesta. Un
utilizzare servizi di cloud. Il
database SQL può essere
database divide
diviso su più macchine ma
automaticamente i dati tra i
questo richiede un lavoro
server se necessario.
ingegneristico maggiore e
tipicamente operazioni come
le JOIN non possono più
essere effettuate.
Modello di sviluppo Misto tra open-source
Open-source.
(Postgres, MySQL) e closedsource (Oracle Database).
Supporto transazioni Supporta le transazioni.
Vengono supportate solo in
certe circostanze e a certi
livelli.
Manipolazione dati Con specifici linguaggi usando Attraverso delle API orientate
Select, Insert e Update.
Consistenza Può essere configurato per una
consistenza maggiore.
agli oggetti.
Dipende dalla base di dati,
alcune hanno una maggiore
consistenza come MongoDB,
altre offrono una consistenza
minore (es. Cassandra).
15
Capitolo 2: Apache Accumulo
Apache Accumulo è un database NoSQL open source scritto in Java appartenente alla
famiglia key-value, costruito sull’architettura shared-nothing (vengono rimosse le
dipendenze tra le unità di scala in modo da rendere più facile la scalabilità aggiungendo
o rimuovendo unità) che permette di espandere il numero di nodi in modo da poter
contenere una grande quantità di dati.
2.1 Storia
L’agenzia per la sicurezza nazionale americana NSA interessata all’idea di un database
NoSQL che avesse un’elevata capacità di scalabilità, incominciò nel 2008 a progettare
Apache Accumulo usando il database BigTable di Google come punto di partenza
come fece Facebook con il proprio database
Cassandra. L’NSA progettò questo nuovo database
per poter implementare dei propri meccanismi di
sicurezza che andavano a limitare il numero delle
persone che potevano accedere ai dati. Alla
conferenza O’Reilly Strata-Hadoop World del 2013
16
a New York uno dei principali programmatori dell’NSA che lavorò allo sviluppo di
Accumulo, Adam Fuchs, spiegò come Accumulo lavorava e come potrebbe essere
usato in settori diversi per la raccolta di dati. Adam Fuchs ora è Chief Technology
Officer di Sqrrl, una startup che offre una versione commerciale per le imprese di
Apache Accumulo. Nel 2011 l’NSA rilasciò Accumulo alla fondazione Apache.
17
2.2 Struttura e componenti
Accumulo è costruito sulla base di altri software Apache quali Hadoop che fornisce il
filesystem HDFS e Zookeeper per sincronizzare le impostazioni fra tutti i suoi
processi.
• HDFS ha una architettura master/slave. Un cluster HDFS consiste in un singolo
NameNode, un server master che gestisce lo spazio dei nomi del filesystem e regola
l’accesso ai file dei client. In aggiunta al Namenode ci sono diversi Datanode, di solito
uno per nodo, che gestiscono la memoria. Internamente un file è diviso in uno o più
blocchi e i quali sono memorizzati in un gruppo di Datanode. Il Namenode esegue le
operazioni del filesystem come aprire, chiudere e rinominare file e directory, inoltre
determina la mappa dei Datanode. I Datanode invece sono responsabili di servire le
richieste di scrittura e lettura provenienti dal filesystem del client. HDFS è scritto in
Java e tipicamente viene utilizzato su macchine che eseguono un sistema operativo
GNU/Linux.
• Zookeeper è un servizio centralizzato per il mantenimento della configurazione delle
informazioni e dei nomi fornendo una sincronizzazione distribuita. Tutti questi tipi di
servizi sono utilizzati da altre applicazioni distribuite. Zookeeper è utilizzato da
numerose compagnie come Rackspace, Yahoo!, Reddit e Ebay.
• I TabletServer gestiscono ognuno una partizione di tabelle, questo include ricevere le
write dai client inserendole in un registro, associando periodicamente delle coppie
chiave-valore ai nuovi file in HDFS e rispondere alle richieste di read dai client
fornendo una vista unificata di tutte le chiavi e valori di tutti i file creati.
18
• Il Garbage Collector è un processo che periodicamente identifica ed elimina i file che
non vengono utilizzati da molto tempo da nessun processo.
• Il Master di Accumulo è responsabile del rilevamento e della risposta ai fallimenti dei
TabletServer. Esso cerca di bilanciare il carico dei TabletServer assegnando loro le
tabelle accuratamente e li istruisce nello scaricare le tabelle quando serve. Inoltre si
assicura che ogni tabella è assegnata a un TabletServer e manipola la creazione, le
modifiche e la cancellazione delle stesse quando i client lo richiedono.
• Il processo Tracer si occupa delle API temporali distribuite da Accumulo. Questi
processi possono essere eseguiti in un cluster che scriverà le informazioni sulle
tempistiche da dare alle tabelle di accumulo per dei futuri riferimenti.
• Il Monitor di Accumulo è una applicazione web che si occupa delle informazioni sullo
stato delle istanze. Il Monitor si occupa di mostrare i grafi e le tabelle che contengono
le informazioni sulla lettura e scrittura dei tassi, nascondere i tassi di successo e di
mancanza e la tabella delle informazioni di Accumulo come per esempio le
compressioni attive e in coda. In aggiunta il Monitor dovrebbe essere il punto di
partenza quando si tenta di eseguire il debug di un problema di Accumulo perché
mostra i problemi di alto livello insieme agli errori provenienti da tutti i nodi nel
cluster. Possono essere eseguiti più monitor alla volta.
• Accumulo include delle librerie per i client che vengono utilizzate da ogni applicazione
che si vuole interfacciare con il database. Queste librerie forniscono la logica per
trovare i server, gestire una particolare tabella e comunicare con i TabletServer per
scrivere e leggere le coppie chiave-valore.
19
2.3 API di Accumulo
Le API di Accumulo che vengono fornite ai client sono:
Batch Scanner: prende una lista di intervalli, li raggruppa in tablet server
appropriati e ne restituisce i dati.
Batch Writer: il client buffer scrive in memoria i dati prima di raggrupparli in
tablet server.
Bulk Import: invece di scrivere singoli update su Accumulo, possono essere
importati interi file con coppie chiave-valore. Questi file vengono spostati nella
directory di Accumulo e vengono referenziate. Questa caratteristica è utile per
poter importare una grande quantità di dati. Questo metodo consente anche una
maggiore flessibilità nell’allocazione dei dati.
Map Reduce: Accumulo può essere una sorgente e/o il fondo per riduzione
della mappa degli incarichi.
20
Apache Thrift Proxy: il codice client di Accumulo è molto complesso. Per
esempio il codice individua le tabelle, i tentativi in caso di guasti e supporta
scritture e letture simultanee. Il codice è scritto completamente in JAVA, per
questo il thrift proxy avvolge le client API rendendole disponibili anche per
altri linguaggi di programmazione come Python e C++.
Conditional Mutations: le mutazioni condizionali permettono di eseguire
delle operazioni efficienti e atomiche di lettura e scrittura sulle righe. Le
condizioni possono essere definite utilizzando controlli di uguaglianza dei
valori in una colonna.
2.4 Caratteristiche
Accumulo ha molte caratteristiche che lo rappresentano, una di queste è la sicurezza
del livello delle celle di memoria. La sicurezza al livello delle celle di memoria è
importante perché rende capace il sistema di assegnare ad ogni utenti i permessi per
accedere a tali celle. Questo è significativo negli scenari dei Big Data perché consente
agli amministratori di estendere l’accesso e le funzionalità di un database a un numero
massimo di utenti pur rimanendo nel rispetto della normativa sulla privacy e di
sicurezza vigenti. Con questo tipo di sicurezza gli utenti possono avere accesso al
database e a tutte le tabelle al suo interno, ma l’accesso alle celle di memoria viene
regolamentato e criptato dal sistema. Così la sicurezza a livello di cella permetterebbe
più utenti di accedere al database con una conseguente più veloce e chiara analisi.
Un’altra caratteristica è l’approccio con cui Accumulo salva i dati, basato sul modello
RBAC (role-based access control) che consente di categorizzare in livelli multipli (nel
21
caso dell’NSA i dati vengono categorizzati in confidenziali, segreti e top secret) così
chi accede al database può accedere solo alla categoria di dati in base al proprio livello.
Questo modello è molto versatile e può essere utilizzato in ogni ambiente che richiede
una sicurezza. Per esempio in ambito ospedaliero Accumulo può autorizzare solo il
paziente e il medico del paziente a vedere la propria cartella clinica. Un altro aspetto
importante di Accumulo è la gestione dei dati su richiesta. Il database, infatti, su
richiesta dell’utente può effettuare delle manipolazioni sui dati per migliorarne la
ricerca, la gestione e le performance. Alcuni esempi di on-demand data manager sono
la compattazione, che è l’abilità di compattare le tabelle in un solo in un solo file per
aumentare le prestazioni delle query, la clonazione delle tabelle, operazione utile in
fase di testing e l’importazione e l’esportazione delle tabelle.
Di seguito vengono mostrate alcune schermate dell’interfaccia di Apache Accumulo.
22
23
2.5 Utilizzi di Apache Accumulo
Apache Accumulo è la soluzione ideale per le agenzie governative e le aziende per la
creazione e la gestione di applicazioni sicure e in real-time, che comprendono:
Sessionization (processo che misura il comportamento degli utenti, ordinando
una serie di azioni o richieste fatte da un singolo utente nel corso di
un’interazione).
Metriche e analisi in tempo reale.
Grafici dei dati.
Applicazioni per “l’internet delle cose”.
Il database Apache Accumulo viene comunemente usato per analizzare e raccogliere
dati in tempo reale e fornire i relativi grafici. Un esempio significativo è il programma
Trendulo che mostra come Apache Accumulo può essere utilizzato per l’analisi delle
tendenze. Trendulo supporta le API di Twitter, quindi può analizzare le parole e le
frasi che vengono utilizzati nei post pubblicati dagli utenti del social network e fornire
all’utente del programma una tabella con le tendenze. I dati possono essere estratti con
diverse cadenze temporali (un giorno, o più giorni) per poi essere confrontati e fornire
un andamento temporale delle tendenze. Trendulo è un progetto open source fornito
in due varianti, uno per poter interrogare Accumulo e un’altra per importare dati da
internet per l’uso immediato o per memorizzarlo in un database [11].
24
Un altro esempio relativo all'utilizzo del database Accumulo deriva dall’ambito
aziendale dove la gestione dei dati è un aspetto critico quanto fondamentale. Tra le
aziende che forniscono software basati su Apache Accumulo si citano Cloudera e
Sqrrl, di cui abbiamo trattato nel primo capitolo.
La
prima,
basata
su
Apache
Hadoop, fornisce alle aziende un
software per la gestione dei dati aziendali permettendo una migliore e più rapida
soluzione dei problemi aziendali e la creazione di una base di dati di livello enterprise.
Questo tipo di base di dati permette di esportare le informazioni su un cloud
consentendo a clienti e dipendenti dell’azienda di potervi accedere con una maggiore
facilità e immediatezza. Inoltre, Cloudera offre un elevato livello di sicurezza dei dati
contro gli attacchi informatici [12].
Sqrrl, società fondata da alcuni programmatori che parteciparono allo sviluppo di
Accumulo, fornisce una versione enterprise di Apache Accumulo per tutte quelle
25
aziende che necessitano di un elevato livello di sicurezza. In particolare Sqrrl fornisce
servizi avanzati per la ricerca e la protezione contro malware, attacchi informatici e
utilizza analisti per l’individuazione di minacce che eludono i tradizionali sistemi di
sicurezza [13].
26
Conclusione
In questo elaborato di laurea sono stati presentati i database NoSQL esaminando i
motivi che hanno portato alla nascita del movimento NoSQL. Successivamente è stata
fatta
una
classificazione
dei
database
enunciando
le
caratteristiche
che
contraddistinguono ogni famiglia NoSQL e come vengono implementati e inoltre è
stata fatto un confronto con i database SQL esponendo i pregi e i difetti di ognuna delle
due categorie di database. Infine è stato esaminato nel dettaglio il database Apache
Accumulo descrivendo la storia e le motivazioni che hanno portato alla creazione di
questo database da parte dell’NSA e analizzando le componenti e le sue funzioni.
In conclusione Apache Accumulo è un database le cui funzioni sono incentrate sulla
sicurezza garantendo sicurezza e privacy dei dati e permettendo di poter strutturare i
dati salvati in più categorie così da limitare l’accesso ai dati. Queste caratteristiche
rendono Apache Accumulo uno dei database migliori nell’ambito dei Big Data dove
la prerogativa fondamentale è la sicurezza dei dati.
27
Bibliografia
[1]
http://www.strozzi.it/cgi-bin/CSA/tw7/I/en_US/NoSQL/Home%20Page
[2]
https://www.0x90.it/capire-i-database-sql-e-nosql/
[3]
https://www.digitalocean.com/community/tutorials/understanding-sql-andnosql-databases-and-different-database-models
[4]
Nancy Lynch and Seth Gilbert, “Brewer’s conjecture and the feasibility of
consistent, available, partition-tolerant web services”, ACM SIGACT News, Volume
33 Issue 2 (2002), pg. 51-59. [5]
[6]
http://www.mokabyte.it/2011/03/nosql-1/
http://www.pcworld.com/article/2060060/nsas-accumulo-nosql-store-offersrolebased-data-access.html
[7]
https://hadoop.apache.org/docs/r1.2.1/hdfs_design.html
[8]
https://zookeeper.apache.org
[9]
https://accumulo.apache.org/1.7/accumulo_user_manual#_components
[10] https://accumulo.apache.org/features/
[11] https://github.com/jaredwinick/Trendulo
[12] http://www.cloudera.com/products/apache-hadoop/apache-accumulo.html
[13] https://github.com/jaredwinick/Trendulo
28
