Scuola Politecnica e delle Scienze di Base
Corso di Laurea in Ingegneria Informatica
Elaborato finale in Basi di dati
Graph database: Titan
Anno Accademico 2014/2015
Candidato
Stefano Zannini
matr. N46/1058
Ai miei genitori,
al mio amore Roberta,
ai miei fratelli,
alla famiglia tutta,
ai miei amici.
Indice
Indice .................................................................................................................................................. III
Introduzione ......................................................................................................................................... 4
Capitolo 1: Cenni sui database NoSQL ............................................................................................... 6
1.1 - I DBMS NoSQL ...................................................................................................................... 6
1.2 - Teorema di CAP ...................................................................................................................... 7
1.3 - Panoramica dei NoSQL ........................................................................................................... 7
1.4 - Vantaggi e svantaggi di un NoSQL database .......................................................................... 9
Capitolo 2: Graph database ................................................................................................................ 10
2.1 - Graph database: cosa sono? ................................................................................................... 10
2.2 - Elementi di teoria dei grafi .................................................................................................... 10
2.3 - Potenzialità dei Graph DB ..................................................................................................... 11
2.4 - Relazioni tra RDBMS e Graph DB ....................................................................................... 12
2.5 - La Modellazione di un Grafo ................................................................................................. 14
Capitolo 3: Titan ................................................................................................................................ 15
3.1 - Titan: cos’è?........................................................................................................................... 15
3.2 - Benefici di Titan con Cassandra ............................................................................................ 16
3.3 - Benefici di Titan con HBase .................................................................................................. 17
3.4 - Titan e il teorema di CAP ...................................................................................................... 17
3.5 - TinkerPop e Gremlin Shell .................................................................................................... 18
3.6 - Panoramica sull’architettura di Titan..................................................................................... 19
Capitolo 4: Esempio di un Graph DB con Titan ................................................................................ 21
4.1 - Grafo degli dei ....................................................................................................................... 21
4.2 - Comandi principali della Shell Gremlin ................................................................................ 22
4.3 - Indici del Grafo ...................................................................................................................... 27
4.3.1 - Esempi di Graph traversal .............................................................................................. 27
Bibliografia ........................................................................................................................................ 30
III
Graph database: Titan
Introduzione
Sin dalla nascita dei database, il modello relazionale è stato sicuramente quello di
maggior successo e che meglio ha permesso di rappresentare e strutturare i dati.
Gli RDBMS (Relational Database Management System) consentono di organizzare le
informazioni schematizzandole sotto forma di entità connesse da relazioni. Tuttavia, la
sua natura gli impone che l’organizzazione dei dati segua una serie di vincoli e regole
che non consentono alla struttura di archiviazione di adattarsi a dei cambiamenti
imprevisti. Questi vincoli sono la sua più grande forza e al tempo stesso la causa della
sua debolezza.
Il mondo d’oggi, prima con l’avvento di Internet (inizio degli anni ’90) e poi più
recentemente con l’affermarsi dei Social Network come Facebook e Twitter, è sempre
più connesso e sempre più tipi di informazioni vengono correlate tra loro. Queste ultime
sono sempre meno soggette a quei vincoli che permettevano di definire una struttura di
base alla quale attenersi.
Colossi tecnologici come Google, lo stesso Facebook e tanti altri, hanno un po’
abbandonato la “via del relazionale” per appoggiarsi a diversi tipi di modelli.
In un mondo così altamente connesso e in costante evoluzione non poteva che
verificarsi la nascita di tecnologie di immagazzinamento dei dati capaci di adattarsi a
questa nuova era.
I NoSQL Database (Not Only SQL Database) ed in particolare i Graph Database sono
sicuramente la risposta più forte che è stata data dal mondo dell’informatica al nascere
4
Graph database: Titan
di queste nuove esigenze. Perciò, il modello relazione comincia a vacillare e a perdere il
suo primato di miglior metodo di rappresentazione dei dati, e nuove tecnologie
incominciano a proporsi fortemente come sua alternativa.
Dato che il mondo commerciale è ancora fortemente legato ai database relazionali, e
dato che per ora solo le grandi compagnie possono permettersi di sviluppare ed
effettuare degli studi accurati sui Graph DB, la conoscenza generale che si ha di quest’
ultime tecnologie è ancora scarsa.
In questo elaborato faremo solo un accenno ai DBMS NoSQL, fornendo al lettore una
panoramica sulle loro caratteristiche principali, e le principali tipologie. Verrà
presentato quindi il mondo dei Graph database, illustrando le caratteristiche e i concetti
base di questo nuovo modo di strutturare ed organizzare le informazioni, per poi
soffermarci su un Graph database in particolare: Titan.
5
Graph database: Titan
Capitolo 1: Cenni sui database NoSQL
1.1 - I DBMS NoSQL
Il termine NoSQL fa riferimento a tutti quei modelli che, per la memorizzazione delle
informazioni, non utilizzano il modello relazionale, o che lo utilizzano in maniera non
esclusiva. Si riferisce, dunque, a quei database che vanno oltre l’utilizzo di SQL, cioè
che possono sfruttare anche SQL, ma presentano una struttura più complessa. La
maggior parte dei database NoSQL sono stati sviluppati per funzionare su cluster di
computer, per interagire tra loro in maniera distribuita e orizzontale ed essere tolleranti
agli eventuali fallimenti che potrebbero subire. Spesso questi tipi di DBMS sono
schemaless, ovvero non possiedono uno schema fisso a cui devono attenersi, evitando
quindi le operazioni di JOIN, e puntano a scalare orizzontalmente.
Proprio per questi motivi, i NoSQL DBMS sono contraddistinti dal fatto che non
utilizzano un sistema transazionale ACID, il quale garantisce che ogni transazione
soddisfi le seguenti proprietà:
Atomicity: una transazione è un’unità di elaborazione atomica, indivisibile. Ciò
significa che dovrà essere eseguita totalmente oppure per niente, senza scinderla
in parti più piccole.
Consistency: quando viene lanciata, una transazione trova il database in uno stato
consistente e al suo completamento il database dovrà ancora godere di questa
proprietà.
Isolation: una transazione dovrà essere isolata completamente dalle altre. In caso
6
Graph database: Titan
di fallimento non dovrà interferire con le altre transazioni in esecuzione.
Durability: gli effetti di una transazione che ha terminato correttamente la sua
esecuzione devono essere persistenti nel tempo.
1.2 - Teorema di CAP
Dunque, non si ha più come obiettivo principale quello di garantire le proprietà ACID,
ma si parla di proprietà BASE, in relazione al Teorema di CAP, il quale afferma che è
impossibile per un sistema informatico distribuito fornire simultaneamente tutte e tre le
seguenti garanzie:
Consistency (Coerenza): ogni utente vede in ogni istante la stessa versione del
dato.
Availability (Disponibilità): tutti gli utenti possono sempre leggere e scrivere nel
database.
Partition tolerance (Tolleranza al partizionamento): il sistema lavora bene
nonostante sia fisicamente ripartito nella rete.
Secondo il teorema, un sistema distribuito è in grado di soddisfare al massimo due di
queste garanzie allo stesso tempo, ma non tutte e tre.
Applicando questo teorema ad un sistema che deve rispettare le proprietà BASE, si
osserva che la proprietà sacrificabile è la consistency. Si può trovare, quindi, un
compromesso, tra availability e consistenza, parlando di Latency, che ci indica il limite
di tempo che l’utente è disposto a sopportare per definire un sistema availability.
1.3 - Panoramica dei NoSQL
Le principali categorie di DBMS NoSQL sono:
Key-Value store: i dati vengono immagazzinati in un elemento che contiene una
chiave assieme ai dati veri e propri. Quindi può essere definito come una
semplice hash-table. Questo metodo è il più facile da implementare, ma anche il
più inefficiente se la maggior parte delle operazioni riguardano soltanto una
7
Graph database: Titan
parte di un elemento.
Document-oriented: è l’evoluzione del metodo key/value; rispetto ai normali
database relazionali, invece di immagazzinare i dati in tabelle con dei campi
fissi, questi vengono messi in un documento (rappresentato in XML, JSON o
BSON) che può contenere illimitati campi di illimitata lunghezza.
Column Family Database: le informazioni sono memorizzate in colonne, non in
righe, quindi non supportano l'operazione di join. Tra l’altro non c'è bisogno di
definire subito le colonne. Spesso tali database sono realizzati per consentire
accessi a blog, poiché permettono di inserire attributi multivalore, link, categorie
e tag nelle varie colonne.
Graph DBMS: i dati vengono immagazzinati sotto forma di strutture a grafi,
rendendo più performante l’accesso a questi da applicativi orientati agli oggetti.
Tipicamente si usa nei social network.
Nell’immagine seguente possiamo notare i DBMS NOSQL più noti divisi per categorie:
8
Graph database: Titan
1.4 - Vantaggi e svantaggi di un NoSQL database
I principali vantaggi di un Not Only SQL Database sono i seguenti:
Dato che un elemento contiene tutte le informazioni necessarie non serve usare i
dispendiosi (in termini di performance) JOIN come invece avviene per i database
relazionali.
La semplicità di questi database è uno degli elementi fondamentali: è proprio questo che
permette di scalare in orizzontale in maniera efficiente; molti NoSQL database, infatti,
permettono di aggiungere nodi a caldo in maniera impercettibile all’utente finale.
Scegliendo un database adatto alla mappatura più diretta alle object classes del proprio
applicativo si possono ridurre di molto i tempi dedicati allo sviluppo del metodo di
scambio dati tra il database e l’applicativo stesso.
Logicamente lo sviluppo e l’uso dei NRDBMS comporta anche una serie di piccoli
svantaggi:
La semplicità di questi database porta alla mancanza dei controlli fondamentali
sull’integrità dei dati. Perciò tale compito ricade totalmente sull’applicativo che dialoga
col database, che ovviamente dovrebbe essere testato in modo molto approfondito prima
di essere messo in produzione.
La mancanza di uno standard universale (come può essere SQL) è un altro difetto di
questi modelli. Ogni database ha infatti le proprie API e il suo metodo di storing e di
accesso ai dati. Pertanto, risulta palese che se lo sviluppo del database sul quale si basa
un applicativo venisse interrotto, il passaggio ad un altro database non sarebbe
sicuramente una cosa immediata, ma richiederebbe alcuni cambi più o meno radicali da
apportare all’applicativo stesso.
9
Graph database: Titan
Capitolo 2: Graph database
2.1 - Graph database: cosa sono?
Un Graph Database Management System è un sistema di gestione online che
sottopone un modello dati a grafo, a metodi di Creazione, Lettura, Aggiornamento e
Cancellazione (Create, Read, Update e Delete : CRUD). I Graph DBMS vengono
progettati in modo da ottimizzare le prestazioni e l’integrità delle operazioni
transazionali.
La forza di questo tipo di database è di gestire dati fortemente interconnessi,
permettendo un’operazione molto interessante: l’attraversamento (graph traversal),
che rispetto a una normale query su database key/value, stabilisce come passare da un
nodo all’altro utilizzando le relazioni tra nodi.
2.2 - Elementi di teoria dei grafi
I Graph DBMS, come abbiamo appena detto, organizzano le informazioni sotto forma
di grafo, quindi è utile definire il concetto di Grafo.
Un grafo è una raccolta di vertici e nodi, in parole semplici, è un insieme di nodi
connessi da relazioni. I grafi rappresentano le entità con i nodi, e il modo nel quale
queste entità si rapportano con il mondo, con le relazioni.
Più formalmente, si dice grafo una coppia ordinata G = (V, E) di insiemi, con V insieme
dei nodi ed E insieme degli archi, tali che gli elementi di E siano coppie di elementi di
V. Due vertici u, v connessi da un arco, prendono nome di "estremi dell'arco"; l'arco e
10
Graph database: Titan
viene anche identificato con la coppia formata dai suoi estremi (u, v).
La variante più conosciuta di modello a grafo è rappresentato dal modello property
graph, che presenta le seguenti caratteristiche:
Un grafo contiene nodi e relazioni.
I nodi posseggono delle proprietà (coppie di chiave-valore).
Le relazioni posseggono un nome e sono direzionate, ed hanno sempre un nodo di
partenza e un nodo di arrivo.
Anche le relazioni possono avere delle proprietà.
Sebbene sia semplice, un grafo con queste proprietà può essere usato per
descrivere tutti i tipi di scenari possibili.
2.3 - Potenzialità dei Graph DB
I database a grafo sono spesso più veloci di quelli relazionali nell'associazione di
insiemi di dati, e mappano in maniera più diretta le strutture di applicazioni orientate
agli oggetti. Dipendono meno da un rigido schema entità relazione e sono molto più
adeguati per gestire dati mutevoli con schemi evolutivi. Al contrario, i database
relazionali sono tipicamente più veloci nell'eseguire le stesse operazioni su un grande
numero di dati. I grafi, se da un lato permettono di esprimere concetti molto complessi
in maniera semplice, dall’altro presentano una problematica non trascurabile: non ci
sono tecniche universali abbastanza adeguate che permettono di modellare facilmente
tale struttura rispetto ad un qualsivoglia problema.
In compenso, però, i graph DB offrono un modello dati flessibile e agile che permette
di adattarsi continuamente all’evolversi della realtà. Ecco quelle che sono le loro
potenzialità:
Performance: Uno dei problemi degli RDBMS (Relational Database Management System) è il continuo utilizzo delle operazioni di JOIN, che la natura dei
Graph DB consente di evitare semplicemente attraversando le relazioni che
connettono i nodi. Le performance dei Graph DBMS, quindi, tendono ad essere
11
Graph database: Titan
ottimali quando i dati da archiviare sono altamente connessi e la mole del dataset
è estremamente grande.
Flessibilità: Dato che I graph DBMS sono Schemaless,cioè non posseggono uno
schema prefissato al quale attenersi, si adattano facilmente all’evolversi del
dominio applicativo senza dover rimodellare e convertire l’intera base dati.
Inoltre, l’aggiunta di nuove relazioni e nodi non compromette le interrogazioni
che sono state costruite per la vecchia versione del database.
2.4 - Relazioni tra RDBMS e Graph DB
Per molti decenni, gli sviluppatori hanno provato a sistemare i dati connessi all’interno
del database relazionale e subito vennero mostrate difficoltà nel tentativo di modellare
le relationship del mondo reale. Le relationship esistono nel mondo del database
relazionale, ma solo come rappresentazioni di tabelle accoppiate, ma spesso si ha la
necessità di non avere ambiguità sulla semantica delle relazioni che collegano le entità.
Se i dati si moltiplicano la loro struttura di database di tipo relazionale diventa più
complessa e meno uniforme, e il modello relazionale diventa oneroso. Uno dei peggiori
svantaggi che si può ottenere nell’utilizzo dei database relazionali è l’aumento delle
costose operazioni di join, che ostacola le prestazioni e rende difficile adattare un
database esistente in risposta ai cambiamenti del business. Inoltre lo schema tabellare
mescola i propri dati con le foreign-key.
Esempio di schema relazionale, rappresentazione di un social network.
12
Graph database: Titan
I graph DB, basati proprio sul concetto di Relazione, risolvono questo problema già
all’origine, poiché la loro struttura non è tabellare, usando l’ index-free adjacency dove
ogni nodo ha un esplicito riferimento ai nodi adiacenti e non ha bisogno di ulteriori
indici per trovare questi. Inoltre per ottimizzare le performance, le informazioni sui
nodi, sulle relazioni e sulle proprietà vengono scritte su file differenti.
Esempio di schema a grafo, rappresentazione di un social network.
Per dimostrare quello che è stato appena detto riporto un esperimento fatto da Emil
Eifrem, CEO della Neo Technology, che mostra le differenze di performance tra un
database relazionale e un graph database in un certo tipo di problema chiamato
"arbitrary path query". In pratica dati 1,000 utenti, con una media di 50 amici ciascuno,
bisogna determinare se una persona è collegata ad un’altra al più di una profondità di 4
relationship.
Un popolare database relazionale open source ha impiegato circa 2,000 ms ad effettuare
questa query, mentre il graph DB 2 ms, in pratica 1,000 volte più veloce per questo tipo
di problema. Portando il numero di utenti da 1,000 ad 1,000,000. Il graph database
impiega circa lo stesso tempo, mentre il database relazionale è stato stoppato dopo
diversi giorni di attesa dei risultati.
13
Graph database: Titan
2.5 - La Modellazione di un Grafo
Essendo i Graph DMBS una tecnologia recente, non esiste ancora una precisa e ben
consolidata tecnica di modellazione. Si può affermare, in effetti, che nessuno possiede
la ricetta giusta della modellazione di uno schema a grafo. Esistono teorie differenti, e a
volte anche contrastanti, sul come dovrebbe essere la tecnica di modellazione. Il più
delle volte essa prevede la creazione uno schema entità-relazione (E-R) in tutto per
tutto. Lo schema E-R, pur essendo la base di partenza delle tecniche di modellazione di
un database relazionale, è sicuramente il diagramma che più si avvicina al property
graph model. Pur non essendo presenti teorie ben consolidate, verrà illustrata la più
accreditata ed utilizzata delle tecniche di modellazione. La tecnica di Modellazione di
un Grafo si può suddividere in 2 fasi: analisi e arricchimento.
Analisi: Nelle prime fasi dell’analisi, il lavoro richiede di avere un approccio
simile a quello del modello relazionale: utilizzando metodi lo-fi (a bassa fedeltà,
poco professionale) viene data una descrizione approssimativa del dominio, ma
che permetta di avere un’idea di come sarà poi strutturato il nostro modello
finale. In questa fase viene creato un modello molto simile allo schema E-R.
Arricchimento: Dopo aver fatto ciò, invece di trasformare le entità del modello
in tabelle, ossia creando quello che viene chiamato Modello Logico, lo
arricchiamo, con l’obiettivo di produrre un’accurata rappresentazione degli
aspetti salienti del dominio. Ovvero, creiamo dal nostro schema E-R, simile ad
un grafo, un modello a grafo arricchito di proprietà e relazioni che cerchi di
descrivere al meglio il dominio del problema. In molti casi in aggiunta allo
schema “arricchito”, si decide di non progettare uno schema generalizzato, ma
rappresentare un tipico caso d’uso che permetta di dare una descrizione globale
del dominio. Ossia, ci si baserà su uno schema che mostra i valori delle singole
entità e delle loro relazioni, esattamente il contrario di quello che viene fatto per
un database relazionale, ovvero verrà utilizzata una sotto-istanza del dominio per
descriverlo al meglio.
14
Graph database: Titan
Capitolo 3: Titan
3.1 - Titan: cos’è?
Titan è un database a grafo scalabile e ottimizzato per archiviare e interrogare grafi
contenenti centinaia di miliardi di vertici e archi distribuiti su cluster. Si tratta di un
database transazionale, in grado di supportare migliaia di utenti contemporaneamente
eseguendo complessi attraversamenti dei grafi in tempo reale.
Le funzionalità principali che Titan offre sono le seguenti:
Scalabilità elastica e lineare per dati crescenti.
Distribuzione e replicazione dei dati per garantire migliori prestazioni e una
maggiore tolleranza agli errori.
Multi-centro dati ad alta disponibilità e backup a caldo.
Supporto per ACID.
15
Graph database: Titan
Supporto per varie applicazioni di memorizzazione (Apache Cassandra, Apache
HBase, Oracle BerkeleyDB).
Supporto per ricerche tramite ElasticSerach, Solr e Lucene.
Integrazione nativa con TinkerPop (Gremlin graph query language, Gremlin
graph server e Gremlin applications).
Titan è progettato per supportare l'elaborazione di grafici talmente grandi da richiedere
capacità di memorizzazione e computazionali molto superiori rispetto a quelle che una
singola macchina è in grado di fornire. La sua capacità transazionale aumenta con
l’aumentare delle macchine costituenti il cluster.
3.2 - Benefici di Titan con Cassandra
Cassandra è un database management
system non relazionale, distribuito con
licenza open source e ottimizzato per la
gestione di grandi quantità di dati.
È incluso tra i database NOSQL
Column family, perché ha un datamodel
ispirato a BigTable.
Cassandra fornisce una struttura di memorizzazione chiave-valore, con Eventual
Consistency. Alle chiavi corrispondono dei valori, raggruppati in famiglie di colonne.
Una famiglia di colonne è definita quando il database viene creato. Tuttavia le colonne
possono essere aggiunte a una famiglia in qualsiasi momento.
Inoltre, le colonne sono aggiunte solo specificando le chiavi, così, differenti chiavi
possono avere differenti numeri di colonne in una data famiglia. I valori di una famiglia
di colonne sono memorizzati insieme, in quanto Cassandra adotta un approccio ibrido
tra DBMS orientato alle colonne e la memorizzazione orientata alle righe.
L’integrazione di Titan con Cassandra offre una serie di benefici:
Continuous Availability (approccio mirato a proteggere gli utenti contro tempi
16
Graph database: Titan
di inattività qualunque sia la causa) senza alcun single "point of failure".
Nessun collo di bottiglia in lettura o in scrittura, in quanto non è presente alcuna
architettura master/slave.
La sua scalabilità elastica consente l'introduzione e la rimozione di macchine.
Integrazione con Hadoop (framework che supporta applicazioni distribuite con
elevato accesso ai dati sotto una licenza libera).
Caching layer, assicura che i dati disponibili in memoria siano sempre disponibili
in memoria.
La dimensione della cache può aumentare aggiungendo più macchine al cluster
3.3 - Benefici di Titan con HBase
HBase è una base dati
distribuita
open
source
modellata su BigTable di
Google e scritta in Java. Fu
sviluppato come parte del
progetto Hadoop dell'Apache Software Foundation ed eseguito su HDFS (Hadoop
Distributed File System), fornendo capacità simili a quelle di BigTable per Hadoop.
I benefici di Titan con HBase sono i seguenti:
Supporto nativo alla “strong consistency”.
Scalabilità lineare con l'aggiunta di più macchine.
Strictly consistency
3.4 - Titan e il teorema di CAP
Quando si utilizza un database, dovrebbe essere accuratamente considerato il teorema di
CAP. Come si può notare dallo schema sottostante, la scelta di uno dei tre backend di
supporto a Titan (Cassandra, HBase e BerkleyDB) è influenzata dai compromessi
derivanti dal teorema. Si noti che BerkeleyDB è un database non distribuito e, come
17
Graph database: Titan
tale, con Titan viene in genere utilizzato a scopo di test e di esplorazione.
3.5 - TinkerPop e Gremlin Shell
TinkerPop è un progetto open-source che punta alla realizzazione di uno standard per
la gestione di graph database sulla piattaforma Java, sfruttando anche linguaggi
alternativi che però si integrano perfettamente nella Java Virtual Machine (JVM), come
Scala o Groovy.
L’obiettivo è quello di fornire un insieme di risorse dedicate ai graph database:
essenzialmente un server (Rexter), implementazioni di algoritmi e componenti per il
dataflow, un linguaggio di nuova generazione orientato ai grafi (Gremlin), e in
particolare una API standardizzata per l'accesso ai graph database (Blueprints).
Gremlin è un linguaggio specifico progettato per interrogare, analizzare e manipolare i
grafi all’interno dello stack TinkerPop.
Si tratta di un linguaggio di programmazione Turing completo, ossia con lo stesso
potere computazionale di una macchina di Turing universale, specializzato nella
18
Graph database: Titan
gestione di grafi. In realtà non è un linguaggio costruito da zero, ma un Domain
Specific Language derivato da Java, che fa largo uso di XPath.
Le funzionalità di Gremlin, che possono tornare utili per semplificare l'analisi e la
manipolazione di un grafo, sono la presenza di tipi di dati specifici, la disponibilità di
operazioni matematiche e la possibilità di integrazione in altri framework tramite il
General Graph Model. Questo nuovo linguaggio di programmazione lavora con un
grafo delle proprietà, un grafo in cui vertici e archi hanno proprietà definite come
elementi chiave-valore. Oltre a fornire i tipi graph, vertex ed edge, Gremlin offre
operazioni matematiche e istruzioni condizionali specializzate sui grafi.
Il linguaggio fornisce i seguenti tipi:
Grafo: un grafo è composto da una serie di vertici e una serie di archi.
Vertice: un vertice è composto da un insieme di archi uscenti, archi entranti, e
una mappa di proprietà.
Arco: un arco è composto da un vertice in uscita, un vertice in entrata, e una
mappa di proprietà.
Booleano: un booleano può essere sia vero che falso.
Numero: un numero può essere naturale (intero) o reale (double).
Stringa: una stringa è un array di caratteri.
Lista: una lista è un insieme ordinato di oggetti potenzialmente duplicati.
Mappa: una mappa è un array associativo, da un insieme di oggetti chiavi a una
collezione di oggetti valori.
3.6 - Panoramica sull’architettura di Titan
Titan è un motore di database a grafo e implementa interfacce robuste, modulari per la
persistenza dei dati, l'indicizzazione dei dati e l'accesso client. L'architettura modulare
di Titan permette di interoperare con una vasta gamma di storage, indici e tecnologie
client, e facilita anche il processo di estensione di Titan.
Titan viene fornita di serie con le seguenti estensioni, ma la sua architettura modulare
19
Graph database: Titan
supporta estensioni di terze parti.
Data storage:
o Cassandra
o HBase
o BerkeleyDB
Indici, che accelerano e consentono query più complesse:
o Elasticsearch
o Lucene
In generale, le applicazioni possono interagire con Titan in due modi:
Incorporando Titan all'interno dell'applicazione che esegue le query Gremlin
direttamente sul grafo all'interno della stessa JVM. L’esecuzione di query, la
cache di Titan, e la gestione delle transazioni avvengono tutte, come
l'applicazione, nella stessa JVM. Il recupero dei dati dal backend di
memorizzazione, invece, può essere locale o remoto.
Interagendo con un'istanza locale o remota di Titan inviando le query Gremlin al
server. Titan supporta in modo nativo la componente Gremlin Server dello stack
Tinkerpop.
20
Graph database: Titan
Capitolo 4: Esempio di un Graph DB con Titan
4.1 - Grafo degli dei
Gli esempi in questo capitolo si basano su un grafo distribuito con Titan chiamato
“Graph of the Gods”. Il modello di questo grafo è il classico property graph model e
questa particolare istanza descrive le relazioni tra gli esseri e i luoghi del pantheon
romano.
21
Graph database: Titan
4.2 - Comandi principali della Shell Gremlin
Ecco la lista dei principali comandi offerti dalla shell Gremlin:
Creare un grafo
Es:
gremlin> g = new TinkerGraph()
==>tinkergraph[vertices:0 edges:0]
Selezione di un vertice: g.v(x)
Es:
gremlin> g.v(0)
==>v[0]
gremlin> g.v(5)
==>v[5]
Selezione di un arco, con visualizzazione dei due vertici collegati: g.e(y)
Es:
gremlin> g.e(1)
==>e[1][0-_default->154]
gremlin> g.e(21)
==>e[21][4-_default->70]
Mostrare vertici adiacenti al vertice selezionato: both
Es:
gremlin> v = g.v(4)
==>v[4]
gremlin>v.both
==>v[1]
==>v[5]
==>v[3]
22
Graph database: Titan
Ottenere archi in entrata e in uscita dal vertice: bothE
Es:
gremlin> v = g.v(4)
==>v[4]
gremlin> v.bothE
==>e[8][1-knows->4]
==>e[10][4-created->5]
==>e[11][4-created->3]
Ottenere il vertice in cui l’arco entra e quello da cui esce: bothV
Es:
gremlin> e = g.e(12)
==>e[12][6-created->3]
gremlin>e.outV
==>v[6]
gremlin>e.inV
==>v[3]
gremlin> e.bothV
==>v[6]
==>v[3]
Aggiungere vertici al grafo: Graph.addVertex
Es:
g.addVertex(1)
g.addVertex(8)
Con tali comandi vengono aggiunti vertici al grafo. Si possono indicare
anche i vari attributi come nell’esempio che segue:
g.addVertex(null,[name:”William”,surname”Shakespeare”])
23
Graph database: Titan
Rimuovere vertici al grafo: Graph.removeVertex
Es:
gremlin> g.addVertex()
==>v[128]
gremlin>g.removeVertex(g.v(128))
==>null
Aggiungere un arco al grafo: Graph.addEdge
Es:
gremlin> v1 = g.addVertex(100)
==>v[100]
gremlin> v2 = g.addVertex(200)
==>v[200]
Con il comando seguente comando creiamo un arco che congiunge i due vertici
creati, assegnandogli anche un nome indicato tra virgolette.
gremlin> g.addEdge(v1,v2,’friend’)
==>e[0][100-friend->200]
Rimuovere un arco al grafo: Graph.removeEdge
Es:
gremlin> g.removeEdge(g.e(0))
==>null
Scorrere tutti gli archi del grafo: E
Es:
gremlin>g.E
==>e[10][4-created->5]
==>e[7][1-knows->2]
==>e[11][4-created->3]
24
Graph database: Titan
Ottenere le proprietà chiavi di un elemento: Element.keys
Es:
gremlin> g.v(1).keys()
==>name
==>age
Ottenere i valori delle proprietà di un elemento: Element.values
Es:
gremlin> g.v(1).values()
==>marko
==>29
Ottenere i vertici uscenti adiacenti al vertice selezionato: Out
Es:
gremlin> g.v(1).out
==>v[61]
==>v[36]
==>v[50]
Ottenere gli archi in uscita dal vertice: OutE
Es:
gremlin>g.v(1).outE
==>e(7)[1-default->61]
==>e(9)[1-default->36]
==>e(11)[1-default->50]
Ottenere il vertice da cui esce l’arco: OutV
Es:
gremlin> g.e(22).outV
==>v[4]
25
Graph database: Titan
Ottenere i vertici adiacenti al vertice selezionato: In
Es:
gremlin> g.v(5).in
==>v[80]
==>v[130]
Ottenere gli archi in ingresso al vertice: InE
Es:
gremlin>g.v(1).inE
==>e(4)[16-default->5]
==>e(7)[18-default->5]
==>e(13)[26-default->5]
Ottenere il vertice in cui entra l’arco selezionato: InV
Es:
gremlin> g.e(99).inV
==>v[89]
Ottenere una rappresentazione delle proprietà di un elemento. valueMap
Es:
gremlin> g.V().valueMap()
==>[name:[marko], age:[29]]
==>[name:[vadas], age:[27]]
==>[name:[ripple], lang:[java]]
==>[name:[peter], age:[35]]
gremlin> g.V().valueMap('age')
==>[age:[29]]
==>[age:[27]]
==>[age:[32]]
==>[:]
==>[age:[35]]
26
Graph database: Titan
4.3 - Indici del Grafo
Il modello tipico per l'accesso ai dati in un graph db è quello di individuare prima il
punto di ingresso del grafo usando un indice. Tale punto di ingresso è un vertice o un
arco. Nel nostro esempio dato che c’è un indice univoco sulla proprietà “nome”,
recuperiamo il vertice “Saturn”. Poi otteniamo la mappa delle proprietà del vertice con i
rispettivi valori, e vediamo che Saturno ha 10000 anni. Alla fine chiediamo al graph db
chi fosse il nipote di Saturno. Il risultato è Hercules.
4.3.1 - Esempi di Graph traversal
Hercules è un semidio e, per dimostrare che è metà dio e metà umano, devono essere
esaminate le origini dei suoi genitori. E’ possibile, quindi, attraversare dal vertice Ercole
a quello di sua madre e di suo padre. Infine, determiniamo il tipo di ciascuno di essi,
"human" e "god".
Gli esempi finora sono stati rispetto alle linee genetiche dei diversi attori del
Pantheon romano. Il property graph model è abbastanza espressivo per rappresentare
diversi tipi di cose e relazioni.
Il grafo degli dei individua anche varie imprese eroiche di Hercules, le sue famose 12
27
Graph database: Titan
fatiche. È possibile esplorare questi eventi attraversando gli archi “battled” in uscita dal
vertice Hercules.
In seguito vengono forniti ulteriori esempi più complessi di graph traversal sul grafo
degli dei. La spiegazione di ogni attraversamento è presente nella linea precedente con
un commento “ // ”.
Coabitanti di Tartaro
Fratelli di Plutone
28
Graph database: Titan
Plutone vive nel Tartaro, perché non mostra alcuna preoccupazione per la morte. I suoi
fratelli, d'altra parte, scelgono le loro posizioni in base al loro amore per certe qualità di
queste località.
29
Graph database: Titan
Bibliografia
[1]
NoSQL Database, http://www.nosql-database.org/
[2]
Ian Robison, Jim Wabber. "The Graph Database." - O’Reilly Media Inc., 2013.
[3]
Titan Documentation, http://s3.thinkaurelius.com/docs/titan/1.0.0/
[4]
Introduction to Graph DB, http://www.youtube.com/watch?v=UodTzseLh04
[5]
TinkerPop Documentation,
http://tinkerpop.incubator.apache.org/docs/3.0.1-incubating/
30
