You are on page 1of 47

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 NoSQL…………………………………………………………………7
1.2.1 Categorie di sistemi database NoSQL……………………………………....7
1.3 Cos’è un Grafo? …………………………………………………………………..9
1.3.1 Il Property Graph Model……………………………………………………10
1.4 I graph DBMS……………………………………………………………………11

CAPITOLO 2 RELATIONAL VS GRAPH DATABASE..………………………...13
2.1 Modello dei Dati…………………………………………………………………13
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 Architettura………………………………………………………………………28
3.1.1 Struttura di Storage………………………………………………………...29
3.1.2 Cache………………………………………………………………………31
3.1.3 Transaction Module………………………………………………………..32
3.1.4 Neo4j High Availability (HA)……………………………………………..33
3.1.5 API…………………………………………………………………………34
3.2 Cypher query language…………………………………………………………..35
3.3 Confronto prestazionale tra API…………………………………………………37
3.4 Confronto prestazionale tra Neo4j e MySQL……………………………………40

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 l’efficienza
dell’informazione, 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 dell’introduzione 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 l’intera totalità dei
casi d’uso che si presentavano nel mondo reale. Con l’avvento di Internet e
l’affermarsi 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, quest’ultimo DBMS sarà approfondito nel terzo capitolo della tesi.
CAPITOLO 1 I GRAPH DATABASE

4

1. regole. le ellissi determinano le teorie dalle quali si sono sviluppati e le frecce le varie influenze. 5 . un insieme di operazioni. 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. Come mostrato nella figura 1 [1] all’interno dei rettangoli vengono rappresentati i vari modelli che si sono sviluppati nel corso degli anni. I database model sono fondamentali per capire e utilizzare i graph database.1 Evoluzione dei modelli di database nel corso degli anni FIGURA 1 Evoluzione dei vari modelli di database. Negli ultimi quarant’anni si sono sviluppati diversi modelli di database.

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

Il termine NoSQL significa “not only SQL” . 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. I database NoSQL si dividono in quattro principali categorie. il database relazionale non è stato progettato per supportare la scalabilità orizzontale oggi caratteristica sempre più utile e necessaria [3].Come abbiamo visto il database relazionale fece la sua comparsa fin dagli anni ‘70 e anche per questo è ed è stato altamente utilizzato. ma ognuno può possedere differenti campi (o attributi) come vediamo in figura 2. I valori non seguono uno schema fisso. 7 . 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). Proprio grazie a questo suo prolungato utilizzo è stato molto sviluppato. 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à.1 Categorie di sistemi database NoSQL[3]  Key-value store Questo modello è sicuramente caratterizzato da strutture dati molto semplici. così da rendere possibili ottime performance (soprattutto in lettura). ma. SQL è il linguaggio comunemente usato nei database relazionali e viene spesso preso in rappresentanza dell’intero paradigma relazionale. nonostante questo. Essenzialmente i record sono memorizzati e recuperati usando una chiave che definisce univocamente il record. 1.2.

8 . questi campi possono anche contenere pezzi multipli di dati. 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. 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”. 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. Questa caratteristica fa sì che non ci sia uno spreco di spazio.  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. ma ogni record è memorizzato come un documento che possiede determinate caratteristiche. Al documento può essere aggiunto un qualsiasi numero di campi con qualsiasi lunghezza.  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. 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.

rendendoli capaci di adattarsi e rappresentare ogni tipo di dato. Qui di seguito approfondiremo quest’ultimo modello.E). con a∈V e b∈V. Già questo semplice esempio (figura 2) ci fa capire il potere espressivo dei grafi e di quanto siano intuitivi da comprendere. Più formalmente si dice grafo una coppia ordinata G = (V. 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. La teoria dei grafi si occupa di studiare i grafi. in questo caso. Un arco è una coppia (a.b) di vertici. Prendendo ad esempio il noto social network Twitter. Molte strutture dati come le organizzazioni gerarchiche. dicendoci. dove V è l’insieme dei nodi ed E è l’insieme degli archi. 1. così la teoria dei grafi è un altro concetto molto utilizzato in questa scienza. 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. nella figura 3 vediamo un piccolo network di utenti Twitter. collegati fra loro da archi o lati. l’automazione e anche altri concetti più semplici come la logica matematica e booleana collegano strettamente matematica e alla informatica). 9 . Le relazioni sono la chiave per comprendere il contesto semantico. chi è seguito da chi.3 Cos’è un Grafo? Come la matematica ha un ruolo importante nell’informatica (ad esempio molti concetti come la crittografia. Un grafo è una insieme di elementi detti nodi o vertici. I nodi nel grafo rappresentano le entità e gli archi le relazioni tra i nodi . i diagrammi di flusso e i social network sono rappresentati attraverso grafi [3].

10 . FIGURA 3 Un piccolo grafo che rappresenta un insieme di follower con l’aggiunta dei messaggi da parte di uno di questi. Le label indicano il ruolo dei nodi all’interno del database (Labeled Property Graph Model). ed hanno sempre un nodo di partenza e un nodo di arrivo. 1. due nodi possono condividere qualsiasi numero o tipo di relazioni senza sacrificare le performance di attraversamento del grafo. dove “chiave” è la stringa identificativa della proprietà.  I nodi possono essere contrassegnati da uno o più “label”. Il Property Graph ha le seguenti caratteristiche:  Contiene nodi e relazioni.1 Il Property Graph Model La variante più conosciuta del modello a grafo è quella del Property Graph Model. “valore” dipende invece dal tipo di dato.  Anche le relazioni possono possedere delle proprietà. Quando le relazioni sono immagazzinate efficientemente.  Le relazioni possiedono un nome e sono orientate.3.  I nodi contengono proprietà attraverso coppie chiave-valore.

sebbene semplice. è che una relazione connette sempre due nodi e che l’eliminazione di un nodo determina l’eliminazione delle relazioni ad essa associate.4 I graph DBMS Un Graph Database Management System è un sistema per la gestioni dei database. I Graph DBMS sono generalmente costruiti per essere utilizzati con i sistemi transazionali OLTP. Questo è un sistema software progettato per consentire la creazione. Vi sono due componenti dei graph database da tener in mente quando si vuole analizzare una tecnologia di questo tipo: 11 . ma riguardante tutti i grafi. FIGURA 4 Un building block del Property Graph 1. Di conseguenza sono normalmente ottimizzati per favorire le prestazioni e progettati per l’integrità e disponibilità delle operazioni transazionali. Molte persone trovano il Property Graph Model intuitivo e facile da capire. può essere usato per descrivere la stragrande maggioranza dei casi d’uso grafici. la manipolazione e l'interrogazione efficiente di database. in modo tale che diano indicazioni utili sui nostri dati. infatti.Un’importante caratteristica da ricordare a proposito dei Property Graph.

processing engine non nativo. o qualche altro tipo di data store. 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 l’accesso a un indice globale esterno.Data Storage Qualche Graph DBMS utilizza dei native graph storage [4]. ovvero all’interno di un database relazionale. 12 . FIGURA 5 Una panoramica dei modelli di alcuni graph database presenti oggi sul mercato. processing engine nativo (più performante). ovvero. di un database orientato agli oggetti. la prima formata da tutti quelli che sfruttano l’index-free adjancency. 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. la seconda quelli che non la usano. Processing Engine Possiamo distinguere i graph DBMS in due categorie. Questo comporta che ogni elemento contenga un puntatore diretto ai suoi elementi adiacenti rendendo così le ricerche via indice non necessarie.

garantendo. 13 .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). la consistenza dei dati. vale a dire SQL (Structured Query Language). Una volta che il modello dei dati è stato progettato in modo consistente. Tutti i dati all’interno 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. Questo modello si sviluppa intorno al concetto di relazione (o tabella). quindi. 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. FIGURA 6 Esempio di relazioni (tabelle) in un database relazionale.CAPITOLO 2 RELATIONAL VS GRAPH DATABASE 2. i dati possono essere inseriti e manipolati utilizzando il linguaggio strutturato standard dei database relazionali. detti perciò sistemi di gestione di basi di dati relazionali (RDBMS) [2].

pur essendo un modello ormai standard e molto utilizzato. motivo per cui spesso molte colonne rimangano parzialmente riempite [3].  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]. un attributo o una relazione utilizzata per descrivere una risorsa. Property (proprietà): indica una proprietà. i dati devono essere memorizzati usando un alto numero di tabelle. come ad esempio i network o i social. un’organizzazione non governativa internazionale che ha come scopo quello di sviluppare tutte le potenzialità del World Wide Web. Attualmente i modelli principali di riferimento per l’implementazione 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). Resource (risorsa): indica ciò che viene descritto mediante RDF.Il modello relazionale. Questo modello è basato su tre oggetti: . Il Relational Database supporta schemi molto rigidi poiché tutte le tuple in una relazione seguono lo stesso schema e quindi hanno le stesse colonne. infatti le operazioni di join hanno basse performance e non sono scalabili con il crescere del numero di tuple. 14 . . presenta diversi problemi:  In strutture con dati altamente interconnessi. 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. generando problemi a causa dell’elevato numero di operazioni join (operazioni molto costose di combinazione delle tuple appartenenti a due tabelle) necessarie per recuperare i dati.

ma solo per RDF esiste uno standard riconosciuto in SPARQL [2]. che formano una struttura a grafo in cui le risorse sono rappresentate dai nodi e i predicati dagli archi.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 all’interno di database relazionali. 2. si relazionano tra di loro. di conseguenza in questo tipo di schema non si presenterà il problema dei valori nulli e di allocare spazio per questi valori. Un aspetto negativo delle relationship all’interno database relazionale è che hanno ambiguità semantica poiché non specificano ad esempio il peso e la forza della 15 . 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. . anche se solitamente il passaggio da uno all'altro è molto intuitivo. Statement (espressione): è l'elemento che descrive una risorsa costituito da un soggetto che rappresenta la Resource. ma siccome i relational database erano inizialmente progettati per codificare strutture a tabelle. Quando si parla di relationship nei database relazionali si intende il modo in cui le tabelle. potevano sorgere difficoltà nel modellare questo tipo di dati [4]. 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. che contengono istanze diverse. Per entrambi esistono dei linguaggi di interrogazione specifici. al contrario di quelli relazionali. Ogni istanza di questo modello è quindi formato da un insieme di triple del tipo soggetto-predicato-oggetto. un predicato che esprime la Property e da un oggetto chiamato Value che indica il valore della proprietà. I due modelli (Property Grafh Model ed RDF) non sono del tutto coincidenti. Dal punto di vista della struttura i Graph Database.

16 . 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é. mantengono queste dipendenze semantiche. come network e social (molto diffusi ai giorni d’oggi). FIGURA 7 Esempio di un semplice schema di dati riguardanti le persone di un social network e le loro relative amicizie. l’operazione richiederebbe due join e quindi le query diventerebbero sintatticamente e computazionalmente più complesse e aumenterebbero di conseguenza il costo della risposta. a cui possono essere associate proprietà. 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” all’interno del database. Relationship nei Database a Grafo Quando ci sono dati connessi che includono dipendenze semantiche tra le entità. si può ridurre il numero di tuple attraverso la clausola WHERE. oltre a richiedere un solo join tra le tabelle. Il costo di un’operazione di interrogazione del database aumenta significativamente a seconda del numero di join che vengono eseguiti. Se ad esempio si volessero trovare gli amici degli amici di un determinato soggetto. il modello a grafo risulta molto più appropriato in quanto le relationship.relationship stessa e per di più le operazioni di join sono molto onerose in particolare all’interno di contesti altamente connessi.

FIGURA 8 Semplice esempio di social network. come invece avviene con le operazioni di join nei database relazionali. Il grafo offre un quadro più ricco di un contesto network.3 Linguaggi di interrogazione nei Database Relazionali e a Grafo I database relazionali per interrogare. Interrogare i dati per mezzo di questi attraversamenti ci evita di eseguire costose operazioni di raggruppamento sull’intero insieme di dati. inserire modificare e cancellare dati nel database. infatti dalla figura 8 possiamo capire intuitivamente chi è l’amico di chi o chi è collega di chi (attraverso la relationship FRIEND_OF o COLLEAGUE_OF) ed anche se questa relationship viene ricambiata. 2.Nel caso dei social network. Grazie alle relationship è inoltre possibile “attraversare” il grafo. 17 . semplice esempio di dati altamente connessi e network semi-strutturato. utilizzano lo standard SQL. cioè muoversi tra i nodi collegati dalle relationship. la struttura del modello risulterà come in figura 8. In questo social network le connessioni fra le entità non sono uniformi per tutto il dominio.

Data Control Language).  inserire.  interrogare i dati memorizzati (DQL . I graph database.Data Query Language). non possiedono un linguaggio di interrogazione standard. FROM.Data Definition Language). Per l’interrogazione dei dati SQL si basa sui tre comandi principali SELECT. modificare e gestire dati memorizzati (DML . Cypher è un linguaggio dichiarativo (ovvero un tipo di linguaggio che si focalizza sulla descrizione della proprietà considerata. nodo per nodo. Con questo linguaggio è possibile:  creare e modificare schemi di database (DDL . al contrario dei relational database.SQL è un linguaggio dichiarativo basato sull’algebra relazionale. 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. lasciando indeterminato l’algoritmo 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.Data Manipulation Language). Neo4j fornisce anche API Java native per l’interrogazione 18 . i linguaggi più utilizzati e famosi sono Cypher e Gremlin [12]. per mezzo delle relazioni che li collegano. La forza della graph query language si misura con la sua abilità di attraversare efficacemente il grafo che significa passare attraverso il grafo.  creare e gestire strumenti di controllo ed accesso ai dati (DCL .

19 . Sharding è una tecnica molto flessibile nella quale i nodi possono essere aggiunti quando i dati crescono e rimossi quando decrescono senza interessare l’applicazione. Per ottenere il primo tipo è necessario incrementare le capacità della macchina.  Replication significa i dati sono replicati su più nodi di una rete calcolatori. La scalabilità è di due tipi: verticale ed orizzontale. la qual cosa richiede un costo elevato. Queste presentano un grado di astrazione minore rispetto ai due linguaggi sopra citati ma un’ottima efficienza. rendendo quindi i dati più robusti. ma distribuiti su più nodi. Infatti se un nodo fallisce i dati persi possono essere recuperati da un altro nodo. 2. a causa della frammentarietà dei dati.  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. e si può ottenere con due tecniche: replication e sharding. Lo scalabilità nei database relazionali risulta un problema a causa delle operazioni di join. Questo significa che i dati possono non essere su una sola macchina. Inoltre incrementa le operazioni di lettura poiché si possono distribuire le operazioni di lettura su vari nodi. la prestazione peggiorerà poiché i dati devono essere modificati su tutti i nodi. si rende necessaria una grande comunicazione tra i nodi che richiederà un numero maggiore di join e quindi un costo maggiore. Per le operazioni di scrittura. questo è il motivo per cui i database NoSQL non supportano le operazioni di join. Per questo motivo la scalabilità orizzontale è molto più utilizzata.dei dati. invece.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. infatti.

La consistenza viene garantita nei database relazionali dal central locking system. 2. hanno optato per una più debole forma di consistenza (Eventual Consistency) in favore di una maggiore 20 . inclusi alcuni graph database. può risultare più complesso che distribuire i dati negli altri database NoSQL anche se comunque è possibile [6]. I nuovi database NoSQL. Queste proprietà consentono alle transazioni di eseguire operazioni corrette e sicure sulla base di dati.Scalare i dati di un grafo. Quando si distribuisce un grafo. grazie al quale i dati sono bloccati fino a quando non si raggiunge uno stato stabile.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 all’inizio della transazione [2].  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. Questo è dovuto alla natura molto connessa dei grafi. in sostanza.  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. 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).  Durabilità: i dati scritti sul database saranno memorizzati su disco e disponibili dopo il riavvio del database. è meglio evitare il più possibile di avere relazioni che abbraccino più nodi della rete di calcolatori. attraverso lo sharding.

Questi database seguono un paradigma chiamato BASE (Basically Available. Nel caso si scelga di rinunciare alla disponibilità (availability). Per evitare la partizione si potrebbero inserire tutti i dati in una sola macchina. Il sistema rimane indisponibile fin quando la modifica non sarà trasportata su tutti i nodi. 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.  Partition Tolerance (Tolleranza al Partizionamento): garantisce che il sistema rimanga funzionante nonostante la perdita di messaggi.disponibilità dei dati (High Availability).  Availability (disponibilità): si ha quando il sistema fornisce la garanzia di accesso e usabilità dei dati. per le operazioni di modifica. garantirà la consistenza rendendo i dati indisponibili per un certo tempo. Soft-state. a causa della quale i dati perdono la sincronizzazione. Il problema si presenta quando si crea partizione tra i nodi. ma questo porterebbe sicuramente limitazioni alla scalabilità. così che. I dati verranno però sincronizzati solo dopo che la partizione sarà risolta (si tratta appunto della Eventual Consistency). Nel caso in cui invece si scelga di penalizzare la consistenza (consistency). i nodi rimarranno online anche se non possono comunicare con gli altri. La differenza dei due sistemi è spiegabile attraverso il CAP theorem il quale. i sistemi non necessitano continuamente di consistenza. I problemi di inconsistenza di solito risultano più difficili da trattare. Eventually consistent). D’altro canto. 21 . Questa è l’idea seguita dalle proprietà ACID. in questi casi alcuni nodi possono rimanere isolati dagli altri e non avere più informazioni aggiornate (sono partizionati). 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 sistema. proposto per la prima volta da Eric Brewer [3] nel 2000. Nel caso si scelga di tralasciare la partition tolerance. ne gioveranno la disponibilità dei dati e la tolleranza di partizionamento.

. indice su EDGES. La creazione di indici è utile per un effettuare un più rapido accesso ai dati. Gli indici più utilizzati sono il B-Tree. VERTEX_FROM: ID del vertice di partenza. e senza quindi il bisogno di un indice globale [8]. Vari attributi per le informazioni contenute nel vertice (nome ecc…). VERTEX_TO: ID del vertice di arrivo. 2. . . Questo approccio però.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à: . comporta un grave problema: all'aumentare delle righe (soprattutto sulla tabella dei vertici).VERTEX_TO. I graph database offrono una soluzione diversa rispetto ai relazionali usando la tecnica è chiamata index-free adjacency. . Informazioni aggiuntive sulla relazione tra i vertici.  Creare indici aggiuntivi: . ID dell’arco. nonostante sia corretto.  Creare un’entità EDGES per gli archi con le proprietà: . nonostante siano database NoSQL. Il costo per una lettura tramite indice B-Tree infatti è dell'ordine di O(log(n)). indice su EDGES. .Una particolarità dei database a grafo è che. alcuni modelli supportano le proprietà ACID e questo è il caso di Neo4j come vedremo nel prossimo capitolo. Infatti. il costo in lettura aumenta sensibilmente. In altre parole ogni 22 . Per esaminare gli M archi in uscita dal vertice di partenza abbiamo quindi un costo computazionale C di C=(Mlog(n)) [7].VERTEX_FROM. dove n = numero totale di vertici del grafo. ID del vertice. per riuscire ad ottenere una lettura costante ogni singolo vertice ha un indice degli archi in uscita e questo permette di verificare l’esistenza di un arco tra due vertici del grafo semplicemente visitando uno dei due vertici. B+Tree o indici Hash.

2. fornito in ingresso dalla fase precedente. 23 . cioè un centro di elaborazione dei dati la cui struttura può essere rappresentata in figura 9 [4]. in uno schema logico di descrizione dei dati pertinente al tipo di DBMS scelto (quindi descritta con un linguaggio formale supportato dal DBMS).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) d’interesse in termini di un modello formale indipendente dal DBMS. rendendo indipendente le prestazioni dalle dimensioni globali del database e possibile l’analisi di grafi difficilmente gestibili con indici globali.  La progettazione logica che si pone come obiettivo quello di trasformare lo schema concettuale. 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.nodo porta le informazioni sui nodi a cui è relazionato. La descrizione attraverso tale modello produce uno schema concettuale.  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.

Sono stati proposti vari modelli concettuali ma il più famoso e utilizzato è sicuramente il diagramma Entity-Relationship (E-R). 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 dell’esempio precedente (figura 9). FIGURA 9 Esempio di Data Center. si può costruire il seguente diagramma E-R: 24 . 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. La maggior parte delle volte questo passaggio risulta informale ed avviene spesso attraverso schizzi alla lavagna a seguito di una discussione tra l’esperto in materia e l’architetto dei dati e del sistema. In riferimento all’esempio precedente. 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.

tale modello è il modello a grafo. tecnica che prevede la duplicazione dei dati al fine di acquisire migliori performance. con i loro rigidi schemi. Dopo questa fase la metodologia diverge poiché. che non sacrifica le prestazioni e che supporta l’evoluzione conservando l’integrità dei dati quando è sottoposto a rapidi cambiamenti. non sono certo uno strumento particolarmente buono per supportare rapidi cambiamenti. 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. risulta simile a quella relazionale. L’ultima fase che precede l’implementazione 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. Nel modello logico i dati sono strutturati in tabelle normalizzate per eliminare la ridondanza ed espresse con il linguaggio SQL. una denormalizzazione dei dati. invece di 25 . FIGURA 10 Un diagramma Entity-Relationship per un Data Center. quindi è necessario un modello strettamente allineato col dominio. Progettazione per le basi di dati a grafo I database relazionali. per migliorare l’efficienza e la velocità del database. La fase precedente alla progettazione. Questa traduzione viene fatta seguendo semplici regole standard e spesso viene fatta in modo automatico. cioè quella di raccolta dei requisiti.

si utilizza un grafo. si testa il modello per verificare se è adatto ad eseguire specifiche query e si correggono gli errori o imprecisioni eventuali.utilizzare un diagramma Entity-Relationship.8 Vantaggi dei Database a Grafo 26 . con lo scopo di produrre una accurata rappresentazione del dominio [4]. Nell’esempio 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). una volta creati i nodi e le relazioni sul graph database. 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. 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. In riferimento all’esempio è possibile costruire il modello a grafo di figura 11. Infine. 2.

non hanno all’interno della loro struttura un meccanismo di gestione della sicurezza e degli 27 . sono schema-less. nei graph database le prestazioni rimangono costanti anche all’aumentare dei dati. che fa si che il supporto per una implementazione del database possa essere applicato ed utilizzato anche ad altre implementazioni. come ad esempio Neo4j. al contrario dei relational che possiedono uno schema fisso. Inoltre un sistema database relazionale come MySQL ha un ampio supporto multiutente. SQL. Questo gli permette di adattarsi all’evolversi del dominio applicativo senza dover rimodellare e convertire l’intera base di dati. Flessibilità I graph database. quindi è possibile aggiungere nuovi nodi. questo li ha resi maturi e stabili. Con maturità ci riferiamo a quanto il sistema è stato testato: infatti se un sistema è stato testato un numero maggiore di volte. le query si riferiscono solo ad una porzione di grafo. mentre alcuni graph database. I database relazionali hanno fornito supporti di memorizzazione per decine di anni. relazioni e sottografi a una struttura senza turbare le funzionalità e le query costruite per la versione precedente del database. Questo fa si che il tempo sia proporzionale solo alla parte di grafo da attraversare. inoltre essi hanno anche un linguaggio standard. non solo rispetto ai database relazionali ma anche relativamente a quelli NoSQL. significa che è più stabile e sono stati trovati e corretti un numero maggiore di errori. poiché. Rispetto ai relational database dove le prestazioni delle query diminuiscono con l’aumentare dei dati. grazie all’index-free adjacency. Il grafo è naturalmente additivo. 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].Prestazioni Uno dei maggiori vantaggi portati dalla base di dati a grafo è il netto miglioramento delle prestazioni nel caso di dati fortemente connessi.

supportato da Neo Technology. Per chiarire quest’ultimo punto. 28 . relationship e proprietà.  Può essere usato sia in modalità server che embedded.  È schema-less. CAPITOLO 3 NEO4J Neo4j [5][11] è un database a grafo open source. completamente transazionale. Il Neo4j possiede le seguenti caratteristiche principali:  Usa un modello a grafo per rappresentare i dati.accessi multiutente (la Access Control List viene gestita solo a livello di applicazione) [9].  Non possiede una politica di accesso controllata. utilizza il modello property graph ed è sviluppato interamente in Java.  Può memorizzare fino a diversi miliardi di nodi.  Possiede linguaggi di interrogazione dichiarativi ed espressivi.  Possiede un’alta velocità di interrogazione tramite attraversamenti del grafo. 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.  Le transazioni seguono le proprietà ACID.

La struttura base di un server Neo4j può essere rappresentata come in figura 12. Ogni elemento salvato negli store file per 29 .1 Struttura di Storage Tutti i dati e le informazioni del grafo che il server storicizza e gestisce vengono salvate all’interno di una serie di file che prendono il nome di Store File i quali vengono memorizzati all’interno di un’unica cartella. 3. il transaction module che include il transaction log e il transaction management grazie al quale vengono garantite le proprietà ACID delle transazioni. I dati sui nodi nel database Neo4j sono memorizzati in un file chiamato neostore.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.1. Se si guarda la sua architettura si notano alla base i dischi all’interno dei quali i dati vengono memorizzati sotto forma di record file. detta Cartella di Database. un sistema di caching per velocizzare il recupero dei dati. 3. 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 l’interfaccia [10].nodestore.db all’interno del disco.1 Architettura FIGURA 12 Architettura di Neo4j.

i restanti quattro byte rappresentano invece l’ID della prima proprietà del nodo. i puntatori ai record della precedente e prossima 30 . La lunghezza fissa permette una ricerca più rapida dei nodi all’interno dello store file. gli ID del nodo di partenza e di arrivo. oltre al flag. I dati delle relazioni nel database Neo4j sono memorizzati in un file chiamato neostore.db all’interno del disco. Come lo store file dei nodi. il puntatore al tipo di relazione. ad esempio se abbiamo che un nodo ha ID 100 basterà scorrere fino al 900 byte all’interno del file e così il database può effettuare ricerche velocissime ad un costo inferiore. Il primo byte rappresenta un flag che ci dice se il record è impegnato o meno per salvare i dati di un nodo. quello delle relazioni contiene un record di dimensione fissa (come quello in figura 12) di 33 byte. Nella figura vediamo il record dello store file per i nodi. i successivi quattro byte rappresentano l’ID della prima relazione connessa al nodo. FIGURA 13 Struttura del record dei nodi.i nodi possiede una lunghezza fissa di memorizzazione chiamata record (ciò avviene nella maggior parte degli store file di Neo4j).relationshipstore. Ogni record contiene. e ogni record ha una lunghezza di 9 byte. FIGURA 14 Struttura del record delle relazioni.

dal puntatore all’indice. nel caso in cui la proprietà sia composta array o lunghe stringhe. 3. . neostore. da un blocco di memorizzazione e infine l’Id della successiva proprietà dell’elemento a cui appartiene. I dati delle proprietà sono memorizzati nel file chiamato neostore. Gli ultimi 4 byte invece contengono l’ID della prima proprietà della relazione. Quest’ultimo agisce sugli store file memorizzati permanentemente sul disco. questi valori saranno salvati in dynamicStore record con dimensioni di 125 byte contenuti in appositi store file (neostore.relazione del nodo di partenza e arrivo.1. Anche i record delle proprietà sono lunghi 33 byte e come al solito il primo byte è occupato dal flag.db.propertystore.strings nel caso siano stringhe. I successi byte sono occupati in ordine dal puntatore al tipo di proprietà. Il blocco di memorizzazione conterrà il valore della proprietà solo nel caso in cui il valore sia di piccole dimensioni. In Neo4j esistono due diversi tipi di cache: .arrays nel caso si tratti di array).propertystore. FIGURA 15 Struttura del record delle proprietà.2 Cache Con il termine Cache si intende un’area di memoria di piccole dimensioni ed estremamente veloce che immagazzina le informazioni più frequentemente usate.db. Object Cache.db sul disco. in modo da rileggerle velocemente. File Buffer Cache. invece. Il File Buffer Cache può essere anche chiamato low level cache o file system cache. caricando in memoria porzioni di questi con lo scopo di migliorare le performance di 31 .propertystore.

Questo comportamento è sicuro in quanto tutte le operazioni sono permanentemente scritte nel registro logico. in forma di oggetti con una rappresentazione orientata a supportare le API di Neo4j e l’attraversamento del grafo. negli Object Cache la situazione si inverte. La Object Cache può essere chiamata high level cache. Proprio poiché vengono garantite queste proprietà.1. Le operazioni di lettura possono essere da 5 a 10 volte più veloci rispetto a quelle della File Buffer Cache[5]. il quale può infatti essere utilizzato per recuperare i file dell'archivio in caso di crash. 3.scrittura e lettura. Qui infatti i nodi tengono i riferimenti a tutte le relazioni e i record delle relazioni si semplificano notevolmente mantenendo solo l’ID delle proprietà. Il File System Cache migliora le prestazioni scrivendo sulle cache e posticipando la scrittura permanente su disco fino alla rotazione del logical log (ovvero l’operazione di archiviazione dei vecchi log file). memorizzando singoli nodi. relazioni e le loro proprietà. la prima rimpiazza la seconda (si segue la politica least recently used) [5]. 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.3 Transaction Module All’interno del transaction module è possibile trovare il transaction management e il transaction log che si occupano di garantire le proprietà ACID dalle transazioni di Neo4j. consentendo quindi di migliorare proprio la velocità di attraversamento. Quest’ultima agisce ad alto livello. 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. la gestione delle transazioni in Neo4j è abbastanza simile a quella che avviene nei database relazionali nei quali vengono eseguiti rollback (un’operazione 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 . Quando una regione non caricata nella cache supera in numero di utilizzi una caricata.

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 quest’ultima. Neo4j HA fornisce principalmente le seguenti funzionalità: 33 .1. infatti. senza il transaction log sarebbe impossibile eseguire il rollback. Le transazioni in Neo4j possono racchiudere al loro interno altre transazioni annidate (nested transaction). Questa componente è importantissima per mantenere il database in uno stato consistente anche in caso di guasto.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. Il transaction log è un processo che gestisce il “diario”. cioè una memoria stabile dove vengono registrate le azioni svolte dalle transazioni.per limitare l’accesso ad una risorsa condivisa in un ambiente multitasking) per garantire l’isolamento e la consistenza delle operazioni di lettura e scrittura. 3.

nel caso di failure da parte del Master node.  Una faul-tolerant database architecture [5]. Le operazioni di lettura sono molto più semplici (poiché non richiedono transazioni) e sono trattate da ogni nodo [10]. 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. dove diversi database (Slave) possono essere configurati per essere l’esatta 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. 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. esse vengono bloccate. in altre parole nel caso una macchina che compone il cluster si “rompa”. Nel caso invece l’operazione di scrittura venga eseguita su uno Slave. quando ciò accade.  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. ma d’altro canto risulta anche più lento. ne elegge uno nuovo. 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. Zookeeper service è un componente che monitora lo stato dei Service e. Quest’ultimo approccio è sicuramente più sicuro rispetto al primo (poiché le transazioni sono eseguite su due server anziché uno). così che ogni nodo possa mantenere dati aggiornati e consistenti. fornendo le istruzioni di configurazione del cluster e evidenziando quali sono le istanze di database disponibili. Il Cluster Manager si occupa invece di gestire Zookeper Service e lo stesso Load Balcer.5 API 34 . 3. Normalmente. un nuovo master viene eletto e diviene attivo nel giro di pochi secondi e durante questo periodo nessuna operazione di scrittura può avvenire.1.

creazione.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). oltre a risultare molto semplice.I programmatori di sistema raramente interagiscono direttamente con il file system o con le cache in quanto preferiscono utilizzare altri strumenti: le API. di cui è munito il server. permettono ai client di spedire richieste in formato JSON (JavaScript Object Notation. È una Java API imperativa che permette di eseguire operazioni di interrogazione. Quando Neo4j funziona in modalità server si parla di REST API. 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. Le API. È una Java API dichiarativa con la quale è possibile interrogare il grafo semplicemente indicando i vincoli generali che permettono di limitare l’attraversamento (come ad esempio specificare quale tipo di relationship seguire e la profondità con cui attraversare il grafo).  Cypher. L’operazione con cui viene ritrovato uno specifico pattern all’interno del grafo viene chiamata graph pattern matching. un formato adatto all'interscambio di dati fra applicazioni client- server) prevalentemente per mezzo del protocollo HTTP. Neo4j mette a disposizione diverse API:  Core Java API.  Traversal API. eliminazione e modifica tramite codice Java. È un linguaggio dichiarativo proprio di Neo4j ispirato a SQL e. 35 . La sigla API sta per Application Programming Interface. 3. consente di effettuare query espressive ed efficienti (lo vedremo descritto più nel dettaglio nel prossimo paragrafo). Essendo imperativa bisogna riprodurre la struttura del grafo all’interno del codice Java.

. C. MATCH e RETURN. con un accesso diretto ad un nodo o ad una relazione per mezzo di ID. Il pattern del nostro esempio risulterà come segue: 36 .-). In mezzo ai trattini. all’interno delle parentesi quadre e prefissato dai due punti. Vengono usate le parentesi tonde per indicare i nodi. Cypher è composto da clausole le più importanti delle quali sono sicuramente la clausola START. e coppie di trattini (-) seguiti dal segno di maggiore o minore (che indicano la direzione della relazione) per disegnare le relazioni (.START Indica uno o più punti di partenza. Nell’esempio si cerca un nodo per mezzo dell’indice chiamato “people” che possegga la proprietà “name” con valore “Luca”.> e <.Come la maggior parte dei linguaggi query. Essi sono ottenuti per mezzo di ricerche attraverso un indice. che possono essere nodi o relationship. è presente il nome del tipo di relazione. Per descrivere questi pattern si usano i caratteri ASCII (codice standard americano per la codifica dei caratteri). (A)-[:KNOWS]->(C) RETURN B. -MATCH Questa clausola permette a un utente o ad una applicazione di descrivere i pattern che verranno poi trovati dal database.. Un esempio di query potrebbe essere: START A = node:people(name:‘Luca’) MATCH (A)-[:KNOWS]->(B)-[:KNOWS]->(C). o più raramente. all’interno del grafo. “A” invece sarà l’identificatore di tale nodo (o nodi) di partenza e servirà per far riferimento al nodo di partenza all’interno della nostra query.

Anche per questo infatti viene utilizzata la clausola START che. . Altre clausole utilizzate da Cypher sono: . 3. . C) attraverso le relationship “KNOWS” potrebbe teoricamente ricorrere molte volte all’interno del grafo. . . -RETURN Questa clausola specifica quali nodi.WHERE: fornisce condizioni per filtrare i risultati ottenuti dal match. relationship e proprietà devono essere restituiti. Grazie alla clausola MATCH si evitano quindi le costose operazioni di JOIN. Con riferimento all’esempio. Questo pattern che collega i tre nodi (A. i nodi di interesse sono quelli legati agli identificatori ‘B’ e ‘C’. circoscrive “A” a solo quei nodi che possiedono l’attributo “name” con il valore “Luca”. relationship e proprietà. B.3 Confronto prestazionale tra API 37 . (A)-[:KNOWS]->(C). nel nostro caso.DELETE: rimuove nodi.CREATE e CREATE UNIQUE: crea nodi e relationship.UNION: unisce i risultati di due o più query.FIGURA 17 Pattern della clausola MATCH: (A)-[:KNOWS]->(B)-[:KNOWS]->(C). .WITH: divide una query in multiple parti distinte.SET: stabilisce i valori associati alle proprietà.

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. Traversal API e Cypher. queste. 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. Risultati del test Qui di seguito elenchiamo i risultati dei vari test.Come visto nei paragrafi precedenti Neo4j possiede diversi metodi per interrogare e interagire coi dati: Core Java API. si collegheranno con le reletionship [ref]. ognuno dei quali differisce dall’altro per la dimensione del database scelta (Data1 o Data 2) e/o per tipo di query utilizzata (Complexity1 o Complexity2). 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). 38 . In questo paragrafo si analizzeranno e confronteranno con dei test le performance dei differenti metodi di interrogazione del database Neo4j. I saggi saranno collegati agli autori (o all’autore) che li hanno scritti attraverso delle relationship orientate [author] mentre nel caso una pubblicazione faccia riferimento ad un’altra.

1. Data2 e Complexity2: 39 . Data1 e Complexity2: FIGURA 20 Risultato Test 2 3. Data2 e Complexity1: FIGURA 21 Risultato test 3 4. Data1 e Complexity1: FIGURA 19 Risultato del Test 2.

risultando molto più lenta nei database di maggiori dimensioni (figura 19). 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. FIGURA 22 Risultato Test 4 Analizzando i risultati dei test. la dimensione del database non influenza le performance. 20. le Core Java API forniscono l’approccio più veloce nell’interrogare il database mentre Cypher risulta nettamente il più lento. D’altro canto Cypher risulta un linguaggio più astratto e semplice dal punto di vista sintattico e per questo spesso è preferibile alle Core Java API. mentre quando risulta elevato la differenza di costo diventa molto sensibile. Con l’aumentare di questo valore invece la 40 . 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. mostrano che all’interno di database delle stesse dimensioni il tempo di risposta a una interrogazione non subisce l’influenza della complessità della query quando il “query number” è basso. Le Traversal API risultano un buon compromesso tra i due linguaggi sopra citati. La motivazione è dovuta al fatto che Cypher. L’influenza della dimensione del database nella performance Un aspetto che si può notare confrontando le figure 19 e 21 è che. quando il “query number” è piccolo. L’influenza della complessità dell’interrogazione nella performance Le figure 19. utilizzando un linguaggio dichiarativo.

i chemical/biological network (per rappresentare legami molecolari e le mappe genetiche) e i road network (per rappresentare i percorsi stradali). dei successivi 4 saranno string (stringhe o sequenze di caratteri) da 8KB e degli ultimi 4 sempre stringhe da 32KB. 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. il secondo 5000. -la scalabilità. Progettazione del test Per testare i due database si creano 12 grafi in cui ogni nodo contiene una proprietà. 3. la struttura di ciascun grafo è generata casualmente da un programma. il terzo 10000 e il quarto 100000 nodi (vedi figura 23) [13] così da valutare la scalabilità. -flessibilità. Seguendo le precedenti disposizioni. I valori delle proprietà di 4 dei grafi saranno integer (numeri interi). da un punto di vista più soggettivo valutando: -maturità. -facilità di programmazione. Si utilizzano 4 grafi di ogni tipo in modo tale che il primo contenga 1000 nodi. 41 . La struttura a grafo è piuttosto comune ed esempi reali sono i social network.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. 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.complessità della query influenza notevolmente il costo della performance (maggiore sarà la complessità maggiore sarà il costo a parità di query number).

si riferiscono solamente alla struttura del grafo e non alle proprietà dei nodi contenuti in esso.node con gli attributi “nodeId”(ovvero l’identificatore del nodo) e “proprietà”. Le structural query sono: S0: trovare tutti i nodi orfani (cioè senza archi in entrata e in uscita) all’interno del grafo. 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. al contrario delle seconde. La differenza tra questi due tipi di query è dovuta al fatto che le prime. I2: determinare il numero dei nodi che hanno una proprietà con valore (integer) inferiore ad un certo valore assegnato.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. FIGURA 23 Database del test Per memorizzare i grafi nel relational database (MySQL) si utilizzano due tabelle: . 42 . S4: attraversare il grafo fino a profondità 4 e determinare il numero di nodi trovati.

S0 in millisecondi. FIGURA 26 Risultati della data query C1 in millisecondi. S128. mentre per Neo4j sono state utilizzate le traversal API. FIGURA 24 Risultati delle structural query S4. FIGURA 25 Risultati delle data query I1. Il test è stato fatto per stringhe di dimensioni diverse (da 4 a 8 caratteri).C1: determinare il numero di nodi le cui proprietà contengono una certa stringa (o sequenza di caratteri). Risultati Nelle seguenti tabelle sono riportati i risultati in termini temporali delle interrogazioni descritte le paragrafo precedente. I2 in millisecondi. Valutazioni oggettive 43 . Il linguaggio utilizzato da MySQL per interrogare i dati è ovviamente SQL.

l’attraversamento del grafo che da un nodo gli permette di risalire attraverso le sue relazioni ad altri nodi ad esso collegati. facilità di programmazione e flessibilità. aumentando invece le dimensioni. come ad esempio Oracle [13] e Microsoft [13] che hanno investito molto in questi 44 . non avendo archi ad essi collegati. Le caratteristiche che si andranno ad analizzare e confrontare saranno: maturità. Da figura 23 si nota però come Neo4j richieda mediamente uno spazio di archiviazione superiore a quello di MySQL. Questo tipo di operazione non è supportata dai database relazionali che invece dovranno effettuare costose operazioni di join. Questo tipo di ricerca trattando tutti i dati come dati di testo non risulta particolarmente efficace per le query I1 e I2. ma sono comunque importanti nel momento in cui si debba scegliere quale tipo di database utilizzare. Questo è dovuto al fatto che Neo4j può sfruttare. L’interrogazione S0 offre risultati più simili in termini prestazionali poiché per i nodi orfani. Valutazioni soggettive Questo tipo di valutazioni non sono quantificabili in termini numerici. 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. questi sono impiegato in ambiti commerciali e di ricerca accademica e hanno generato diverse “commercial ventures”. L’interrogazione C1 (figura 26) fornisce riscontri interessanti. Le data query per i database contenenti dati di tipo integer (I1. non è possibile sfruttare l’attraversamento del grafo. I2) mostrano una maggiore efficacia del database relazionale (figura 25). infatti. anche grazie all’index free adjacency. infatti nei database di minori dimensioni (quelli da 1000 nodi) le prestazioni di MySQL sono simili ed addirittura migliori di quelle di Neo4j. I relational database sono sicuramente il tipo di base di dati più utilizzati al mondo.Per le query S4 e S128 Neo4j risulta nella maggior parte dei casi nettamente più rapido (figura 24).  Si parla di sistema maturo quando questo è stato testato a fondo. più test sono effettuati maggiori saranno i “bug” identificati e di conseguenza il sistema stabile. Neo4j risulta nettamente più veloce dimostrando una scalabilità migliore.

come è già stato spiegato nel capitolo precedente. Sicuramente i graph database. le transazioni. dopo una breve introduzione all’ambito dei database NoSQL. Al contrario ricercare il valore di un attributo all’interno della base di dati di può risultare meno costoso in un database relazionale (anche se le prestazioni dei graph database dipendono molto dall’indicizzazione utilizzata)  Neo4j essendo un graph database risulta molto più flessibile di MySQL poiché.  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. database. in particolare Neo4j. i database a grafo non possiedono uno schema fisso. in generale. invece. Dall’analisi svolta nella tesi si può concludere che definire quale sia il miglior database da utilizzare dipende molto dai casi d’uso. mentre i database relazionali sono perfetti nel 45 . la programmazione ed infine le prestazioni per le quali sono state effettuate interrogazioni sul database relazionale MySQL e quello a grafo Neo4j. funzionano molto bene nel rappresentare dati connessi e nel rispondere in maniera rapida alle query che richiedono l’ attraversamento del grafo. 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. 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. Invece i database 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. è stato presentato un confronto tra i database a grafo e quelli relazionali analizzandone i modelli. dovrà eseguire diversi join. CONCLUSIONI In questa tesi. gli indici.

Marzo 2014) 46 . “A Novel Approach to Transform Relational Database into Graph Database using Neo4j”. 2012. [5] Manuale Online di Neo4j v2. 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). “Survey of graph database models”.rappresentare dati strutturati. Robinson. 2013. 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. IEEE 28th International Conference on Data Engineering Workshops. Computer Science and engineering department Thapar university. Entrambi i database presentano quindi aspetti positivi e negativi e una più appropriata area di applicazione.wikipedia. O’Reilly Media Inc. pp 171-176. “Graph Databases”.2 (Febbraio . [4] Ian. [2] Wikipedia. Bibliografia [1] Renzo Angles and Claudio Gutierrez.3.org) [3] Mehak Gupta.. 2014. (http://www. Jim Webber and Emil Eifrem.

Institute for Information Systems (iisys) Hof University Alfons-Goppel-Platz 1 DE-95028 Hof. [12] Florian Holzschuher and Prof. “Performance of Graph Query Languages. “Comparative Analysis of Different Graph Databases”. 2013. 2014. “Graph Databases: Their Power and Limitations”. Yixin Chen and Dawn Wilkins. “Model-Driven Design of Graph Databases”. Italy. [13] Chad Vicknair. Jadhav. 3 Issue 9. pp. Vol. International Journal of Engineering Research & Technology (IJERT). “Database relazionali e NoSQL a confronto”. Zhendong Zhao. 2015. René Peinl. D. 172–185. “Research on architecture and query performance based on distributed graph database Neo4j”. Germany . [7] Dimitri De Franciscis. “A Comparison of a Graph Database and a Relational Database”. 2010. International Journal of Soft Computing and Engineering (IJSCE). “Comparative Analysis of Relational And Graph Databases”. [10] Hongcheng Huang. Xiaofei Nan. [9] Shalini Batra and Charu Tyagi. Gremlin and Native Access in Neo4j”.[6] Jaroslav Pokorný. 58–69. Ruhi Oberoi. International Federation for Information Processing (IFIP). Michael Macias. 2012. Chongqing University of Posts and Telecommunications. pp. 2013. Antonio Maccioni and Riccardo Torlone. 2013. 47 . Dr. Ziyu Dong. Rome. 2014. Department of Computer and Information Science University of Mississippi. Issue-2. Dipartimento di Ingegneria Universit`a Roma Tre. Comparison of Cypher. Volume-2. [11] Pradeep. [8] Roberto De Virgilio.