ALMA MATER STUDIORUM - UNIVERSIT DI BOLOGNA

SCUOLA DI INGEGNERIA E ARCHITETTURA

DIPARTIMENTO DI INFORMATICA-SCIENZA E INGEGNERIA

CORSO DI LAUREA IN INGEGNERIA GESTIONALE

TESI DI LAUREA

In

Sistemi Informativi L

Database relazionali e database a grafo a confronto:

analisi delle prestazioni di MySQL e Neo4j

CANDIDATO RELATORE:
Nicholas Tonna Chiar.ma Prof.ssa Wilma Penzo

Anno Accademico 2015/16

Sessione III

INDICE

1
INTRODUZIONE.4
CAPITOLO 1 I GRAPH DATABASE.5
1.1 Evoluzione dei modelli di database nel corso degli anni 5
1.2 I database NoSQL7
1.2.1 Categorie di sistemi database NoSQL....7
1.3 Cos un Grafo? ..9
1.3.1 Il Property Graph Model10
1.4 I graph DBMS11

CAPITOLO 2 RELATIONAL VS GRAPH DATABASE.....13

2.1 Modello dei Dati13
2.2 Le relationship nei database relazionali e a grafo..15
2.3 Linguaggi di interrogazione nei Database Relazionali e a Grafo..17
2.4 Scalabilit...19
2.5 Trattamento delle Transazioni...20
2.6 Gestione degli indici..22
2.7 Confronto tra progettazioni dei dati..23
2.8 Vantaggi dei Database a Grafo......26

CAPITOLO 3 NEO4J..28
3.1 Architettura28
3.1.1 Struttura di Storage...29
3.1.2 Cache31
3.1.3 Transaction Module..32
3.1.4 Neo4j High Availability (HA)..33
3.1.5 API34
3.2 Cypher query language..35
3.3 Confronto prestazionale tra API37
3.4 Confronto prestazionale tra Neo4j e MySQL40

CONCLUSIONI..45

2
INTRODUZIONE

3
Il sistema informativo aziendale (SIA) l'insieme dei mezzi tecnici, delle procedure
organizzative e delle risorse umane finalizzati alla gestione delle informazioni
prodotte, utilizzate e condivise da un'azienda durante l'esecuzione dei processi
aziendali [2]. Questi sistemi oggi si appoggiano sempre pi ai sistemi informatici
grazie ai quali possibile, oltre ad aumentare la velocit e lefficienza
dellinformazione, immagazzinare grandi quantit di dati in database. I database
sono archivi nei quali i dati sono memorizzati in modo strutturato. Il compito di
organizzare, interrogare e manipolare in modo efficiente il database affidato a un
sistema software chiamato DBMS (Database Management System).
Nella seguente tesi si andranno a confrontare due tipi di DBMS (che per semplicit
possiamo chiamare semplicemente database): i Relational database e i Graph
database.
I relational database sono nati a seguito dellintroduzione del modello relazionale da
parte di Codd[1] nel 1970 e da allora sono i database pi utilizzati. Con questo
modello logico infatti stato possibile descrivere al meglio quasi lintera totalit dei
casi duso che si presentavano nel mondo reale. Con lavvento di Internet e
laffermarsi dei social network aumentata la connessione dati e il numero di
informazioni e richieste da gestire; questo ha portato a galla i limiti del modello
relazionale nel trattare grandi quantit di dati molto connessi o nel memorizzare dati
non strutturati.
Per questo si sviluppata una nuova categoria di database chiamati NoSQL (Not only
SQL), tra i quali i graph database, capaci di garantire un modello pi flessibile e una
scalabilit migliore. Per ora questi modelli non si sono molto diffusi nel mondo
commerciale, che rimane ancora legato ai modelli relazionali, e solo alcune grandi
compagnie hanno iniziato ad investire in tali tecnologie (ad esempio Google,
Facebook ed Ebay).
Lo scopo di questa tesi sar quindi quello di comprendere quali vantaggi possono
portare le basi di dati a grafo. Il confronto sar effettuato anche dal punto di vista
prestazionale verificando il costo di risposta ad alcune interrogazioni. I database
utilizzati per testare i modelli saranno MySQL per i database relazionali e Neo4j per i
database a grafo, questultimo DBMS sar approfondito nel terzo capitolo della tesi.
CAPITOLO 1 I GRAPH DATABASE

4
1.1 Evoluzione dei modelli di database nel corso degli anni

FIGURA 1 Evoluzione dei vari modelli di database.

Negli ultimi quarantanni si sono sviluppati diversi modelli di database.

Il termine database model fu introdotto per la prima volta nel 1976 e sta ad indicare
quello strumento logico/concettuale sulla base del quale viene poi sviluppato il
database e si basa su tre principali caratteristiche: un insieme di tipologie di strutture
dati, regole, un insieme di operazioni.
I database model sono fondamentali per capire e utilizzare i graph database.
Come mostrato nella figura 1 [1] allinterno dei rettangoli vengono rappresentati i
vari modelli che si sono sviluppati nel corso degli anni, le ellissi determinano le teorie
dalle quali si sono sviluppati e le frecce le varie influenze.

5
I primi modelli utilizzavano strutture basate principalmente sul file system e quindi
sul modello fisico, in particolare parliamo del modello gerarchico (hierarchical
database model ) e del modello reticolare (network database model).
Una prima evoluzione si ha con lo sviluppo del database relazionale secondo la
formulazione di Codd [1], il quale ebbe lidea di separare il livello logico da quello
fisico.
Questo modello, basato sulla teoria degli insiemi, sulla logica del primo ordine e
strutturato intorno al concetto matematico di relazione, ancora oggi uno dei modelli
pi utilizzati essendo molto pi intuitivo ed espressivo per la strutturazione dei dati,
anche se per spesso risulta pi lento ed occupa una memoria di massa maggiore
rispetto ad altri modelli.
In seguito al modello relazionale si sviluppa, anche grazie allinfluenza di
questultimo unita allinfluenza della teoria dei grafi, il modello semantico, che cerca
per lappunto di mantenere il livello concettuale molto vicino al dominio semantico.
Negli anni 80 viene introdotto il modello object oriented la cui idea principale era
quella di rappresentare i dati come collezioni di oggetti [1].
Accanto a questultimo fanno la loro comparsa anche i modelli a grafo, i quali
cercano di rappresentare sotto forma di grafo il dominio applicativo, creando, come
vedremo in seguito, numerosi vantaggi, soprattutto in termini di prestazioni.
Il modello a grafo proprio grazie alla sua efficacia stato molto sviluppato negli anni
influenzando nuovi modelli con caratteristiche sempre pi flessibili.
Tra questi possibile individuare il Semi-structured database model che fu adottato
nel 1997 da Buneman [1] che si propone di trattare i dati con una struttura flessibile
come le pagine web o i documenti.
Infine XML un sistema software adottato da Bray[1] nel 1998, che permette ai dati di
essere memorizzati nel formato XML.
I graph database sono stati sviluppati principalmente sulla base di due modelli: RDF e
Property graph che verranno approfonditi nei prossimi capitoli.
Basato proprio su questultimo, nel 2007, stato sviluppato Neo4j.
1.2 I database NoSQL

6
Come abbiamo visto il database relazionale fece la sua comparsa fin dagli anni 70
e anche per questo ed stato altamente utilizzato. Proprio grazie a questo suo
prolungato utilizzo stato molto sviluppato, ma, nonostante questo, il database
relazionale non stato progettato per supportare la scalabilit orizzontale oggi
caratteristica sempre pi utile e necessaria [3].
Con scalabilit si intende la capacit da parte di un database di crescere o diminuire in
funzione delle necessit e delle disponibilit e pu essere di due tipi:
Scalabilit Verticale
Scalabilit Orizzontale
Quella verticale (scale up) riguarda la capacita di un sistema di migliorare le
caratteristiche hardware dei singoli componenti, mentre quella orizzontale (scale out)
pu essere ottenuta ad esempio aggiungendo ad un calcolatore un ulteriore unit di
calcolo di pari potenza capace di supportare il lavoro svolto dal primo ed estenderne
cos le potenzialit.
I NoSQL Database Management System sono sistemi software che consentono di
immagazzinare e organizzare i dati senza fare affidamento sul modello relazionale e
che consentono la scalabilit orizzontale (pi efficiente e meno onerosa della
scalabilit verticale). Il termine NoSQL significa not only SQL . SQL il
linguaggio comunemente usato nei database relazionali e viene spesso preso in
rappresentanza dellintero paradigma relazionale.
I database NoSQL si dividono in quattro principali categorie.

1.2.1 Categorie di sistemi database NoSQL[3]

Key-value store
Questo modello sicuramente caratterizzato da strutture dati molto semplici.
Essenzialmente i record sono memorizzati e recuperati usando una chiave che
definisce univocamente il record, cos da rendere possibili ottime performance
(soprattutto in lettura). I valori non seguono uno schema fisso, ma ognuno pu
possedere differenti campi (o attributi) come vediamo in figura 2.

7
 FIGURA 2 Rappresentazione del Key-Value store

Document database
Le basi di dati orientate ai documenti non memorizzano i dati in tabelle con
campi uniformi per ogni record come nei database relazionali, ma ogni record
memorizzato come un documento che possiede determinate caratteristiche.
Al documento pu essere aggiunto un qualsiasi numero di campi con qualsiasi
lunghezza, questi campi possono anche contenere pezzi multipli di dati.
Questa caratteristica fa s che non ci sia uno spreco di spazio, poich i record
non sono obbligati a seguire uno schema fisso e quindi costretti a riempire
anche gli attributi che non possiedono con il valore null.

Column-oriented database
Questo modello stato progettato per trattare una grande quantit di dati e
memorizza le tabelle di dati sotto forma di colonne di dati piuttosto che come
righe di dati. Il Column-Oriented database pu essere visto come una
evoluzione del Key-Value store poich a differenza di questo utilizza due o
pi livelli di indicizzazione. La chiave pi esterna (row key) usata per
identificare ogni column family e ognuna di queste definisce a sua volta
dove i dati sono memorizzati sul disco.

Graph database
Il database a grafo un database basato sulla teoria dei grafi ed molto utile
per attraversare con facilit milioni di nodi interconnessi da relazioni.

8
 Questi database sono altamente scalabili e flessibili ed oggi sono molto
utilizzati soprattutto per via dello sviluppo dei social network che sono di fatto
grafi con milioni di nodi.
Qui di seguito approfondiremo questultimo modello.

1.3 Cos un Grafo?

Come la matematica ha un ruolo importante nellinformatica (ad esempio molti

concetti come la crittografia, lautomazione e anche altri concetti pi semplici come
la logica matematica e booleana collegano strettamente matematica e alla
informatica), cos la teoria dei grafi un altro concetto molto utilizzato in questa
scienza. Molte strutture dati come le organizzazioni gerarchiche, i diagrammi di
flusso e i social network sono rappresentati attraverso grafi [3].
La teoria dei grafi si occupa di studiare i grafi, oggetti discreti che permettono di
schematizzare una grande variet di situazioni e di processi e spesso di consentirne
l'analisi in termini quantitativi e algoritmici, rendendoli capaci di adattarsi e
rappresentare ogni tipo di dato.
Un grafo una insieme di elementi detti nodi o vertici, collegati fra loro da archi o
lati. I nodi nel grafo rappresentano le entit e gli archi le relazioni tra i nodi .
Pi formalmente si dice grafo una coppia ordinata G = (V,E), dove V linsieme dei
nodi ed E linsieme degli archi. Un arco una coppia (a,b) di vertici, con aV e
bV.

Prendendo ad esempio il noto social network Twitter, nella figura 3 vediamo un

piccolo network di utenti Twitter.
Gi questo semplice esempio (figura 2) ci fa capire il potere espressivo dei grafi e di
quanto siano intuitivi da comprendere. Le relazioni sono la chiave per comprendere il
contesto semantico, dicendoci, in questo caso, chi seguito da chi.

9
 FIGURA 3 Un piccolo grafo che rappresenta un insieme di follower con laggiunta
dei messaggi da parte di uno di questi.

1.3.1 Il Property Graph Model

La variante pi conosciuta del modello a grafo quella del Property Graph Model.
Il Property Graph ha le seguenti caratteristiche:
Contiene nodi e relazioni;
I nodi contengono propriet attraverso coppie chiave-valore, dove chiave
la stringa identificativa della propriet, valore dipende invece dal tipo di
dato;
I nodi possono essere contrassegnati da uno o pi label. Le label indicano il
ruolo dei nodi allinterno del database (Labeled Property Graph Model);
Le relazioni possiedono un nome e sono orientate, ed hanno sempre un nodo
di partenza e un nodo di arrivo;
Anche le relazioni possono possedere delle propriet.

Quando le relazioni sono immagazzinate efficientemente, due nodi possono

condividere qualsiasi numero o tipo di relazioni senza sacrificare le performance di
attraversamento del grafo.

10
Unimportante caratteristica da ricordare a proposito dei Property Graph, ma
riguardante tutti i grafi, che una relazione connette sempre due nodi e che
leliminazione di un nodo determina leliminazione delle relazioni ad essa associate.
Molte persone trovano il Property Graph Model intuitivo e facile da capire, infatti,
sebbene semplice, pu essere usato per descrivere la stragrande maggioranza dei casi
duso grafici, in modo tale che diano indicazioni utili sui nostri dati.

FIGURA 4 Un building block del Property Graph

1.4 I graph DBMS

Un Graph Database Management System un sistema per la gestioni dei database.

Questo un sistema software progettato per consentire la creazione, la manipolazione
e l'interrogazione efficiente di database.
I Graph DBMS sono generalmente costruiti per essere utilizzati con i sistemi
transazionali OLTP. Di conseguenza sono normalmente ottimizzati per favorire le
prestazioni e progettati per lintegrit e disponibilit delle operazioni transazionali.
Vi sono due componenti dei graph database da tener in mente quando si vuole
analizzare una tecnologia di questo tipo:

11
Data Storage
Qualche Graph DBMS utilizza dei native graph storage [4], ovvero, possiede una
piattaforma di salvataggio delle informazioni nata ed ottimizzata per salvare i dati
sotto forma di grafo. Diversi graph DBMS traducono e salvano le informazioni in
modi differenti, ovvero allinterno di un database relazionale, di un database orientato
agli oggetti, o qualche altro tipo di data store.

Processing Engine
Possiamo distinguere i graph DBMS in due categorie, la prima formata da tutti quelli
che sfruttano lindex-free adjancency, processing engine nativo (pi performante); la
seconda quelli che non la usano, processing engine non nativo.
Un grafo soddisfa la index-free adjacency se la presenza di una relazione tra due nodi
pu essere verificata solo visitando uno dei nodi e non richiede invece laccesso a un
indice globale esterno. Questo comporta che ogni elemento contenga un puntatore
diretto ai suoi elementi adiacenti rendendo cos le ricerche via indice non necessarie.

FIGURA 5 Una panoramica dei modelli di alcuni graph database presenti oggi sul
mercato.

12
CAPITOLO 2 RELATIONAL VS GRAPH DATABASE

2.1 Modello dei Dati

Il Modello Relazionale
Il modello relazionale un modello logico di rappresentazione o strutturazione
dei dati di un database implementato su sistemi di gestione di basi di dati (DBMS),
detti perci sistemi di gestione di basi di dati relazionali (RDBMS) [2].
Questo modello si sviluppa intorno al concetto di relazione (o tabella). Tutti i dati
allinterno di una base di dati relazionale sono rappresentati per mezzo di tabelle e le
colonne di tali tabelle sono formalmente chiamate attributi della relazione mentre le
righe tuple.

FIGURA 6 Esempio di relazioni (tabelle) in un database relazionale.

Un altro concetto centrale in questo modello la normalizzazione che un

procedimento che permette ai database relazionali di immagazzinare qualunque dato
senza ridondanza o perdita di informazione, garantendo, quindi, la consistenza dei
dati.
Una volta che il modello dei dati stato progettato in modo consistente, i dati
possono essere inseriti e manipolati utilizzando il linguaggio strutturato standard dei
database relazionali, vale a dire SQL (Structured Query Language).

13
Il modello relazionale, pur essendo un modello ormai standard e molto utilizzato,
presenta diversi problemi:
In strutture con dati altamente interconnessi, come ad esempio i network o i
social, i dati devono essere memorizzati usando un alto numero di tabelle,
generando problemi a causa dellelevato numero di operazioni join
(operazioni molto costose di combinazione delle tuple appartenenti a due
tabelle) necessarie per recuperare i dati; infatti le operazioni di join hanno
basse performance e non sono scalabili con il crescere del numero di tuple.
Un altro problema di questo modello riguarda la sua inefficienza nel
memorizzare dati semi-strutturati e non strutturati (non seguono strutture
fisse) che vengono memorizzati in tabelle in cui la maggior parte delle
colonne risulter vuota [3].
Il Relational Database supporta schemi molto rigidi poich tutte le tuple in una
relazione seguono lo stesso schema e quindi hanno le stesse colonne, motivo per cui
spesso molte colonne rimangano parzialmente riempite [3].

Il Modello a Grafo
Un modello a grafo usa nodi e archi per rappresentare e archiviare l'informazione. La
rappresentazione dei dati mediante grafi offre un'alternativa al modello relazionale.
Attualmente i modelli principali di riferimento per limplementazione dei database a
grafo sono due:
Il Property Graph Model (gi descritto nel capitolo precedente)
Il RDF (Resource Description Framework)

Il Resource Description Framework un modello proposto dal World Wide Web

Consortium (W3C), unorganizzazione non governativa internazionale che ha come
scopo quello di sviluppare tutte le potenzialit del World Wide Web.
Questo modello basato su tre oggetti:
- Resource (risorsa): indica ci che viene descritto mediante RDF;
- Property (propriet): indica una propriet, un attributo o una
relazione utilizzata per descrivere una risorsa;

14
 - Statement (espressione): l'elemento che descrive una risorsa
costituito da un soggetto che rappresenta la Resource, un predicato che
esprime la Property e da un oggetto chiamato Value che indica il valore della
propriet.
Ogni istanza di questo modello quindi formato da un insieme di triple del tipo
soggetto-predicato-oggetto, che formano una struttura a grafo in cui le risorse sono
rappresentate dai nodi e i predicati dagli archi.

I due modelli (Property Grafh Model ed RDF) non sono del tutto coincidenti, anche
se solitamente il passaggio da uno all'altro molto intuitivo. Per entrambi esistono dei
linguaggi di interrogazione specifici, ma solo per RDF esiste uno standard
riconosciuto in SPARQL [2].
Dal punto di vista della struttura i Graph Database, al contrario di quelli relazionali,
sono molto pi flessibili: ogni nodo e relazione nel grafo possiede le proprie propriet
senza quindi seguire uno schema rigido come nel caso del Relational Database, di
conseguenza in questo tipo di schema non si presenter il problema dei valori nulli e
di allocare spazio per questi valori.

2.2 Le relationship nei database relazionali e a grafo

Relationship nei Database Relazionali

Per molti decenni gli sviluppatori hanno cercato di sistemare i dati connessi e semi-
strutturati allinterno di database relazionali, ma siccome i relational database erano
inizialmente progettati per codificare strutture a tabelle, potevano sorgere difficolt
nel modellare questo tipo di dati [4].
Quando si parla di relationship nei database relazionali si intende il modo in cui le
tabelle, che contengono istanze diverse, si relazionano tra di loro; per farlo utilizzano
il join che nel linguaggio SQL un operatore il quale permette di combinare le tuple
di due tabelle tramite l'operazione di congiunzione (od unione) dell'algebra
relazionale.
Un aspetto negativo delle relationship allinterno database relazionale che hanno
ambiguit semantica poich non specificano ad esempio il peso e la forza della

15
relationship stessa e per di pi le operazioni di join sono molto onerose in particolare
allinterno di contesti altamente connessi, come network e social (molto diffusi ai
giorni doggi).
Il costo di unoperazione di interrogazione del database aumenta significativamente a
seconda del numero di join che vengono eseguiti. Si ponga ad esempio il caso che un
social network strutturato come in figura 7 si vogliano trovare gli amici di un soggetto
registrato nella tabella Person allinterno del database. Relativamente a questo tipo
di interrogazione necessaria una operazione di join dato che la tabella Person
dovr relazionarsi con quella PersonFriend dunque la query non risulterebbe
particolarmente costosa o difficile poich, oltre a richiedere un solo join tra le tabelle,
si pu ridurre il numero di tuple attraverso la clausola WHERE.

FIGURA 7 Esempio di un semplice schema di dati riguardanti le persone di un social

network e le loro relative amicizie.

Se ad esempio si volessero trovare gli amici degli amici di un determinato soggetto,

loperazione richiederebbe due join e quindi le query diventerebbero sintatticamente e
computazionalmente pi complesse e aumenterebbero di conseguenza il costo della
risposta.

Relationship nei Database a Grafo

Quando ci sono dati connessi che includono dipendenze semantiche tra le entit, il
modello a grafo risulta molto pi appropriato in quanto le relationship, a cui possono
essere associate propriet, mantengono queste dipendenze semantiche.

16
Nel caso dei social network, semplice esempio di dati altamente connessi e network
semi-strutturato, la struttura del modello risulter come in figura 8.

FIGURA 8 Semplice esempio di social network.

In questo social network le connessioni fra le entit non sono uniformi per tutto il
dominio. Il grafo offre un quadro pi ricco di un contesto network, infatti dalla figura
8 possiamo capire intuitivamente chi lamico di chi o chi collega di chi (attraverso
la relationship FRIEND_OF o COLLEAGUE_OF) ed anche se questa relationship
viene ricambiata.
Grazie alle relationship inoltre possibile attraversare il grafo, cio muoversi tra i
nodi collegati dalle relationship. Interrogare i dati per mezzo di questi attraversamenti
ci evita di eseguire costose operazioni di raggruppamento sullintero insieme di dati,
come invece avviene con le operazioni di join nei database relazionali.

2.3 Linguaggi di interrogazione nei Database Relazionali e a Grafo

I database relazionali per interrogare, inserire modificare e cancellare dati nel

database, utilizzano lo standard SQL.

17
SQL un linguaggio dichiarativo basato sullalgebra relazionale. Con questo
linguaggio possibile:
creare e modificare schemi di database (DDL - Data Definition Language);
inserire, modificare e gestire dati memorizzati (DML - Data Manipulation
Language);
interrogare i dati memorizzati (DQL - Data Query Language);
creare e gestire strumenti di controllo ed accesso ai dati (DCL - Data Control
Language).

Per linterrogazione dei dati SQL si basa sui tre comandi principali SELECT, FROM,
e WHERE.
Un esempio di interrogazione riferito al social network del paragrafo precedente
(figura 5) potrebbe essere:

Questa interrogazione ci restituir come risultato gli amici di Bob.

La forza della graph query language si misura con la sua abilit di attraversare
efficacemente il grafo che significa passare attraverso il grafo, nodo per nodo, per
mezzo delle relazioni che li collegano.
I graph database, al contrario dei relational database, non possiedono un linguaggio di
interrogazione standard, i linguaggi pi utilizzati e famosi sono Cypher e Gremlin
[12].
Cypher un linguaggio dichiarativo (ovvero un tipo di linguaggio che si focalizza
sulla descrizione della propriet considerata, lasciando indeterminato lalgoritmo da
usare per trovare la soluzione) ispirato a SQL proprio di Neo4j, mentre Gremlin un
graph traversal language sviluppato da Tinkerpop che supporta interrogazioni
dichiarative e imperative. Neo4j fornisce anche API Java native per linterrogazione

18
dei dati. Queste presentano un grado di astrazione minore rispetto ai due linguaggi
sopra citati ma unottima efficienza.

2.4 Scalabilit

La scalabilit una caratteristica molto importante che determina un utilizzo

efficiente del database [3] e ad oggi risulta uno dei requisiti pi importanti delle
moderne applicazioni proprio perch queste devono trattare con milioni di dati.
La scalabilit di due tipi: verticale ed orizzontale. Per ottenere il primo tipo
necessario incrementare le capacit della macchina, la qual cosa richiede un costo
elevato. Per questo motivo la scalabilit orizzontale molto pi utilizzata, e si pu
ottenere con due tecniche: replication e sharding.
Replication significa i dati sono replicati su pi nodi di una rete calcolatori,
rendendo quindi i dati pi robusti. Infatti se un nodo fallisce i dati persi
possono essere recuperati da un altro nodo. Inoltre incrementa le operazioni di
lettura poich si possono distribuire le operazioni di lettura su vari nodi. Per le
operazioni di scrittura, invece, la prestazione peggiorer poich i dati devono
essere modificati su tutti i nodi.
Sharding invece una modalit pi complessa di distribuzione dei dati che
prevede il loro partizionamento dei dati in base a vari criteri su vari nodi.
Questo significa che i dati possono non essere su una sola macchina, ma
distribuiti su pi nodi. Sharding una tecnica molto flessibile nella quale i
nodi possono essere aggiunti quando i dati crescono e rimossi quando
decrescono senza interessare lapplicazione.

Lo scalabilit nei database relazionali risulta un problema a causa delle operazioni di

join, infatti, a causa della frammentariet dei dati, si rende necessaria una grande
comunicazione tra i nodi che richieder un numero maggiore di join e quindi un costo
maggiore; questo il motivo per cui i database NoSQL non supportano le operazioni
di join.

19
Scalare i dati di un grafo, attraverso lo sharding, pu risultare pi complesso che
distribuire i dati negli altri database NoSQL anche se comunque possibile [6].
Questo dovuto alla natura molto connessa dei grafi. Quando si distribuisce un grafo,
in sostanza, meglio evitare il pi possibile di avere relazioni che abbraccino pi
nodi della rete di calcolatori.

2.5 Trattamento delle Transazioni

In informatica una transazione una sequenza di operazioni che pu concludersi o

con un successo o con un insuccesso: nel primo caso il risultato delle operazioni deve
essere reso persistente nel secondo caso invece si deve tornare allo stato consistente
precedente allinizio della transazione [2].
Nei database relazionali le transazioni godono di quattro propriet dette propriet
ACID:
Atomicit: la transazione indivisibile nella sua esecuzione che quindi deve
essere necessariamente o totale o nulla (non sono ammesse esecuzioni
parziali);
Consistenza: la capacit di una transazione di non violare i vincoli
referenziali e di integrit della base di dati cos che ogni client che acceder al
database legger gli ultimi dati aggiornati.
Isolamento: la garanzia che il DBMS esegua le transazioni in maniera
indipendente ed isolata in modo che non interferiscano tra di loro se
l'esecuzione di queste contemporanea.
Durabilit: i dati scritti sul database saranno memorizzati su disco e
disponibili dopo il riavvio del database.
Queste propriet consentono alle transazioni di eseguire operazioni corrette e sicure
sulla base di dati.
La consistenza viene garantita nei database relazionali dal central locking system,
grazie al quale i dati sono bloccati fino a quando non si raggiunge uno stato stabile.
I nuovi database NoSQL, inclusi alcuni graph database, hanno optato per una pi
debole forma di consistenza (Eventual Consistency) in favore di una maggiore

20
disponibilit dei dati (High Availability). Questi database seguono un paradigma
chiamato BASE (Basically Available, Soft-state, Eventually consistent).
La differenza dei due sistemi spiegabile attraverso il CAP theorem il quale, proposto
per la prima volta da Eric Brewer [3] nel 2000, afferma che un sistema distribuito pu
fornire contemporaneamente solo due fra le seguenti garanzie:
Consistency (consistenza): si ha quando in un ambiente distribuito tutti i
server hanno gli stessi dati;
Availability (disponibilit): si ha quando il sistema fornisce la garanzia di
accesso e usabilit dei dati;
Partition Tolerance (Tolleranza al Partizionamento): garantisce che il sistema
rimanga funzionante nonostante la perdita di messaggi; in questi casi alcuni
nodi possono rimanere isolati dagli altri e non avere pi informazioni
aggiornate (sono partizionati).

Nel caso si scelga di tralasciare la partition tolerance, si possono eseguire operazioni

di lettura e scrittura fin quando tutti i nodi sono online ed possibile essere sicuri che
i dati siano consistenti. Il problema si presenta quando si crea partizione tra i nodi, a
causa della quale i dati perdono la sincronizzazione. Per evitare la partizione si
potrebbero inserire tutti i dati in una sola macchina, ma questo porterebbe
sicuramente limitazioni alla scalabilit.
Nel caso si scelga di rinunciare alla disponibilit (availability), il sistema, per le
operazioni di modifica, garantir la consistenza rendendo i dati indisponibili per un
certo tempo. Il sistema rimane indisponibile fin quando la modifica non sar
trasportata su tutti i nodi. Questa lidea seguita dalle propriet ACID.
Nel caso in cui invece si scelga di penalizzare la consistenza (consistency), ne
gioveranno la disponibilit dei dati e la tolleranza di partizionamento, cos che, i nodi
rimarranno online anche se non possono comunicare con gli altri. I dati verranno per
sincronizzati solo dopo che la partizione sar risolta (si tratta appunto della Eventual
Consistency).
I problemi di inconsistenza di solito risultano pi difficili da trattare. Daltro canto, i
sistemi non necessitano continuamente di consistenza.

21
Una particolarit dei database a grafo che, nonostante siano database NoSQL, alcuni
modelli supportano le propriet ACID e questo il caso di Neo4j come vedremo nel
prossimo capitolo.
2.6 Gestione degli indici

Quando si vuole memorizzare una struttura a grafo in un database relazionale

necessario procedere come segue:
Creare un'entit VERTICES per i vertici con le propriet:
- ID del vertice;
- Vari attributi per le informazioni contenute nel vertice (nome ecc).
Creare unentit EDGES per gli archi con le propriet:
- ID dellarco;
- VERTEX_FROM: ID del vertice di partenza;
- VERTEX_TO: ID del vertice di arrivo;
- Informazioni aggiuntive sulla relazione tra i vertici.
Creare indici aggiuntivi:
- indice su EDGES.VERTEX_FROM;
- indice su EDGES.VERTEX_TO.
La creazione di indici utile per un effettuare un pi rapido accesso ai dati. Gli indici
pi utilizzati sono il B-Tree, B+Tree o indici Hash.
Questo approccio per, nonostante sia corretto, comporta un grave problema:
all'aumentare delle righe (soprattutto sulla tabella dei vertici), il costo in lettura
aumenta sensibilmente. Il costo per una lettura tramite indice B-Tree infatti
dell'ordine di O(log(n)), dove n = numero totale di vertici del grafo. Per esaminare gli
M archi in uscita dal vertice di partenza abbiamo quindi un costo computazionale C di
C=(Mlog(n)) [7].
I graph database offrono una soluzione diversa rispetto ai relazionali usando la
tecnica chiamata index-free adjacency. Infatti, per riuscire ad ottenere una lettura
costante ogni singolo vertice ha un indice degli archi in uscita e questo permette di
verificare lesistenza di un arco tra due vertici del grafo semplicemente visitando uno
dei due vertici, e senza quindi il bisogno di un indice globale [8]. In altre parole ogni

22
nodo porta le informazioni sui nodi a cui relazionato, rendendo indipendente le
prestazioni dalle dimensioni globali del database e possibile lanalisi di grafi
difficilmente gestibili con indici globali.
2.7 Confronto tra progettazioni dei dati

Nella progettazione di una base di dati possiamo distinguere tre fasi:

La progettazione concettuale il cui scopo rappresentare i dati della realt (o
dominio) dinteresse in termini di un modello formale indipendente dal
DBMS. La descrizione attraverso tale modello produce uno schema
concettuale.
La progettazione logica che si pone come obiettivo quello di trasformare lo
schema concettuale, fornito in ingresso dalla fase precedente, in uno schema
logico di descrizione dei dati pertinente al tipo di DBMS scelto (quindi
descritta con un linguaggio formale supportato dal DBMS).
La progettazione fisica nella quale si implementa lo schema fisico che in
pratica consiste in uno schema logico ottimizzato in funzione delle previsioni
del carico applicativo.

Per confrontare i due tipi di database (relazionale e a grafo) si pu fare il semplice

esempio di progettazione di un database riguardante la gestione di un data center, cio
un centro di elaborazione dei dati la cui struttura pu essere rappresentata in figura 9
[4].

23
 FIGURA 9 Esempio di Data Center.
Progettazione per le basi di dati relazionali
La progettazione preceduta da una fase di raccolta e analisi dei requisiti che
definisce i dati e le operazioni da svolgere su questi. La maggior parte delle volte
questo passaggio risulta informale ed avviene spesso attraverso schizzi alla lavagna a
seguito di una discussione tra lesperto in materia e larchitetto dei dati e del sistema.
Al termine di questa fase si ottiene una descrizione informale dei requisiti espressa
nel linguaggio naturale partendo dalla quale si crea un glossario termini e talvolta un
diagramma come quello dellesempio precedente (figura 9).

La fase successiva la progettazione concettuale che traduce il risultato della raccolta

dei requisiti in una descrizione formale cercando di eliminare le ambiguit tipiche
delle frasi nel linguaggio naturale producendo uno schema concettuale. Sono stati
proposti vari modelli concettuali ma il pi famoso e utilizzato sicuramente il
diagramma Entity-Relationship (E-R).
In riferimento allesempio precedente, si pu costruire il seguente diagramma E-R:

24
 FIGURA 10 Un diagramma Entity-Relationship per un Data Center.

Dato che non esistono DBMS in gradi di operare direttamente sui concetti di uno
schema E-R necessario tradurlo in schemi relazionali passando quindi da uno
schema concettuale ad uno logico. Questa traduzione viene fatta seguendo semplici
regole standard e spesso viene fatta in modo automatico. Nel modello logico i dati
sono strutturati in tabelle normalizzate per eliminare la ridondanza ed espresse con il
linguaggio SQL.
Lultima fase che precede limplementazione vera e propria quella della
progettazione fisica nella quale vengono rivisti gli schemi logici in funzione del
carico di lavoro previsto ad esempio pu essere talvolta utile, per migliorare
lefficienza e la velocit del database, una denormalizzazione dei dati, tecnica che
prevede la duplicazione dei dati al fine di acquisire migliori performance.

Progettazione per le basi di dati a grafo

I database relazionali, con i loro rigidi schemi, non sono certo uno strumento
particolarmente buono per supportare rapidi cambiamenti, quindi necessario un
modello strettamente allineato col dominio, che non sacrifica le prestazioni e che
supporta levoluzione conservando lintegrit dei dati quando sottoposto a rapidi
cambiamenti; tale modello il modello a grafo.
La fase precedente alla progettazione, cio quella di raccolta dei requisiti, risulta
simile a quella relazionale. Dopo questa fase la metodologia diverge poich, invece di

25
utilizzare un diagramma Entity-Relationship, si utilizza un grafo, con lo scopo di
produrre una accurata rappresentazione del dominio [4].
In riferimento allesempio possibile costruire il modello a grafo di figura 11.
Nellesempio si vede come i nodi siano stati arricchiti con propriet e come gli archi
specifichino il tipo di relazione che c tra i nodi (le relazioni sono in questo caso
orientate e volendo possono possedere anche attributi).
Si pu inoltre percepire come il modello concettuale nei graph database risulti pi
espressivo e affine alla struttura del dominio (figura 9) rispetto a quello del relational
database.
Infine, una volta creati i nodi e le relazioni sul graph database, si testa il modello per
verificare se adatto ad eseguire specifiche query e si correggono gli errori o
imprecisioni eventuali. I cambiamenti successivi della struttura del grafo sono
facilitati grazie alla flessibilit del modello a grafo.

FIGURA 11 Esempio di grafo che descrive un Data Center.

2.8 Vantaggi dei Database a Grafo

26
Prestazioni
Uno dei maggiori vantaggi portati dalla base di dati a grafo il netto miglioramento
delle prestazioni nel caso di dati fortemente connessi, non solo rispetto ai database
relazionali ma anche relativamente a quelli NoSQL.
Rispetto ai relational database dove le prestazioni delle query diminuiscono con
laumentare dei dati, nei graph database le prestazioni rimangono costanti anche
allaumentare dei dati, poich, grazie allindex-free adjacency, le query si riferiscono
solo ad una porzione di grafo. Questo fa si che il tempo sia proporzionale solo alla
parte di grafo da attraversare.

Flessibilit
I graph database, al contrario dei relational che possiedono uno schema fisso, sono
schema-less. Questo gli permette di adattarsi allevolversi del dominio applicativo
senza dover rimodellare e convertire lintera base di dati. Il grafo naturalmente
additivo, quindi possibile aggiungere nuovi nodi, relazioni e sottografi a una
struttura senza turbare le funzionalit e le query costruite per la versione precedente
del database.

Ci sono comunque anche aspetti svantaggiosi del graph database uno dei quali il
fatto che molti dei graph database (come ad esempio Neo4j) siano relativamente
giovani ed abbiano un pi basso livello di maturit rispetto ai database relazionali
[9]. Con maturit ci riferiamo a quanto il sistema stato testato: infatti se un sistema
stato testato un numero maggiore di volte, significa che pi stabile e sono stati
trovati e corretti un numero maggiore di errori.
I database relazionali hanno fornito supporti di memorizzazione per decine di anni,
questo li ha resi maturi e stabili, inoltre essi hanno anche un linguaggio standard,
SQL, che fa si che il supporto per una implementazione del database possa essere
applicato ed utilizzato anche ad altre implementazioni.
Inoltre un sistema database relazionale come MySQL ha un ampio supporto
multiutente, mentre alcuni graph database, come ad esempio Neo4j, non hanno
allinterno della loro struttura un meccanismo di gestione della sicurezza e degli

27
accessi multiutente (la Access Control List viene gestita solo a livello di applicazione)
[9].

CAPITOLO 3 NEO4J

Neo4j [5][11] un database a grafo open source, completamente transazionale,

supportato da Neo Technology, utilizza il modello property graph ed sviluppato
interamente in Java.
Il Neo4j possiede le seguenti caratteristiche principali:
Usa un modello a grafo per rappresentare i dati;
Le transazioni seguono le propriet ACID;
Pu memorizzare fino a diversi miliardi di nodi, relationship e propriet;
Possiede linguaggi di interrogazione dichiarativi ed espressivi;
Possiede unalta velocit di interrogazione tramite attraversamenti del grafo;
schema-less;
Non possiede una politica di accesso controllata;
Pu essere usato sia in modalit server che embedded.
Per chiarire questultimo punto, un database in modalit embedded incorporato nel
software applicativo mentre in modalit server il database un processo a s stante a
cui si accede tramite REST[2] facendo query e ricevendo i dati in remoto.

28
REST (Representational State Transfer) possiamo definirlo come l'insieme di metodi
per prendere (Get) inviare (Post) ed eliminare (Delete) risorse (ad esempio pagine
web) attraverso il protocollo http.

3.1 Architettura

FIGURA 12 Architettura di Neo4j.

La struttura base di un server Neo4j pu essere rappresentata come in figura 12.

Se si guarda la sua architettura si notano alla base i dischi allinterno dei quali i dati
vengono memorizzati sotto forma di record file, un sistema di caching per velocizzare
il recupero dei dati, il transaction module che include il transaction log e il
transaction management grazie al quale vengono garantite le propriet ACID delle
transazioni, un modulo HA (high availability) che caratterizza la capacita di clustering
del sistema e infine nello strato superiore le API (application programming interface)
che forniscono linterfaccia [10].

3.1.1 Struttura di Storage

Tutti i dati e le informazioni del grafo che il server storicizza e gestisce vengono
salvate allinterno di una serie di file che prendono il nome di Store File i quali
vengono memorizzati allinterno di ununica cartella, detta Cartella di Database.
I dati sui nodi nel database Neo4j sono memorizzati in un file chiamato
neostore.nodestore.db allinterno del disco. Ogni elemento salvato negli store file per

29
i nodi possiede una lunghezza fissa di memorizzazione chiamata record (ci avviene
nella maggior parte degli store file di Neo4j).

FIGURA 13 Struttura del record dei nodi.

Nella figura vediamo il record dello store file per i nodi, e ogni record ha una
lunghezza di 9 byte. Il primo byte rappresenta un flag che ci dice se il record
impegnato o meno per salvare i dati di un nodo, i successivi quattro byte
rappresentano lID della prima relazione connessa al nodo, i restanti quattro byte
rappresentano invece lID della prima propriet del nodo.
La lunghezza fissa permette una ricerca pi rapida dei nodi allinterno dello store file,
ad esempio se abbiamo che un nodo ha ID 100 baster scorrere fino al 900 byte
allinterno del file e cos il database pu effettuare ricerche velocissime ad un costo
inferiore.

FIGURA 14 Struttura del record delle relazioni.

I dati delle relazioni nel database Neo4j sono memorizzati in un file chiamato
neostore.relationshipstore.db allinterno del disco. Come lo store file dei nodi, quello
delle relazioni contiene un record di dimensione fissa (come quello in figura 12) di 33
byte. Ogni record contiene, oltre al flag, gli ID del nodo di partenza e di arrivo, il
puntatore al tipo di relazione, i puntatori ai record della precedente e prossima

30
relazione del nodo di partenza e arrivo. Gli ultimi 4 byte invece contengono lID della
prima propriet della relazione.

FIGURA 15 Struttura del record delle propriet.

I dati delle propriet sono memorizzati nel file chiamato neostore.propertystore.db sul
disco. Anche i record delle propriet sono lunghi 33 byte e come al solito il primo
byte occupato dal flag. I successi byte sono occupati in ordine dal puntatore al tipo
di propriet, dal puntatore allindice, da un blocco di memorizzazione e infine lId
della successiva propriet dellelemento a cui appartiene. Il blocco di
memorizzazione conterr il valore della propriet solo nel caso in cui il valore sia di
piccole dimensioni, invece, nel caso in cui la propriet sia composta array o lunghe
stringhe, questi valori saranno salvati in dynamicStore record con dimensioni di 125
byte contenuti in appositi store file (neostore.propertystore.db.strings nel caso siano
stringhe, neostore.propertystore.db.arrays nel caso si tratti di array).

3.1.2 Cache

Con il termine Cache si intende unarea di memoria di piccole dimensioni ed

estremamente veloce che immagazzina le informazioni pi frequentemente usate, in
modo da rileggerle velocemente.
In Neo4j esistono due diversi tipi di cache:
- File Buffer Cache;
- Object Cache;

Il File Buffer Cache pu essere anche chiamato low level cache o file system cache.
Questultimo agisce sugli store file memorizzati permanentemente sul disco,
caricando in memoria porzioni di questi con lo scopo di migliorare le performance di

31
scrittura e lettura. Il File System Cache migliora le prestazioni scrivendo sulle cache e
posticipando la scrittura permanente su disco fino alla rotazione del logical log
(ovvero loperazione di archiviazione dei vecchi log file). Questo comportamento
sicuro in quanto tutte le operazioni sono permanentemente scritte nel registro logico,
il quale pu infatti essere utilizzato per recuperare i file dell'archivio in caso di crash.
Ogni store file viene suddiviso dal File System Cache in un numero di regioni dalle
stesse dimensioni e carica in memoria le regioni di store file pi utilizzate. Quando
una regione non caricata nella cache supera in numero di utilizzi una caricata, la
prima rimpiazza la seconda (si segue la politica least recently used) [5].

La Object Cache pu essere chiamata high level cache.

Questultima agisce ad alto livello, memorizzando singoli nodi, relazioni e le loro
propriet, in forma di oggetti con una rappresentazione orientata a supportare le API
di Neo4j e lattraversamento del grafo, consentendo quindi di migliorare proprio la
velocit di attraversamento. Le operazioni di lettura possono essere da 5 a 10 volte
pi veloci rispetto a quelle della File Buffer Cache[5].
Mentre nel disco i record delle relazioni contengono la maggior parte delle
informazioni e quelli dei nodi contengono solo i riferimenti alla loro prima relazione,
negli Object Cache la situazione si inverte. Qui infatti i nodi tengono i riferimenti a
tutte le relazioni e i record delle relazioni si semplificano notevolmente mantenendo
solo lID delle propriet.

3.1.3 Transaction Module

Allinterno del transaction module possibile trovare il transaction management e il

transaction log che si occupano di garantire le propriet ACID dalle transazioni di
Neo4j.
Proprio poich vengono garantite queste propriet, la gestione delle transazioni in
Neo4j abbastanza simile a quella che avviene nei database relazionali nei quali
vengono eseguiti rollback (unoperazione che permette di riportare il database ad uno
stato corretto precedente ad un eventuale guasto) nel caso la transazione non sia stata
completata correttamente e utilizzati lock (veri e propri blocchi di lettura e scrittura

32
per limitare laccesso ad una risorsa condivisa in un ambiente multitasking) per
garantire lisolamento e la consistenza delle operazioni di lettura e scrittura.
Le transazioni in Neo4j possono racchiudere al loro interno altre transazioni annidate
(nested transaction), ognuna delle quali se non completata correttamente pu
comportare il rollback della transazione madre a cui appartiene e di tutte le altre
transazioni che dipendono da questultima.

Il transaction log un processo che gestisce il diario, cio una memoria stabile
dove vengono registrate le azioni svolte dalle transazioni. Questa componente
importantissima per mantenere il database in uno stato consistente anche in caso di
guasto, infatti, senza il transaction log sarebbe impossibile eseguire il rollback.

3.1.4 Neo4j High Availability (HA)

FIGURA 16 Neo4j HA cluster structure

Neo4j HA una struttura cluster di tipo Master/Slave che stata progettata per
rendere il sistema in grado di fornire un servizio di erogazione continuo dei dati.
Neo4j HA fornisce principalmente le seguenti funzionalit:

33
 Una faul-tolerant database architecture [5], dove diversi database (Slave)
possono essere configurati per essere lesatta copia di un singolo database
(Master) e ci permette al sistema di essere completamente funzionale sia in
lettura che in scrittura in caso di un hadware failure, in altre parole nel caso
una macchina che compone il cluster si rompa.
Fornisce una horizontally scaling read-mostly architectur [5] che permette al
sistema di trattare meglio i carichi di lettura di quanto possa fare un singolo
database.

La Neo4j cluster structure composta da un Load Balancer la cui funzione quella di

ricevere gli ordini di lettura e scrittura da parte delle applicazioni e di assegnarle ai
Server. Il Load Balancer di solito esegue le operazioni di scrittura sul Master mentre
gli Slave sono successivamente sincronizzati con il Master tramite il HA Cluster
Protocol, cos che ogni nodo possa mantenere dati aggiornati e consistenti. Nel caso
invece loperazione di scrittura venga eseguita su uno Slave, questa verr per prima
cosa sincronizzata con il master e non sar considerata conclusa finche non ci sar
stato il COMMIT (segnale che la transazione si conclusa con successo) su entrambi
i server. Questultimo approccio sicuramente pi sicuro rispetto al primo (poich le
transazioni sono eseguite su due server anzich uno), ma daltro canto risulta anche
pi lento. Le operazioni di lettura sono molto pi semplici (poich non richiedono
transazioni) e sono trattate da ogni nodo [10].
Zookeeper service un componente che monitora lo stato dei Service e, nel caso di
failure da parte del Master node, ne elegge uno nuovo. Normalmente, quando ci
accade, un nuovo master viene eletto e diviene attivo nel giro di pochi secondi e
durante questo periodo nessuna operazione di scrittura pu avvenire, esse vengono
bloccate.
Il Cluster Manager si occupa invece di gestire Zookeper Service e lo stesso Load
Balcer, fornendo le istruzioni di configurazione del cluster e evidenziando quali sono
le istanze di database disponibili.

3.1.5 API

34
I programmatori di sistema raramente interagiscono direttamente con il file system o
con le cache in quanto preferiscono utilizzare altri strumenti: le API.
La sigla API sta per Application Programming Interface, e corrisponde ad un insieme
di procedure disponibili al programmatore che permettono di interagire con una
tecnologia senza dover conoscere e gestire i meccanismi interni della tecnologia in
questione.
Neo4j mette a disposizione diverse API:
Core Java API. una Java API imperativa che permette di eseguire
operazioni di interrogazione, creazione, eliminazione e modifica tramite
codice Java. Essendo imperativa bisogna riprodurre la struttura del grafo
allinterno del codice Java.
Traversal API. una Java API dichiarativa con la quale possibile interrogare
il grafo semplicemente indicando i vincoli generali che permettono di limitare
lattraversamento (come ad esempio specificare quale tipo di relationship
seguire e la profondit con cui attraversare il grafo).
Cypher. un linguaggio dichiarativo proprio di Neo4j ispirato a SQL e, oltre a
risultare molto semplice, consente di effettuare query espressive ed efficienti
(lo vedremo descritto pi nel dettaglio nel prossimo paragrafo).

Quando Neo4j funziona in modalit server si parla di REST API. Le API, di cui
munito il server, permettono ai client di spedire richieste in formato JSON (JavaScript
Object Notation, un formato adatto all'interscambio di dati fra applicazioni client-
server) prevalentemente per mezzo del protocollo HTTP.

3.2 Cypher query language

Cypher [4][5] come gi detto un linguaggio dichiarativo ispirato a SQL che

permette agli utenti o alle applicazioni di interrogare il database sfruttando il concetto
di pattern (sottografi). Loperazione con cui viene ritrovato uno specifico pattern
allinterno del grafo viene chiamata graph pattern matching.

35
Come la maggior parte dei linguaggi query, Cypher composto da clausole le pi
importanti delle quali sono sicuramente la clausola START, MATCH e RETURN.
Un esempio di query potrebbe essere:

START A = node:people(name:Luca)
MATCH (A)-[:KNOWS]->(B)-[:KNOWS]->(C); (A)-[:KNOWS]->(C)
RETURN B, C;

- START
Indica uno o pi punti di partenza, che possono essere nodi o relationship, allinterno
del grafo. Essi sono ottenuti per mezzo di ricerche attraverso un indice, o pi
raramente, con un accesso diretto ad un nodo o ad una relazione per mezzo di ID.
Nellesempio si cerca un nodo per mezzo dellindice chiamato people che possegga
la propriet name con valore Luca. A invece sar lidentificatore di tale nodo
(o nodi) di partenza e servir per far riferimento al nodo di partenza allinterno della
nostra query.

-MATCH
Questa clausola permette a un utente o ad una applicazione di descrivere i pattern che
verranno poi trovati dal database.
Per descrivere questi pattern si usano i caratteri ASCII (codice standard americano per
la codifica dei caratteri). Vengono usate le parentesi tonde per indicare i nodi, e
coppie di trattini (-) seguiti dal segno di maggiore o minore (che indicano la direzione
della relazione) per disegnare le relazioni (- - > e <- -). In mezzo ai trattini, allinterno
delle parentesi quadre e prefissato dai due punti, presente il nome del tipo di
relazione.
Il pattern del nostro esempio risulter come segue:

36
FIGURA 17 Pattern della clausola MATCH: (A)-[:KNOWS]->(B)-[:KNOWS]->(C);
(A)-[:KNOWS]->(C).
Questo pattern che collega i tre nodi (A, B, C) attraverso le relationship KNOWS
potrebbe teoricamente ricorrere molte volte allinterno del grafo. Anche per questo
infatti viene utilizzata la clausola START che, nel nostro caso, circoscrive A a solo
quei nodi che possiedono lattributo name con il valore Luca.
Grazie alla clausola MATCH si evitano quindi le costose operazioni di JOIN.

-RETURN
Questa clausola specifica quali nodi, relationship e propriet devono essere restituiti.
Con riferimento allesempio, i nodi di interesse sono quelli legati agli identificatori
B e C.
Altre clausole utilizzate da Cypher sono:
- WHERE: fornisce condizioni per filtrare i risultati ottenuti dal match;

- CREATE e CREATE UNIQUE: crea nodi e relationship;

- DELETE: rimuove nodi, relationship e propriet;

- SET: stabilisce i valori associati alle propriet;

- UNION: unisce i risultati di due o pi query;

- WITH: divide una query in multiple parti distinte.

3.3 Confronto prestazionale tra API

37
Come visto nei paragrafi precedenti Neo4j possiede diversi metodi per interrogare e
interagire coi dati: Core Java API, Traversal API e Cypher.
In questo paragrafo si analizzeranno e confronteranno con dei test le performance dei
differenti metodi di interrogazione del database Neo4j.
Il modello base del test [10] rappresentato in figura 18:

FIGURA 18 Modello base del test

In questo modello ci saranno due tipi di nodi: i nodi composti dagli autori (author) e i
nodi delle pubblicazioni o saggi (paper). I saggi saranno collegati agli autori (o
allautore) che li hanno scritti attraverso delle relationship orientate [author] mentre
nel caso una pubblicazione faccia riferimento ad unaltra, queste, si collegheranno
con le reletionship [ref].
I test saranno effettuati su basi di dati di due dimensioni diverse e per mezzo di due
query con complessit differenti come riassunto nella tabella seguente.

Risultati del test

Qui di seguito elenchiamo i risultati dei vari test, ognuno dei quali differisce dallaltro
per la dimensione del database scelta (Data1 o Data 2) e/o per tipo di query utilizzata
(Complexity1 o Complexity2). Per mostrare la scalabilit del sistema si utilizza un
numero di query (che ricordiamo possono essere di del tipo Complexity1 o
Complexity2) che va da 10 a 9000, il tempo di risposta a tali query espresso in
secondi.

38
1. Data1 e Complexity1:

FIGURA 19 Risultato del Test

2. Data1 e Complexity2:

FIGURA 20 Risultato Test 2

3. Data2 e Complexity1:

FIGURA 21 Risultato test 3

4. Data2 e Complexity2:

39
 FIGURA 22 Risultato Test 4
Analizzando i risultati dei test, le Core Java API forniscono lapproccio pi veloce
nellinterrogare il database mentre Cypher risulta nettamente il pi lento.
La motivazione dovuta al fatto che Cypher, utilizzando un linguaggio dichiarativo,
nel codice di interrogazione esprimer solo cosa si vuole ottenere tralasciando il
compito di definire il come ottenerlo alla macchina che di conseguenza avr un
compito pi oneroso. Daltro canto Cypher risulta un linguaggio pi astratto e
semplice dal punto di vista sintattico e per questo spesso preferibile alle Core Java
API. Le Traversal API risultano un buon compromesso tra i due linguaggi sopra citati.

Linfluenza della dimensione del database nella performance

Un aspetto che si pu notare confrontando le figure 19 e 21 che, quando il query
number piccolo, la dimensione del database non influenza le performance, mentre
quando risulta elevato la differenza di costo diventa molto sensibile, risultando molto
pi lenta nei database di maggiori dimensioni (figura 19). Dalla curva di figura 19 si
nota anche come la dimensione del database abbia un impatto molto pi evidente per
Cypher rispetto alle Core Java API o alle Traversal API.

Linfluenza della complessit dellinterrogazione nella performance

Le figure 19, 20, mostrano che allinterno di database delle stesse dimensioni il tempo
di risposta a una interrogazione non subisce linfluenza della complessit della query
quando il query number basso. Con laumentare di questo valore invece la

40
complessit della query influenza notevolmente il costo della performance (maggiore
sar la complessit maggiore sar il costo a parit di query number).

3.4 Confronto prestazionale tra Neo4j e MySQL

In questo capitolo si cerca di confrontare le capacit di Neo4j e MySQL nel trattare

dati connessi che possono essere rappresentati con una struttura a grafo.
La struttura a grafo piuttosto comune ed esempi reali sono i social network, i
chemical/biological network (per rappresentare legami molecolari e le mappe
genetiche) e i road network (per rappresentare i percorsi stradali).
Il benchmark effettuato da un punto di vista oggettivo testando:
-le loro prestazioni nel rispondere ad un predefinito insieme di query;
-lo spazio di archiviazione richiesto;
-la scalabilit;
da un punto di vista pi soggettivo valutando:
-maturit;
-facilit di programmazione;
-flessibilit.

Progettazione del test

Per testare i due database si creano 12 grafi in cui ogni nodo contiene una propriet.
I valori delle propriet di 4 dei grafi saranno integer (numeri interi), dei successivi 4
saranno string (stringhe o sequenze di caratteri) da 8KB e degli ultimi 4 sempre
stringhe da 32KB. Si utilizzano 4 grafi di ogni tipo in modo tale che il primo
contenga 1000 nodi, il secondo 5000, il terzo 10000 e il quarto 100000 nodi (vedi
figura 23) [13] cos da valutare la scalabilit.
Seguendo le precedenti disposizioni, la struttura di ciascun grafo generata
casualmente da un programma.
Successivamente ognuno dei grafi memorizzato in un database MySQL e in un
database Neo4j come mostra la figura 23 nella quale viene riportato anche lo spazio
di archiviazione richiesto dai due database.

41
 FIGURA 23 Database del test

Per memorizzare i grafi nel relational database (MySQL) si utilizzano due tabelle:
- node con gli attributi nodeId(ovvero lidentificatore del nodo) e propriet;
- edge con gli attributi source(che indica il nodo di partenza) e sink(che indica il
nome di arrivo).

Query
Per testare il database si effettuano sei interrogazioni che si possono dividere in due
categorie: structural query e data query. La differenza tra questi due tipi di query
dovuta al fatto che le prime, al contrario delle seconde, si riferiscono solamente alla
struttura del grafo e non alle propriet dei nodi contenuti in esso.
Le structural query sono:
S0: trovare tutti i nodi orfani (cio senza archi in entrata e in uscita) allinterno del
grafo.
S4: attraversare il grafo fino a profondit 4 e determinare il numero di nodi trovati.
S128: attraversare il grafo fino a profondit 128 e determinare il numero di nodi
trovati.
Le data query sono:
I1: determinare il numero dei nodi che hanno una propriet con valore (integer)
uguale ad un certo valore assegnato.
I2: determinare il numero dei nodi che hanno una propriet con valore (integer)
inferiore ad un certo valore assegnato.

42
C1: determinare il numero di nodi le cui propriet contengono una certa stringa (o
sequenza di caratteri).
Il linguaggio utilizzato da MySQL per interrogare i dati ovviamente SQL, mentre
per Neo4j sono state utilizzate le traversal API.

Risultati
Nelle seguenti tabelle sono riportati i risultati in termini temporali delle interrogazioni
descritte le paragrafo precedente.

FIGURA 24 Risultati delle structural query S4, S128, S0 in millisecondi.

FIGURA 25 Risultati delle data query I1, I2 in millisecondi.

FIGURA 26 Risultati della data query C1 in millisecondi. Il test stato fatto per
stringhe di dimensioni diverse (da 4 a 8 caratteri).

Valutazioni oggettive

43
Per le query S4 e S128 Neo4j risulta nella maggior parte dei casi nettamente pi
rapido (figura 24). Questo dovuto al fatto che Neo4j pu sfruttare, anche grazie
allindex free adjacency, lattraversamento del grafo che da un nodo gli permette di
risalire attraverso le sue relazioni ad altri nodi ad esso collegati. Questo tipo di
operazione non supportata dai database relazionali che invece dovranno effettuare
costose operazioni di join. Linterrogazione S0 offre risultati pi simili in termini
prestazionali poich per i nodi orfani, non avendo archi ad essi collegati, non
possibile sfruttare lattraversamento del grafo.
Le data query per i database contenenti dati di tipo integer (I1, I2) mostrano una
maggiore efficacia del database relazionale (figura 25), questo dovuto
principalmente al fatto che Neo4j utilizza un servizio di indicizzazione basato su
Lucene [13] (una libreria che fornisce il servizio di definizione e costruzione degli
indici) che sfrutta una ricerca di tipo full-text. Questo tipo di ricerca trattando tutti i
dati come dati di testo non risulta particolarmente efficace per le query I1 e I2.
Linterrogazione C1 (figura 26) fornisce riscontri interessanti, infatti nei database di
minori dimensioni (quelli da 1000 nodi) le prestazioni di MySQL sono simili ed
addirittura migliori di quelle di Neo4j, aumentando invece le dimensioni, Neo4j
risulta nettamente pi veloce dimostrando una scalabilit migliore.
Da figura 23 si nota per come Neo4j richieda mediamente uno spazio di
archiviazione superiore a quello di MySQL.

Valutazioni soggettive
Questo tipo di valutazioni non sono quantificabili in termini numerici, ma sono
comunque importanti nel momento in cui si debba scegliere quale tipo di database
utilizzare. Le caratteristiche che si andranno ad analizzare e confrontare saranno:
maturit, facilit di programmazione e flessibilit.
Si parla di sistema maturo quando questo stato testato a fondo, infatti, pi
test sono effettuati maggiori saranno i bug identificati e di conseguenza il
sistema stabile. I relational database sono sicuramente il tipo di base di dati
pi utilizzati al mondo, questi sono impiegato in ambiti commerciali e di
ricerca accademica e hanno generato diverse commercial ventures, come ad
esempio Oracle [13] e Microsoft [13] che hanno investito molto in questi

44
 database. Invece i database a grafo, in generale, hanno una minore
penetrazione del mercato dovuta soprattutto al fatto che manca un linguaggio
di interrogazione unico ed anche per questo sono meno maturi di quelli
relazionali.
Il fatto di avere un linguaggio di programmazione unico rende la transazioni
tra implementazioni diverse pi semplice nei database relazionali che in quelli
a grafo. La facilit nello scrivere query invece dipende molto dal tipo di
interrogazioni, ad esempio scrivere query di attraversamento in Neo4j risulta
molto pi semplice poich le traversal API contengono algoritmi per farlo
facilmente al contrario di MySQL che, invece, dovr eseguire diversi join. Al
contrario ricercare il valore di un attributo allinterno della base di dati di pu
risultare meno costoso in un database relazionale (anche se le prestazioni dei
graph database dipendono molto dallindicizzazione utilizzata)
Neo4j essendo un graph database risulta molto pi flessibile di MySQL
poich, come gi stato spiegato nel capitolo precedente, i database a grafo
non possiedono uno schema fisso.
CONCLUSIONI

In questa tesi, dopo una breve introduzione allambito dei database NoSQL, stato
presentato un confronto tra i database a grafo e quelli relazionali analizzandone i
modelli, le transazioni, gli indici, la programmazione ed infine le prestazioni per le
quali sono state effettuate interrogazioni sul database relazionale MySQL e quello a
grafo Neo4j.
Il modello relazionale confrontato con quello a grafo ha mostrato limiti soprattutto dal
punto di vista della flessibilit e delle prestazioni (soprattutto per grandi quantit di
dati) mentre risultato migliore in maturit, consistenza e sicurezza.
Dallanalisi svolta nella tesi si pu concludere che definire quale sia il miglior
database da utilizzare dipende molto dai casi duso.
Sicuramente i graph database, in particolare Neo4j, funzionano molto bene nel
rappresentare dati connessi e nel rispondere in maniera rapida alle query che
richiedono l attraversamento del grafo, mentre i database relazionali sono perfetti nel

45
rappresentare dati strutturati. Entrambi i database presentano quindi aspetti positivi e
negativi e una pi appropriata area di applicazione.
Si pu per dire che ad oggi i dati in molte realt sono sempre pi connessi e le
quantit dei dati da gestire sono sempre maggiori e mutevoli (caratteristica che
richiede flessibilit del modello). Queste caratteristiche sono sicuramente meglio
supportate dai database a grafo che per questo negli ultimi anni sta suscitando tanto
interesse da parte di grossi colossi come Google o Facebook ed eBay[5] che utilizza
proprio Neo4j come piattaforma per immagazzinare e gestire i dati.

Bibliografia

[1] Renzo Angles and Claudio Gutierrez. Survey of graph database models. IEEE
28th International Conference on Data Engineering Workshops, pp 171-176, 2012.

[2] Wikipedia. (http://www.wikipedia.org)

[3] Mehak Gupta. A Novel Approach to Transform Relational Database into Graph
Database using Neo4j. Computer Science and engineering department Thapar
university, 2014.

[4] Ian, Robinson, Jim Webber and Emil Eifrem. Graph Databases. OReilly
Media Inc., 2013.

[5] Manuale Online di Neo4j v2.3.2 (Febbraio - Marzo 2014)

46
[6] Jaroslav Pokorn. Graph Databases: Their Power and Limitations.
International Federation for Information Processing (IFIP), pp. 5869, 2015.

[7] Dimitri De Franciscis. Database relazionali e NoSQL a confronto. 2013.

[8] Roberto De Virgilio, Antonio Maccioni and Riccardo Torlone. Model-Driven

Design of Graph Databases. Dipartimento di Ingegneria Universit`a Roma Tre,
Rome, Italy, pp. 172185, 2014.

[9] Shalini Batra and Charu Tyagi. Comparative Analysis of Relational And Graph
Databases. International Journal of Soft Computing and Engineering (IJSCE),
Volume-2, Issue-2, 2012.

[10] Hongcheng Huang, Ziyu Dong. Research on architecture and query

performance based on distributed graph database Neo4j. Chongqing University of
Posts and Telecommunications, 2013.

[11] Pradeep. D. Jadhav, Ruhi Oberoi. Comparative Analysis of Different Graph

Databases. International Journal of Engineering Research & Technology (IJERT),
Vol. 3 Issue 9, 2014.

[12] Florian Holzschuher and Prof. Dr. Ren Peinl. Performance of Graph Query
Languages. Comparison of Cypher, Gremlin and Native Access in Neo4j. Institute
for Information Systems (iisys) Hof University Alfons-Goppel-Platz 1 DE-95028
Hof, Germany , 2013.

[13] Chad Vicknair, Michael Macias, Zhendong Zhao, Xiaofei Nan, Yixin Chen and
Dawn Wilkins. A Comparison of a Graph Database and a Relational Database.
Department of Computer and Information Science University of Mississippi, 2010.

47