Scuola Politecnica e delle Scienze di Base
Corso di Laurea in Ingegneria Informatica
Elaborato finale in Basi di Dati
Big Data e Tecnologie NoSQL: AllegroGraph
Anno Accademico 2014/2015
Candidato:
Maria Amodeo
matr. N46001256
Alla mia famiglia e
a Lia,
a cui devo molto.
Indice
Indice .................................................................................................................................................. III
Introduzione ......................................................................................................................................... 4
Capitolo 1: Big Data ............................................................................................................................ 6
1.1 Definizione e caratteristiche: le quattro V dei Big Data ............................................................ 6
1.2 Vantaggi dei Big Data ................................................................................................................ 7
1.3 Limiti dei Big Data .................................................................................................................... 8
Capitolo 2: Tecnologie NoSQL ......................................................................................................... 10
2.1 Teorema CAP e proprietà BASE ............................................................................................. 10
2.2 Vantaggi e svantaggi ................................................................................................................ 12
2.3 Categorie di database NoSQL .................................................................................................. 13
Capitolo 3: AllegroGraph................................................................................................................... 16
3.1 Caratteristiche generali ............................................................................................................ 17
3.2 Funzionalità avanzate ............................................................................................................... 18
3.2.1 Primitive geospaziali e temporali .......................................................................................... 19
3.3 Indicizzazione .......................................................................................................................... 19
3.4 Esempio applicativo ................................................................................................................. 21
3.4.1 Gruff ...................................................................................................................................... 21
3.4.2 Realizzazione query attraverso l’uso della query view ......................................................... 22
Conclusioni ........................................................................................................................................ 28
Bibliografia ........................................................................................................................................ 29
Introduzione
Se si cerca l’etimologia del termine informazione ci si accorge che deriva dal termine latino
informatio che vuol dire nozione, idea, rappresentazione. Trasmettere un’informazione, e di
conseguenza l’azione dell’informare, consiste nel dare forma a qualcosa, sia essa un’idea o un
concetto. Fin dai tempi più antichi si è sentita l’esigenza di trascrivere e memorizzare dati e
informazioni per poterli visionare in futuro ed averne traccia. Basti pensare che le più
straordinarie invenzioni che sono state realizzate nel corso degli anni, dall’evoluzione dei
linguaggi, alla progettazione e realizzazione di strumenti e macchine potenti, tra cui gli stessi PC,
in grado di facilitare il lavoro dell’uomo, sono state quelle che hanno fatto sì che le persone
potessero comunicare, scambiandosi informazioni e memorizzandole. Negli ultimi anni, tuttavia,
grazie anche allo sviluppo di nuove tecnologie, il volume di dati prodotto dai social networks,
dalle reti di sensori, dalle trascrizioni delle transazioni di acquisto e da tanti altri mezzi, continua
a crescere in maniera esponenziale e ha raggiunto ormai livelli enormi. Essendo i dati presenti in
in tutte le organizzazioni e le economie, queste enormi quantità di dati, che prendono a buon
ragione il nome di Big Data, interessano i leader di tutti i settori e collegare e relazionare insieme
questi zettabyte di dati di ogni tipo che provengono da fonti diverse, che vanno da Facebook a
Twitter, da sistemi operativi a cellulari, possono offrire grandi vantaggi alle aziende che li
posseggono. Potranno, infatti, migliorare i rapporti con i loro clienti e capire le loro esigenze,
rispondere a richieste specifiche e accelerare i tempi di consegna; tuttavia, l’utilizzo dei
tradizionali database relazionali non è adatto ad immagazzinare questa mole di informazione, nè
tantomeno a garantire un’elevata velocità di analisi. La nascita e lo sviluppo delle tecnologie
NoSQL ha permesso la gestione efficace di grandi quantità di dati, grazie a database flessibili e
soprattutto scalabili che garantiranno velocità di elaborazione anche di terabyte e terabyte di dati,
4
la scalabilità orizzontale con l’aggiunta di nuovi server e la possibilità di gestire dati anche non
strutturati, non essendoci dipendenza da schemi fissi. Diverse sono le tipologie di DBMS
NoSQL, ognuna con le sue caratteristiche e funzionalità: dai database in cui vengono
memorizzate le coppie chiave-valore a un modello basato su strutture a grafi, da database
orientati ai documenti a quelli orientati alle colonne. La scelta dell’utilizzo di un database
piuttosto che un altro dipende dalle problematiche che si vogliono risolvere e studiare e in base a
ciò si sceglierà la tipologia che meglio soddisfa le nostre esigenze. In particolare, in questo
elaborato, verrà analizzato uno dei database a grafi che si sta sviluppando negli ultimi anni:
AllegroGraph. Ne verranno descritte le caratteristiche e funzionalità principali e, infine, verrà
presentato un esempio di utilizzo svolto in laboratorio.
5
Capitolo 1: Big Data
La quantità di dati che oggi viene prodotta in tutto il mondo è in enorme crescita:
aziende che raccolgono migliaia di miliardi di byte di informazioni sui loro clienti e
sui loro fornitori, in modo tale da tener traccia delle loro operazioni e da fare
statistiche e previsioni relativamente al proprio mercato; milioni di sensori, presenti in
diversi dispositivi, quali cellulari e automobili, che rilevano e trasferiscono
informazioni sotto forma di dati; adulti e ragazzi che scambiano dati attraverso
smartphones e social network, e l’elenco potrebbe continuare.
I Big Data, grandi quantità di dati che possono essere memorizzati e analizzati,
caratterizzano pertanto ogni settore dell’ambiente e dell’economia globale. Tutto
questo è reso possibile grazie allo sviluppo di nuove tecnologie e a persone che per
comunicare e memorizzare informazioni utilizzano sempre più dispositivi digitali.
1.1 Definizione e caratteristiche: le quattro V dei Big Data
Come suggerisce il nome, i Big Data rappresentano un insieme di dati di grandi
dimensioni la cui stima è variabile, a
causa della necessità di analizzare i dati
in un unico insieme, con l’obiettivo di
ricavarne informazioni maggiori.
Le caratteristiche dei Big Data possono
essere racchiuse nelle quattro V che li
6
caratterizzano:
Volume: indica la dimensione effettiva del dataset e si riferisce alla capacità di
memorizzare e accedere a grandi quantità di dati (fino all’ordine dei Zettabyte,
ovvero miliardi di Terabyte).
Questa grande quantità di dati dipende dal fatto che le fonti di provenienza sono
eterogenee, quindi non avremo solo dati strutturati ma anche non strutturati e ciò è
rappresentato dalla seconda caratteristica: la varietà;
Varietà: i dati che costituiscono questo unico grande insieme appartengono a
tipologie differenti; sono presenti, infatti, dati che provengono da sensori o da altri
tipi di dispositivi e vengono trasmessi sotto forma di immagini, documenti, e-mail,
suoni, video. Avremo perciò dati non strutturati che non sono gestibili con sistemi
“tradizionali”, ma sarà necessario introdurre nuove tecnologie per l’analisi di tali
dati;
Velocità: fa riferimento alla velocità di generazione dei dati, la cui analisi deve
avvenire quasi in tempo reale. Questo permette, ad esempio, di individuare una
tendenza prima di chiunque altro e sfruttare a proprio favore le informazioni
ottenute, traendone vantaggi competitivi ed economici;
Veridicità: essere sicuri dell’affidabilità dei dati è fondamentale per poterli utilizzare
come fonte di valore e di profitto. Per effettuare scelte e ricavarne vantaggi,
bisogna analizzare dati che siano affidabili, perciò solo la qualità di questi ultimi
permette di avere idee innovative e fa sì che siano un vero e proprio valore per
coloro che li analizzano.
1.2 Vantaggi dei Big Data
Sebbene molti cittadini possano vedere questa raccolta di informazioni con molto
sospetto, considerando questa divulgazione dei propri dati come un’intrusione nella
loro privacy, i Big Data hanno avuto un’enorme e rapida diffusione grazie ai numerosi
vantaggi offerti:
o Trasparenza: rendendo questi dati accessibili in maniera tempestiva a coloro che
7
sono interessati a ricavarne informazioni, si può avere un enorme vantaggio. Ad
esempio, nel settore manifatturiero, integrando i dati provenienti da diverse unità di
produzione, è possibile ridurre i tempi di produzione ed aumentarne la qualità;
o Effettuare degli esperimenti per migliorare le prestazioni: analizzando i dati a
disposizione, le varie organizzazioni possono raccogliere informazioni dettagliate
e utilizzare questi dati per verificare la variabilità delle prestazioni effettuando una
scelta piuttosto che un’altra, in modo tale da incrementare le perfomance;
o Sostituzione/supporto delle decisioni umane con algoritmi automatizzati: analisi
sofisticate possono migliorare in maniera sostanziale il processo decisionale,
scoprendo informazioni preziose. Ciò può essere fatto anche in maniera automatica
attraverso algoritmi in modo tale da ottimizzare tali processi come la messa a punto
automatica di inventari e prezzi;
o Innovazione con nuovi modelli di business, prodotti e servizi: le aziende possono,
attraverso i Big Data, creare nuovi prodotti e servizi, migliorare quelli esistenti e
inventare modelli di business completamente nuovi. L’emergere di dati di
localizzazione in tempo reale ha creato una serie completamente nuova di servizi
basati sulla posizione, come servizi di assicurazione per infortuni in base a dove e
come le persone guidano la propria auto.
1.3 Limiti dei Big Data
Come ogni cosa, anche i Big Data presentano limiti e problemi.
Possiamo avere problemi di affidabilità della sorgente dei dati o di qualità stessa dei
dati (correttezza, aggiornamento del dato), problemi di consistenza nel caso in cui
abbiamo contraddizioni tra i vari dati e limiti soprattutto per quanto riguarda la
gestione dei Big Data stessi.
A causa delle grandi dimensioni dei dati e della varietà degli stessi, non è possibile
8
gestire i Big Data attraverso i “tradizionali” RDBMS1, i quali non garantiscono
velocità di analisi e archiviazione di grandi quantità di dati.
I RDBMS, inoltre, gestiscono in modo efficiente informazioni che sono fortemente
strutturate, ma all’interno dei Big Data sono presenti immagini e video digitali, dati
GPS e tanti altri che rientrano nella categoria di dati non strutturati e che non sono
gestibili attraverso i sistemi per la gestione di basi di dati relazionali.
A supporto dei Big Data, sono nate tecnologie “specifiche” in grado di andare oltre
questi limiti; esse fanno uso di sistemi scalabili, che rispondono in maniera veloce e
precisa e che riescono a gestire grandi quantità di dati in modo tale da estrapolare
informazioni preziose.
Queste tecnologie sono note come Tecnologie NoSQL.
1
Il Relational Database Management System (RDBMS) è un sistema di gestione di basi di dati basato sul modello
relazionale, il quale è strutturato intorno al concetto di relazione matematica (detta anche tabella).
9
Capitolo 2: Tecnologie NoSQL
Con il termine NoSQL si fa riferimento alla nuova famiglia di database, sviluppatasi
negli ultimi anni, che si discosta dalla famiglia di database relazionali, garantendo alti
livelli di disponibilità dei dati nonché elevata velocità di recupero.
Il termine venne utilizzato per la prima volta nel 1998 da Carlo Strozzi per far
riferimento a una base di dati relazionale open source che non usava un’interfaccia
SQL. Infatti, NoSQL è l’acronimo di Not Only SQL, pertanto non si oppone
all’utilizzo di database relazionali, come si potrebbe pensare, ma va oltre; verranno
utilizzati laddove i tradizionali database relazionali non sono in grado di gestire
efficientemente i dati.
Il termine fu successivamente ripreso da Eric Evans, nel 2009, per far riferimento al
crescente numero di database non relazionali e distribuiti che si stavano sviluppando e
che erano caratterizzati dalle cosiddette proprietà base (BASE) introdotte da Eric
Browers, anche autore del Teorema CAP.
2.1 Teorema CAP e proprietà BASE
Il Teorema CAP afferma che per un sistema informatico distribuito è possibile che si
verifichino, contemporaneamente, al massimo solo due delle seguenti garanzie:
Coerenza: tutti i nodi vedono gli stessi dati nello stesso momento. Un sistema,
infatti, è definito completamente coerente se garantisce che, memorizzato un
nuovo stato del sistema, per ogni operazione successiva, prima di un nuovo
cambiamento dello stesso, verrà utilizzato sempre questo stato;
10
Disponibilità: la garanzia che ogni richiesta riceva sempre una risposta;
Tolleranza di partizione: il sistema continua a funzionare nonostante il
partizionamento della rete e una serie di fallimenti o perdite di messaggi. Il
singolo nodo non causerà il collasso di un intero sistema.
Quindi, sebbene sia auspicabile per un sistema distribuito avere contemporaneamente
totale coerenza, disponibilità e tolleranza alle partizioni, ciò non è possibile e di volta
in volta bisogna scegliere quale garanzia sacrificare rispetto alle altre due in base ai
requisiti richiesti.
Se ad esempio, viene sacrificata la coerenza potrà accadere, in alcuni casi, che un
partizionamento generi disallineamento tra le repliche dei dati e nello stesso momento
ogni nodo avrà una visione diversa degli stessi. Tuttavia, questo non significa che il
sistema non è consistente ma solo che in alcuni casi potrebbe non esserlo, ossia
garantisce una consistenza “debole”. Se rinunciamo alla disponibilità, invece, abbiamo
coerenza e tolleranza alle partizioni però non abbiamo disponibilità nel caso in cui un
nodo fallisca. Infine, se si sceglie di non avere tolleranza alle partizioni, ciò che
accade nei database relazionali dove i dati vengono memorizzati su un’unica macchina
per evitare partizionamenti, avremo problemi di scalabilità, in quanto sarà possibile
scalare soltanto in verticale, e non in orizzontale, e ciò è molto più costoso.
Quindi, in base alla garanzia da sacrificare, abbiamo tre tipi di sistemi: CA, CP e AP. I
sistemi tradizionali relazionali rientrano in quelli di tipo CA in quanto non tollerano
perdite di messaggi.
11
Rispettando tale teorema, i nuovi sistemi dovranno soddisfare le cosiddette
caratteristiche BASE:
o Basically Available: il sistema deve garantire la disponibilità delle
informazioni, anche se i dati possono trovarsi in uno stato inconsistente o
cambiare;
o Soft State: lo stato del sistema può cambiare nel tempo anche in assenza di
input; non deve garantire la consistenza dei dati in ogni istante;
o Eventual Consistency: il sistema, alla fine, quando non ci saranno più
aggiornamenti, dovrà diventare consistente: tutti i nodi otterranno l’ultima
versione del dato in questione. Le inconsistenze sono dunque transitorie.
2.2 Vantaggi e svantaggi
A differenza dei database relazionali, nei database di tipo NoSQL i dati possono essere
conservati in documenti, pertanto un’applicazione che dovrà analizzare le
informazioni, si troverà ad analizzare un unico documento in cui sono raccolti tutti i
dati di cui ha bisogno e le informazioni correlate risulteranno perciò raggruppate e non
distribuite in differenti strutture logiche. Non utilizzando tabelle, questi database non
richiedono uno schema fisso (schemaless), ciò permette loro di incapsulare nuovi tipi
di dati, compresi quelli non strutturati.
L’assenza di schema definito a priori permette a questi database di scalare
orizzontalmente, utilizzando un comune hardware da aggiungere ai propri sistemi, il
ché non è possibile ai RDBMS, che per conservare un numero di dati sempre
maggiore, scalano in verticale, aumentando i costi dell’hardware sottostante, dovendo
quest’ultimo essere sempre più performante. Inoltre grazie al fatto di raggruppare i
dati in un unico documento, i database non relazionali evitano spesso le operazioni di
unione (join) ottenendo così una maggiore leggerezza computazionale. Nel caso dei
database relazionali, la complessità computazionale aumentava al crescere dei dati,
delle tabelle e delle informazioni da trattare a causa delle numerose operazioni di
12
aggregazione che occorreva fare per raccogliere le informazioni desiderate. Nei
database di tipo NoSQL ciò non è necessario e abbiamo perciò un vantaggio sulle
prestazioni e sulle performance.
Di contro, tra i problemi emergenti abbiamo la duplicazione delle informazioni a
causa dell’elevata flessibilità e della proprietà di aggregazione, tuttavia questo
problema non è così rilevante, grazie alla continua diminuzione dei costi dei sistemi di
memorizzazione.
Inoltre si ha la mancanza di uno standard per l’accesso ai dati e di strumenti di
ottimizzazione per l’interrogazione e l’implementazione di nuovi tipi di dati. A
differenza dei RDBMS, dove i risultati delle richieste fatte attraverso query possono
essere visualizzati in ambienti standard e un database creato in un determinato
ambiente può interfacciarsi con un altro RDBMS, per i sistemi NoSQL ogni
realizzazione ha la sua interfaccia utente e manca uno standard universale, essendo
questi database molto diversi tra loro (ognuno ha le proprie API, il suo metodo di
storing e accesso ai dati). Pertanto se interrompessimo lo sviluppo di un database sul
quale si basa il nostro applicativo, il passaggio ad un altro database richiederebbe delle
modifiche più o meno radicali da apportare al nostro applicativo e ciò richiederebbe
tempo e lavoro.
Infine, la semplicità di questi database ha comportato l’assenza di controlli
fondamentali per l’integrità dei dati. Sarà compito dell’applicativo effettuare
controlli sui dati che appartengono al database con il quale sta dialogando.
2.3 Categorie di database NoSQL
In base al tipo di modello adottato, possiamo raggruppare i database NoSQL in quattro
grandi famiglie:
Columnfamily;
Key/Value;
Document Oriented;
13
Graph-based.
I database di tipo columnfamily possono apparire, a prima vista, molto simili ai
database relazionali, ma dopo un’attenta analisi ci si accorge che in realtà si
differenziano da questi ultimi in maniera sostanziale. Innanzitutto, in questi database i
dati vengono memorizzati per colonna e non per riga, come accadeva nei database
relazionali. Le righe possono essere viste come un insieme di colonne e una singola
riga, in un database columnfamily, può contenere diverse colonne. Le colonne
correlate tra loro, che contengono la stessa tipologia di informazione, vengono
raggruppate in columnfamily e il vantaggio principale è che le colonne che le
costituiscono non devono essere definite a priori, possono perciò essere aggiunte se
necessarie o rimosse se inutilizzate. La flessibilità delle columnfamily permette alle
applicazioni di eseguire query complesse e analisi dei dati, simile, per molti aspetti,
alla funzionalità offerta dai database relazionali. Sono progettati, inoltre, per contenere
grandi quantità di dati (centinaia di milioni o miliardi di righe contenenti centinaia di
colonne) e per fornire un accesso rapido a questi dati correlati tra loro. Rispetto ad un
database relazionale che contiene un volume equivalente di dati, un database di questo
tipo sarà più veloce e più scalabile; grazie alla sua flessibilità, questo modello viene
molto utilizzato nel campo dei Big Data e siti web a traffico elevato.
Nei database di tipo Key/Value i dati vengono memorizzati in coppie chiave-valore,
dove la chiave permette di accedere ai dati (solitamente tipi primitivi, come numeri
interi e stringhe) e il valore rappresenta i dati veri e propri a cui si vuole accedere.
Questo modello risulta essere quello più semplice e riesce a garantisce un’elevata
scalabilità orizzontale, grazie all’assenza di legami tra le varie coppie, che potranno
essere distribuite su server differenti. Anche le ricerche nel database possono essere
fatte in maniera parallela (con funzioni come Map e Reduce), garantendo in questo
modo un’elevata concorrenza e disponibilità di informazioni, a sfavore della
consistenza dei dati. Inoltre alcuni database memorizzano i dati in memoria (RAM),
mentre altri garantiscono la persistenza dei dati impiegando unità a stato solido (SSD)
o dischi rotanti.
14
I database di tipo Document Oriented vengono progettati intorno alla nozione di
documento: i dati non sono memorizzati in tabelle con campi uniformi per ogni record,
ma questi ultimi vengono memorizzati come documenti, ognuno con le proprie
caratteristiche; ad ogni documento è possibile aggiungere un certo numero di campi
con lunghezze anche differenti in modo tale da non avere campi vuoti all’interno dei
documenti. I documenti incapsulano e codificano i dati e le informazioni secondo
alcuni standard, come XML, JSON. Questi documenti possono essere individuati,
all’interno della base dati, attraverso una chiave univoca (tipicamente il database
possiede un indice delle chiavi per velocizzare il recupero dei documenti) e, nei
sistemi più moderni, è possibile recuperare i documenti anche in base al loro
contenuto, attraverso un linguaggio di query o API che variano significativamente da
un’implementazione all’altra. Perciò i database di tipo Document Oriented possono
essere visti come un’evoluzione di quelli Key/Value: essi avranno i vantaggi del
modello Key/Value ma non si è limitati ad effettuare interrogazioni solo attraverso la
chiave.
Nei database di tipo Graph-Based, invece, i dati vengono memorizzati sotto forma di
grafi, ossia come un insieme di nodi e archi, rappresentanti le relazioni tra i dati.
Questo modello di database è stato introdotto, infatti, proprio per le applicazioni dove
le informazioni sull’interconnessione dei dati sono importanti quanto i dati stessi.
Rispetto ai database relazionali sono più veloci nell’associazione dei dati, scalano
molto facilmente permettendo di memorizzare grandi quantità di dati, non utilizzano
operazioni di join e sono adatti a gestire dati mutevoli. Le relazioni tra i nodi sono
utilizzate, ad esempio, dall’operazione di attraversamento (graph traversal), che
stabilisce come passare da un nodo all’altro e ciò può essere utile in applicazioni
complesse, che contengono numerosi dati interconnessi, come i social networks. Tra i
database di tipo graph-based analizzeremo, di seguito, AllegroGraph.
15
Capitolo 3: AllegroGraph
AllegroGraph, realizzato da Franz Inc., è un database di tipo graph-based ed è alla base
di molte applicazioni del Semantic Web2. E’ in grado di memorizzare i dati sotto
forma di triple ed effettua interrogazioni attraverso diversi linguaggi come SPARQL e
Prolog3. Le informazioni vengono quindi memorizzate secondo il modello di dati di
tipo RDF4, che si basa sull’idea di raggruppare le informazioni sotto forma di
espressioni del tipo soggetto-predicato-oggetto; in realtà anche se si è soliti parlare di
triple, ogni asserzione ha cinque campi:
Soggetto
Predicato
Oggetto
Grafo
Triple-id
I primi quattro campi sono stringhe di dimensione arbitraria, l’ultimo campo
rappresenta l’identificatore della tripla. E’ possibile rappresentare ciascuna struttura a
grafo considerando i soggetti e gli oggetti come nodi, mentre i predicati
2
Il Semantic Web rappresenta un’evoluzione del World Wide Web, in quanto si cerca di dare ai dati presenti sul web
un “significato”, in modo da poterli identificare e mettere in relazione. In questo modo, nuove possibilità di analisi e di
navigazione dei dati verranno fornite all’utente che vuole effettuare una ricerca.
3
SPARQL(Simple Protocol And RDF Query Language) è un linguaggio di interrogazione e recupero dei dati espressi
in RDF. Prolog è un linguaggio di programmazione che adotta il paradigma di programmazione logica.
4
Il Resource Description Framework (RDF) è lo strumento base proposto da WC3 (World Wide Web Consortium),
organizzazione non governativa internazionale che ha come scopo quello di sviluppare tutte le potenzialità del World
Wide Web, per la codifica, lo scambio e il riutilizzo di metadati strutturati e consente l’interoperabilità tra applicazioni
che condividono le informazioni sul Web. Lo statement permette di rappresentare un’informazione in RDF ed è una
tripla del tipo Soggetto-Predicato-Oggetto, dove il soggetto rappresenta una risorsa, il predicato rappresenta una
proprietà e l’oggetto un valore.
16
identificheranno i collegamenti tra i vari nodi; in questo modo avremo una tripla per
ciascun collegamento e il campo grafo permetterà di conservare delle informazioni
aggiuntive. Quindi, anche se utilizza un modello di dati di questo tipo, nulla vincola
AllegroGraph al mondo dell’RDF e potrà, perciò, essere considerato un vero e proprio
database grafico.
Per velocizzare le query, sono stati introdotti degli indici che contengono non solo le
asserzioni ma anche informazioni aggiuntive ed, inoltre, si tiene traccia anche delle
triple cancellate. Per molte applicazioni, come tutti i database grafici, può essere più
veloce e flessibile dei tradizionali database relazionali grazie al fatto che tutto è
indicizzato ed è possibile aggiungere nuovi predicati senza cambiare nessuno schema.
3.1 Caratteristiche generali
AllegroGraph dà la possibilità di manipolare i dati attraverso diverse interfacce e
linguaggi, come Java e Lisp e caricare grandi quantità di dati di tipo N-Triples5,
RDF/XML6, Turtle7 e altri formati. In aggiunta, supporta una vasta gamma di tipi di
dati codificati come numeri, date e coordinate geospaziali; l’utilizzo di questi tipi di
dati, non solo riduce la dimensione del triple store8, in quanto i dati che formano la
stringa non devono essere salvati, ma permette di realizzare inoltre delle query molto
veloci e di tipo geospaziale.
AllegroGraph, infatti, costruisce gli indici automaticamente in modo da velocizzare
l’esecuzione delle query. E’ possibile abbreviare i tipi di indici utilizzando s per il
soggetto, p per il predicato e così via. Ciò che conta è il criterio di ordinamento delle
triple, ad esempio per l’indice spogi avremo prima il soggetto, poi il predicato,
l’oggetto, il grafo e infine l’id.
5
Le triple N-Triples sono una sequenza di termini RDF che rappresentano il soggetto, il predicato e l’oggetto di una
tripla RDF. Ogni sequenza termina con un “.”.
6
RDF/XML è una sintassi che viene utilizzata per rappresentare un grafo RDF come un documento XML.
7
Un documento Turtle è una rappresentazione testuale di un grafo RDF, costituito da triple Soggetto-PredicatoOggetto.
8
Un triple store è un database realizzato per la memorizzazione e il recupero di triple RDF. Sarà poi possibile
recuperare le informazioni memorizzate attraverso un linguaggio di query, ad esempio SPARQL.
17
E’ possibile che vengano memorizzate triple duplicate, perché ad esempio due utenti in
maniera indipendente creano la stessa tripla. Dato che, triple duplicate riducono
l’efficienza del sistema, viene messa a disposizione una funzione che permette di
eliminare triple identiche. Questa funzione, delete-duplicate-triples, ci permette di
specificare cosa intendiamo per triple identiche, perché possono essere uguali se hanno
lo stesso soggetto, predicato, oggetto, grafo così come possiamo ritenerle identiche se
hanno lo stesso soggetto, predicato e oggetto, ignorando il grafo.
3.2 Funzionalità avanzate
AllegroGraph supporta diversi tipi di dati specializzati per la memorizzazione
efficiente, manipolazione e ricerca di informazioni dei Social Network, geospaziali e
temporali. Visualizzando interazioni come le connessioni in un grafo, possiamo
trattare un gran numero di situazioni diverse utilizzando strumenti messi a disposizione
dal Social Network Analysis (SNA). SNA ci permette di rispondere a domande come:
Quanto strettamente sono connessi due individui tra loro?
Quali gruppi possiamo individuare all’interno dei dati?
Quanto è importante una determinata persona (o società) per il flusso di
informazioni?
Quante probabilità ci sono che due persone si conoscano?
Il campo è pieno di tecniche matematiche e potenti algoritmi per rispondere a tali
18
domande e gli strumenti messi a disposizione da AllegroGraph comprendono una serie
di metodi di ricerca e strumenti per misurare la centralità e l’importanza dei vari
individui.
3.2.1 Primitive geospaziali e temporali
AllegroGraph fornisce un nuovo meccanismo per la memorizzazione e per il recupero
di dati multi-dimensionali, in particolare per i dati di localizzazione. Anche se spesso
ci riferiamo a questi tipi di dati con “geospaziali”, questo termine in realtà si riferisce
specificamente a posizioni o ad un intorno della superficie terrestre. AllegroGraph,
invece, supporta una nozione più generale di sistemi ad ordinate di tipo
N-dimensionale, rappresentanti ad esempio la latitudine, la longitudine, l’altitudine, il
tempo, ecc., che potrebbero essere utilizzati in campi di tipo non-geo, come la
produzione di semiconduttori (ad es. la superficie di un chip di silicio) e la biologia.
Sebbene non vi sia alcun limite rigido nel numero di dimensioni, in pratica non si
utilizzano più di 5 o 6 dimensioni.
AllegroGraph permette, inoltre, il recupero e l’archiviazione di dati temporali, oltre
che spaziali, come istanti di tempo, intervalli di tempo, data e ora; una volta che i dati
sono stati codificati, le applicazioni possono eseguire query sulla base di un’ampia
gamma di vincoli temporali sui dati, includendo relazioni come:
due istanti
due intervalli
istanti e intervalli
istanti e date
intervalli e date
3.3 Indicizzazione
AllegroGraph utilizza un insieme di indici ordinati per identificare rapidamente un
blocco contiguo di triple e sono caratterizzati da nomi che ne descrivono
19
l’organizzazione; il set predefinito di indici a disposizione sono spogi, posgi, ospgi,
gspoi, gposi, gospi e i, dove:
S sta per l’URI9 soggetto;
P sta per l’URI predicato;
O sta per l’URI oggetto o letterale;
G sta per l’URI che rappresenta il grafico;
I sta per l’identificatore della tripla.
Questi sette indici standard sono disponibili quando si crea un triple store, ma è anche
possibile eliminare gli indici che l’applicazione non userà e realizzare indici
personalizzati.
L’ordine delle lettere indica come un indice è organizzato, ad esempio l’indice spogi
contiene tutte le triple ordinate prima per soggetto, poi per predicato, oggetto e infine
per grafo, l’identificativo è presente come quinta colonna dell’indice. Se il soggetto è
noto, questo indice ci permetterà di trovare tutte le triple che hanno quel determinato
valore come soggetto, raggruppate in un blocco. Questo blocco è ulteriormente
ordinato secondo il predicato, in modo tale che se il valore del predicato è noto,
possiamo immediatamente ridurre le possibili corrispondenze a un piccolo insieme di
triple, di solito a una sola tripla. Per cui questo tipo di indice verrà utilizzato quando è
noto il soggetto, o sono noti soggetto e predicato, o soggetto predicato e oggetto, o
soggetto predicato oggetto e grafo.
L’indice posgi verrà utilizzato per ricercare soggetti ignoti, quando il predicato e
l’oggetto sono specificati, così come ci si servirà dell’indice ospgi se è noto il valore
dell’oggetto, attraverso il quale si potrà ricavare il corrispondente soggetto e predicato.
Gli indici basati sul grafo gspoi, gposi, e gospi vengono utilizzati quando il triple store
è diviso in sottografi. Se si conosce il sottografo, possiamo isolare tutte le sue triple e
successivamente indicizzare attraverso il soggetto, il predicato o l’oggetto se
necessario. Infine l’indice i ci permette di avere un elenco di tutte le triple ordinate per
9
L’URI, Uniform Resource Identifier, rappresenta una stringa utilizzata per identificare univocamente una risorsa
generica che può essere un indirizzo Web, un documento, un file, ecc.
20
id. Ciò è utile quando si vuole effettuare una cancellazione attraverso l’id della tripla,
infatti attraverso l’id è possibile identificare univocamente una determinata tripla ed
AllegroGraph potrà cancellare la stessa tripla dagli altri indici. Ciò rende più veloce la
cancellazione, dato che senza tale indice avrebbe dovuto analizzare ogni singola linea
per trovare la corrispondenza tra gli id.
3.4 Esempio applicativo
Di seguito verrà riportato un esempio di utilizzo di Allegrograph, realizzato
nell’ambito del progetto SMART HEALTH, il cui obiettivo è realizzare un sistema
tecnologico che permetta di realizzare un nuovo modello di Sanità digitale basato sulla
cooperazione tra le diverse entità della Sanità.
Dopo una prima fase di installazione di AllegroGraph Virtual Machine, è stato
utilizzato Gruff per realizzare query su un file dati ti tipo NTRIPLES.
3.4.1 Gruff
Gruff è un triple-store browser interattivo basato su AllegroGraph, fornisce vari
metodi di interrogazione e permette il recupero dei dati in maniera semplice e veloce
con numerosi strumenti per tracciare grafici, visualizzare tabelle di proprietà dei vari
nodi, gestire e realizzare query come diagrammi visivi. Nella modalità di
visualizzazione grafica, i dati vengono visualizzati sotto forma di nodi e i collegamenti
tra i dati sono rappresentati da archi, in modo tale da avere un “grafico” delle
informazioni che stiamo analizzando, mentre la visualizzazione tabellare permette di
vedere le proprietà di ogni singolo nodo. Per la realizzazione delle query, è possibile
utilizzare query view dove è possibile scrivere query in SPARQL o Prolog e
visualizzare i risultati all’interno di una tabella. I nodi risultanti potranno essere
analizzati in dettaglio passando in modalità table view o aggiungendo i nodi all’interno
del graph view; se si sceglie invece di realizzare query attraverso il graphical query
21
view, la realizzazione delle query risulterà ancora più semplice in quanto sarà possibile
elaborare una query come se fosse un “diagramma”, disegnando nodi ed archi.
3.4.2 Realizzazione query attraverso l’uso della query view
Prima di iniziare con le interrogazioni, è stato realizzato un nuovo Triple-Store e
caricato un file di cartelle mediche contenenti informazioni su vari pazienti, quali le
diete seguite, le diagnosi con cui sono stati dimessi, il tipo di alimentazione, il reparto
nel quale sono ricoverati, la malattia da cui sono affetti, il sesso, l’età, ecc., attraverso
il comando Load N-Triples. Per avere una visione grafica delle triple caricate, grazie al
comando Display Some Sample Triple, è stato possibile vedere graficamente parte dei
nodi e dei collegamenti tra gli stessi:
dove i link di collegamento hanno colori diversi in base alle proprietà che
rappresentano. Per poter effettuare delle query sulle 12368 triple caricate, verrà
utilizzata la modalità query view e scelto come linguaggio di interrogazione SPARQL.
22
1.Supponiamo di voler sapere per ogni paziente l’intervento subito.
All’interno della query avremo perciò come variabili il paziente e l’intervento, che
saranno contrassegnate con un punto interrogativo:
La select definisce le variabili da prendere in considerazione nel risultato; la where
definisce il criterio di selezione specificando tra parentesi graffe un “triple pattern”,
mentre limit pone un limite superiore al numero di risultati restituiti, in questo caso
vengono mostrati solo i primi 100. Eseguendo la query con Run Query, l’elenco di tutti
i pazienti con i relativi interventi verrà mostrato all’interno di una tabella:
E’ possibile avere una vista grafica dei risultati cliccando su Create Visual Graph e
ottenendo l’insieme dei nodi dei pazienti collegati ognuno al nodo intervento subito;
nell’immagine riportata di seguito sono presenti i pazienti che hanno subito
l’asportazione dell’appendice, l’appendicectomia:
23
2.Nel caso in cui si vuole effettuare una query più specifica, ad esempio si vogliono
conoscere i pazienti che soffrono di uno specifico disturbo, ad esempio l’inappetenza,
allora sarà necessario introdurre una sola variabile (paziente):
e come risultato avremo in questo caso solo l’elenco dei pazienti che soffrono di
inappetenza:
24
Dal punto di vista grafico, rispetto al caso precedente, avendo fatto una selezione,
avremo un minor numero di nodi:
Per avere informazioni dettagliate, è possibile visualizzare per ogni singolo nodo tutte
le informazioni possibili ed avere anche informazioni su eventuali altri nodi cliccando
su Table View :
25
Come ultimo esempio, supponiamo di avere due condizioni da voler soddisfare:
3. Si vuole sapere quali sono i pazienti di sesso femminile e quelli che sono stati
dimessi con diagnosi di insufficienza respiratoria.
In questo caso utilizzeremo la parola chiave UNION, che esprime un OR logico: la
query catturerà sia le triple che soddisfano il primo triple pattern, sia quelle che
soddisfano il secondo.
I risultati verranno riportati in tabella:
mentre dal punto di vista grafico avremo:
26
E’ possibile anche memorizzare la query con i relativi risultati contenuti nella tabella
in un file attraverso l’opzione Write Text Report:
Oltre ad essere salvati i risultati ottenuti, abbiamo anche informazioni sulla velocità di
esecuzione della query, in questo caso sono state trovate 100 soluzioni in 0,175
secondi.
27
Conclusioni
In questo elaborato abbiamo analizzato il fenomeno dei Big Data e i motivi per cui
sono stati introdotti database di tipo non relazionale, concentrando particolare
attenzione su uno dei database a grafi, AllegroGraph. Sono state analizzate le
principali caratteristiche e vantaggi di questo moderno e high-performance database,
progettato per avere massima velocità di caricamento e di realizzazione delle query.
Come la maggior parte dei database a grafi, si è sviluppato ed è stato utilizzato
principalmente grazie alle potenzialità legate all’espressività e alla facilità di analisi
nella risoluzione di molteplici problemi e alla velocità nell’associazione di insiemi di
dati. Numerose sono ad oggi le aziende e le istituzioni che utilizzano AllegroGraph,
dal campo della Bioinformatica alla Sanità come Mayo Clinic, Merck e Novartis, dal
campo della Difesa come DISA (Defence Information Systems Agency) e ONR
(Office of Naval Research), al campo finanziario come Bank of America e Hoovers,
dal campo governativo come la NASA al campo manifatturiero come Ford e Siemens,
dal campo dei media come Kodak e Adobe al campo delle tecnologie e delle
telecomunicazioni come SAP e KTF e l’elenco è destinato a crescere nei prossimi
anni.
28
Bibliografia
[1]
http://it.wikipedia.org/wiki/Big_data
[2]
http://deloitte.wsj.com/cfo/files/2013/09/TooBigIgnore.pdf
[3]
http://losviluppatore.it/big-data-dalla-teoria-allimplementazione/
[4]
http://it.wikipedia.org/wiki/NoSQL
[5]
http://www.garr.it/eventiGARR/conf10/docs/poster-boraso-conf10.pdf
[6]
http://arxiv.org/ftp/arxiv/papers/1401/1401.2101.pdf
[7]……...http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.67.6951&rep=rep
1&type=pdf
[8]
http://www2.mokabyte.it/cms/article.run?permalink=mb186_BrewerCAP-1
[9]
http://nosql-database.org/
[10]
http://blog.artera.it/programmazione/sql-nosql-database-non-relazionali
[11]
http://franz.com/agraph/allegrograph/
29
