Facoltà di Ingegneria
Corso di Studi in Ingegneria Informatica
Elaborato finale in Basi di Dati
Graph Database
Anno Accademico 2012/2013
Candidato:
MARCO DE MASI
matr. N46000365
Indice
Introduzione
4
Capitolo 1. Graph Database: Cosa sono.
5
1.1
1.2
1.3
1.4
Classificazione dei database NoSQL
Teoria dei grafi applicata al graph database
Nascita ed utilizzo del graph database
Caratteristiche del graph database
5
6
8
9
Capitolo 2. Differenze tra database relazionale e a grafo.
2.1
2.2
2.3
2.4
12
Relationship nei database relazionali e a grafo
Differenze tra query con esempio
Confronto tra efficienze con esempio
Confronto tra modellazione relazionale e a grafo
12
14
15
16
Capitolo 3. Progetti di graph database. Neo4j e Cypher.
3.1
3.2
3.3
3.4
3.5
20
Introduzione a Neo4j
Neo4j: un database completamente transazionale
Query in Neo4j
Cypher per le query sui grafi
Esempio con Cypher
20
20
22
24
27
Bibliografia
Ringraziamenti
29
30
III
Graph Database
Introduzione
In Informatica il termine database o base di dati (a volte abbreviato con DB) indica una
collezione di dati, in cui le informazioni sono organizzate in modo tale da consentire la
gestione dei dati stessi attraverso i cosiddetti query language, che ne permettono la ricerca,
l’inserimento, la cancellazione, l’aggiornamento, ecc. grazie a particolari applicazioni
software dedicate chiamate DBMS (DataBase Management System), che si basano su
un’architettura di tipo Client/Server.
Una base di dati può avere una diversa struttura a seconda del particolare modello logico, di
seguito elencati in ordine cronologico:
1) gerarchico (rappresentato da un albero, anni sessanta);
2) reticolare (rappresentato da un grafo, anni sessanta);
3) relazionale (rappresentato da tabelle e relazioni tra esse, anni settanta);
4) ad oggetti (estensione del paradigma “Object-Oriented” della programmazione a
oggetti, anni ottanta);
Il modello relazionale è attualmente il più diffuso modello, anche se negli ultimi anni sono
stati progettati nuovi sistemi al fine di ottenere elevate prestazioni nelle operazioni di lettura
e scrittura sui database. In particolare sono stati ripresi strumenti del modello reticolare che
hanno consentito lo sviluppo dei Graph Database (Basi di dati a grafo).
4
Graph Database
Capitolo 1
Graph Database: Cosa sono.
1.1 Classificazione dei database NoSQL
Il modello relazionale ha dominato fin dagli anni ’80 con implementazioni come Oracle e
MySQL, con la diffusione dei RDBMS (Relational Database Management System). Negli
ultimi anni però si è verificato un numero crescente di casi d’uso in cui il database
relazionale ha portato problemi sia nella modellazione dei dati che nella scalabilità
orizzontale su più server con grandi quantità di dati. Ciò ha portato allo sviluppo di nuove
tecnologie per risolvere questi problemi che hanno consentito la creazione di progetti di
database riconosciuti col nome di database NoSQL; in realtà il concetto è più antico dei
RDBMS, ed è quindi tornato di moda recentemente.
SQL (Structured Query Language) è il linguaggio standardizzato per database basati sul
modello relazionale, in contrapposizione a esso si usa la terminologia NoSQL.
Il termine NoSQL (acronimo di “Not Only SQL”) viene utilizzato generalmente per
indicare i database che non usano un modello relazionale, anche se non riflette
accuratamente la natura dei suoi database poiché fornisce l’errata impressione che il suo
concetto sia riferito a SQL.
I moderni database non relazionali hanno registrato un notevole sviluppo negli ultimi
anni e sono basati su alcuni punti:
5
Graph Database
-
sono distribuiti;
-
sono open-source;
-
puntano a scalare orizzontalmente.
Essi tipicamente non richiedono uno schema fisso (schemaless), evitano le operazioni di
unione (join), non garantiscono le caratteristiche di Atomicità, Coerenza, Isolamento e
Durabilità (ACID), permettono di gestire grandi quantità di dati.
Il motivo per cui oggi si sono diffusi è che permettono di gestire dati che col tempo sono
cresciuti enormemente in complessità, sia come dimensione che per interconnessioni.
Le principali categorie di database NoSQL sono:
-
Key-Value stores;
-
Column Family stores;
-
Document Databases;
-
Graph Databases.
1.2 Teoria dei grafi applicata al graph database
Il modello relazionale utilizza tabelle, il database orientato al documento utilizza
documenti, ecc., mentre il database a grafo usa nodi e archi per rappresentare e archiviare
l'informazione. Quindi un graph database memorizza i dati in un grafo, che rappresenta la
più generica delle strutture dati, capace di rappresentare elegantemente ogni tipo di dato.
Quando si parla di modelli dei dati basati su grafo è inevitabile fare riferimento alla teoria
dei grafi.
In matematica, in informatica e nella geometria combinatoria, la teoria dei grafi si
occupa di studiare i grafi, cioè oggetti che consentono di effettuare analisi in termini
quantitativi e algoritmici.
Un grafo è un insieme di elementi detti nodi o vertici collegati fra loro da archi o lati.
6
Graph Database
Più formalmente si dice grafo una coppia ordina G = (V,E), dove V è l’insieme dei nodi
ed E è l’insieme degli archi. Un arco è una coppia (a,b) di vertici, con a∈V e b∈V.
Esempio:
Questo tipo di struttura permette di modellare ogni tipo di scenario.
In questo caso ogni nodo rappresenta un’entità (per esempio una persona o
un’attività commerciale) e ogni arco rappresenta una relationship tra due nodi.
La variante più conosciuta di modello a grafo è rappresentato dal modello property
graph, che presenta le seguenti caratteristiche:
-
contiene nodi e relationship;
-
i nodi contengono proprietà attraverso coppie chiave-valore, dove “chiave” è la
stringa identificativa della proprietà, “valore” dipende invece dal tipo di dato;
-
le relationship sono espresse da un nome (una label) e collegano due nodi in modo
diretto (da un nodo iniziale a uno finale);
-
anche le relationship possono contenere proprietà;
La direzione e la label delle relationship aggiungono semantica alla struttura.
La maggior parte delle persone trova il property graph model intuitivo e facile da
comprendere, e può descrivere la stragrande maggioranza dei casi d’uso. Esso risulta
essere il modello di grafo più utilizzato.
7
Graph Database
1.3 Nascita ed utilizzo del graph database
I graph database nacquero con l’idea di ricollocare la semantica dell’SQL tabellare
attraverso un modello dei dati a grafo che avrebbe semplificato il lavoro degli sviluppatori,
dimezzando il tempo normalmente richiesto per i classici database. Originariamente l’idea
era quella di conservare tutte le caratteristiche del database relazionale (transazioni, ACID,
trigger, ecc.).
Negli ultimi anni ci sono stati enormi cambiamenti che riguardano soprattutto Google,
Facebook e Twitter, che infatti utilizzano i grafi al centro del loro business; Facebook per
esempio fu fondato con l’idea che oltre alle informazioni discrete sulle persone (il loro
nome, cosa fanno, ecc.) ci sono anche informazioni sulle relationship tra esse,
rappresentando queste informazioni in un social graph; in modo simile Google capì come
memorizzare e processare i documenti Web e i collegamenti tra essi, utilizzando il web
graph.
La relationship è la chiave per stabilire la semantica del contesto.
Oggi i grafi sono adottati con successo anche all’esterno del mondo del web, per esempio
da compagnie aeree, compagnie logistiche e aziende di servizi finanziari.
Le grandi imprese qualche tempo fa crearono tecnologie proprietarie di elaborazione dei
grafi. Queste considerazioni portarono alla nascita di nuovi strumenti general-purpose per
la gestione dei database, che consentono agli utenti di trarre benefici senza dover costruire
la propria infrastruttura a grafo.
I graph database risultano essere il miglior modo per rappresentare e interrogare dati
connessi, e sono importanti nel business odierno poiché fanno riferimento a relazioni
complesse e dinamiche tra questi dati. L’interpretazione e il valore dei dati connessi
dipende dalle relazioni tra gli elementi dei dati, quindi spesso si dà un nome alle suddette
8
Graph Database
relazioni.
Quasi sconosciuti fino a qualche anno fa, i graph database oggi sono fortemente utilizzati
in diversi settori tra i quali l’assistenza sanitaria, la vendita al dettaglio, lo sviluppo di
giochi ed altro ancora; inoltre hanno aiutato a risolvere importanti problemi riguardanti ad
esempio il social networking e la gestione dei dati.
Questo incremento dell’uso dei graph database è guidato da due fattori principali:
-
il grande successo commerciale di compagnie come Facebook, Google e Twitter, le
quali hanno concentrato il loro modello di business sulle proprie tecnologie a grafo
proprietarie;
-
l’introduzione di graph database general-purpose.
1.4 Caratteristiche del graph database
Un graph database è un database ottimizzato per gestire dati altamente connessi.
Essi furono progettati con l’idea che gli sviluppatori creavano delle strutture a grafo per poi
memorizzare i dati in forma non naturale nelle tabelle dei database relazionali, o anche in
altri database NoSQL, allora si cercò un modo per poter memorizzare questi dati in una
struttura che consentisse di conservare la natura dei dati.
Un graph database è generalmente costruito per interagire con i sistemi transazionali OLTP
(OnLine Transaction Processing), di conseguenza sono ottimizzati per ottenere buone
prestazioni transazionali.
I modelli di riferimento di implementazione dei graph database sono due:
9
Graph Database
-
Property Graph Model (già enunciato in precedenza);
-
Resource Description Framework (RDF) Graph.
RDF è il modello di riferimento del Web Semantico. Il passaggio da un modello all’altro è
molto intuitivo, per entrambi esistono linguaggi di interrogazione specifici, ma solo per RDF
esiste lo standard SPARQL.
I modelli prodotti con i graph database sono più semplici e significativi rispetto ai modelli
prodotti con i tradizionali database relazionali o con altri database NoSQL.
Vantaggi nell’utilizzo dei graph database:
-
Prestazioni.
Uno dei principali vantaggi ottenuti con i graph database, rispetto all’utilizzo dei
database relazionali o altri NoSQL, è l’aumento assoluto delle prestazioni quando si ha
a che fare con dati connessi. Rispetto ai database relazionali dove le prestazioni delle
query diminuiscono all’aumentare dei dati, nel graph database le prestazioni tendono a
rimanere costanti anche con l’aumentare dei dati, poiché le query si riferiscono solo ad
una porzione del grafo. Come conseguenza di ciò, il tempo di esecuzione per ogni
query è proporzionale solo alla dimensione della parte del grafo da attraversare.
-
Flessibilità.
Il grafo è naturalmente additivo, quindi è possibile aggiungere nuove relationship,
nuovi nodi e nuovi sottografi a una struttura senza turbare le query esistenti e le
funzionalità. L’additività dei grafi permette di eseguire minori migrazioni, riducendo
l’overhead della manutenzione e i rischi.
10
Graph Database
-
Agilità (Efficacia risposta ai cambiamenti).
I moderni graph database forniscono strumenti per ottenere uno sviluppo senza attrito
e una buona manutenzione del sistema. In particolare, è possibile sviluppare
un’applicazione in modo controllato grazie alla natura dello schema libero del modello
a grafo e alla testabilità delle API (Application Programmer Interface) e dei linguaggi
query del graph database. Oggi lo sviluppo del graph database si allinea bene con
l’agilità, in modo migliore rispetto allo sviluppo del database relazionale, permettendo
alle applicazioni di supporto ai graph database di evolvere al passo con i cambiamenti
dell’ambiente del business.
Per tutti questi motivi quindi il graph database fornisce la miglior rappresentazione per
modellare, memorizzare e interrogare dati connessi.
11
Graph Database
Capitolo 2
Differenze tra database relazionale e a grafo.
2.1 Relationship nei database relazionali e a grafo
-
RELATIONSHIP NEI DATABASE RELAZIONALI
Per molti decenni, gli sviluppatori hanno provato a sistemare i dati connessi all’interno del
database relazionale, che inizialmente erano progettati per codificare figure e tabelle, e
subito vennero mostrate difficoltà nel tentativo di modellare le relationship del mondo
reale. Le relationship esistono nel mondo del database relazionale, ma solo come
rappresentazioni di tabelle accoppiate, spesso si ha la necessità di non avere ambiguità
sulla semantica delle relationship che collegano le entità.
Se i dati si moltiplicano la loro struttura diventa più complessa e meno uniforme, e il
modello relazionale diventa oneroso.
Uno dei peggiori svantaggi che si può ottenere nell’utilizzo dei database relazionali è
l’aumento delle costose operazioni di join, che ostacola le prestazioni e rende difficile
adattare un database esistente in risposta ai cambiamenti del business.
Inoltre lo schema tabellare mescola i propri dati con le foreign-key.
Esempio di schema relazionale, rappresentazione di un social network:
12
Graph Database
Le relazioni semantiche nel database relazionale sono minori rispetto al caso del database a
grafo.
Quando le query vincolano il numero di righe da considerare in una tabella (ad esempio con
la condizione “WHERE”), esse non risultano particolarmente costose e difficili, a differenza
di quando le query vanno a considerare tutte le righe della tabella risultando quindi costose;
quando si va a considerare join ricorsive, le query diventano computazionalmente e
sintatticamente ancora più complesse.
-
RELATIONSHIP NEI GRAPH DATABASE
Quando si ha a che fare con dati connessi ci sono dipendenze semantiche tra le entità. Si
vuole una figura completa che includa tutti i collegamenti tra ciascun elemento.
Per esempio consideriamo ora il social network:
13
Graph Database
Rispetto al modello relazionale ora la rete cresce in espressività, infatti per ogni utente
sono mostrate le sue relazioni con altri utenti (nell’esempio si può facilmente osservare
come James e Charlie siano sia amici che colleghi).
Inoltre la flessibilità del modello a grafo permette di aggiungere nuovi nodi e nuove
relationship senza compromettere lo schema esistente o la migrazione dei dati.
Quindi il grafo offre maggiori ricchezze rispetto al modello tabellare del database
relazionale, inoltre si hanno notevoli vantaggi nelle prestazioni dei graph database quando
vengono trattati dati connessi.
Naturalmente le relationship in un grafo formano dei path, che vengono coinvolti dal grafo
attraverso le query. La maggior parte delle operazioni path-based del graph database
risultano estremamente efficienti.
2.2 Differenze tra query con esempio
Per i database relazionali è definito lo standard SQL per le query, mentre per i graph
database non c’è un linguaggio standard e nell’esempio consideriamo Cypher.
Esempio. Selezionare una persona che si chiama “Anakin” da un gruppo di persone:
14
Graph Database
Esempio. Trovare tutti gli indirizzi email associati ad una persona di nome “Anakin”:
2.3 Confronto tra efficienze con esempio
Il social network rappresenta l’esempio classico per mostrare la maggior efficienza dei
graph database rispetto ai relazionali quando si ha a che fare con dati connessi; tutto
questo può essere mostrato attraverso un esperimento effettuato per trovare gli amici di
amici (fino a profondità 5 di amicizia) in un social network di un milione di persone,
ognuna avente circa 50 amici, usando un database relazionale e il graph database Neo4j.
L’esperimento produsse i seguenti risultati:
A profondità 2 (amici di amici) entrambi i database producono buoni risultati e un utente
finale non noterebbe la differenza di ms tra i due, ma a partire da profondità 3 (amici di
amici di amici) in poi, il database relazionale presenta query con tempi di esecuzione non
ragionevoli rispetto alle query del Neo4j, che presentano un tempo di esecuzione quasi
invariato ottenendo un risultato più che soddisfacente.
15
Graph Database
2.4 Confronto tra modellazione relazionale e a grafo
Il database relazionale è il più famoso ed utilizzato database, e presenta poche similarità e molte
differenze con i database a grafo.
Le tecniche di modellazione relazionali richiedono di partire prima dal modello logico per
poi arrivare al modello fisico, e queste trasformazioni introducono dissonanze semantiche.
Nei graph database questo gap è ridotto, poiché esso presenta una stretta affinità tra modello
logico e modello fisico.
Esempio di dominio semplificato per la gestione dei dati tramite il supporto di applicazioni che
usano diverse infrastrutture, dalle macchine virtuali ai load balancer:
16
Graph Database
-
MODELLAZIONE RELAZIONALE
La fase iniziale di modellazione relazionale è simile a quella di molte altre tecniche di modellazione
dei dati, cioè si cerca di capire e concordare le entità del dominio e come queste ultime sono
collegate tra loro. Per esprimere questo tipicamente si crea un diagramma come quello nell’esempio
precedente, che è un grafo.
La fase successiva cattura questi accordi in una forma più rigida creando un diagramma
entity-relationship (E-R). Questa trasformazione del modello concettuale in un modello logico usa
una notazione più stretta, e non è sempre necessaria (spesso gli utenti non usano questo diagramma
E-R intermedio).
In riferimento al precedente esempio, si può costruire il seguente diagramma E-R:
Si ha ora un modello normalizzato, che ha notevole complessità nella forma di foreign key e
tabelle. Il lavoro di progetto non è già completo, infatti i modelli normalizzati relazionali
generalmente non sono abbastanza veloci. Per molti sistemi di produzione uno schema
normalizzato deve praticamente essere ulteriormente adattato e specializzato, per poter
17
Graph Database
essere adattato per il database e non per l’utente, questa tecnica è chiamata
denormalizzazione. La denormalizzazione comporta dati duplicati al fine di acquisire
maggiore performance.
Per esempio un utente ha diversi indirizzi email, che nel modello normalizzato potrebbero
essere memorizzati in una tabella EMAIL. Per ridurre le join e i decrementi delle prestazioni
dovuti alle join tra due tabelle, è utile porre questi dati nella tabella USER, aggiungendo una
o più colonne.
Invece in riferimento all’esempio precedente è possibile ottenere:
-
MODELLAZIONE A GRAFO
I database relazionali non rappresentano uno strumento particolarmente buono per
supportare rapidi cambiamenti, quindi si ha bisogno di un modello strettamente allineato col
dominio, che non sacrifica le prestazioni e che supporta l’evoluzione conservando l’integrità
18
Graph Database
dei dati quando è sottoposto a rapidi cambiamenti. Questo modello è il modello a grafo.
Le fasi iniziali sono simili a quelle del modello relazionale, tramite abbozzi si descrive il
dominio. Dopo, invece di trasformare la rappresentazione a grafo in tabelle, bisogna invece
arricchirla per produrre una rappresentazione accurata del dominio.
Assicurando la correttezza del modello del dominio implicitamente si migliora il modello a
grafo, assicurando che ogni nodo abbia le appropriate proprietà e che sia nel contesto
semantico corretto creando relationship con nomi e dirette tra i nodi.
In riferimento all’esempio è possibile costruire il seguente modello a grafo:
Il prossimo passo consiste nel testare se il modello è adatto per poter eseguire specifiche
query, quindi bisogna correggere eventualmente qualche errata decisione di progetto
iniziale. Invece i cambiamenti successivi alla struttura del grafo saranno guidati solamente
dai cambiamenti del business, e ciò è facilitato grazie alla flessibilità del modello a grafo.
19
Graph Database
Capitolo 3
Progetti di graph database. Neo4j e Cypher.
3.1 Introduzione a Neo4j
Esistono vari progetti di basi di dati a grafo, tra i più conosciuti sicuramente ci sono Neo4j,
InfoGrid, DEX e HyperGraphDB.
Neo4j è 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:
-
è intuitivo, poiché usa un modello a grafo per rappresentare i dati;
-
è affidabile, con transazioni completamente ACID;
-
è altamente scalabile, fino a diversi miliardi di nodi, relationship e proprietà;
-
è espressivo, con un potente linguaggio query per il grafo;
-
è veloce, con un potente traversal framework per query ad altà velocità;
-
può essere usato sia in modalità server che embedded.
3.2 Neo4j: un database completamente transazionale
La gestione delle transazioni è stato il punto più discusso nelle tecnologie NoSQL da quando
20
Graph Database
esse hanno iniziato a diffondersi, così i database non relazionali hanno optato per il trade-off
degli attributi transazionali (Atomicità, Coerenza, Isolamento, Durabilità), ad esempio
alcuni database non relazionali come BigTable e Cassandra optarono per la coerenza
trade-off, permettendo così ai clienti di avere la possibilità di leggere dati non aggiornati.
Questi approcci risultano adeguati solo in specifici casi d’uso (caching, concorrenza, …) e
rappresentano un problema quando si introducono i database non relazionali all’interno
di qualche azienda.
Gli attributi transazionali furono ideati per i database relazionali e risultano ancora
importanti in molti casi d’uso.
Neo4j ha adottato un approccio differente rispetto a tutti gli altri database non relazionali,
infatti supporta completamente le proprietà ACID:
-
Atomicità: si possono avvolgere operazioni multiple all’interno di una singola
transazione, la transazione è indivisibile (se una delle operazioni fallisce allora fallisce
l’intera transazione), non sono ammesse esecuzioni parziali;
-
Coerenza: quando si scrivono dati nel database, ogni client che accederà al database
leggerà gli ultimi dati aggiornati;
-
Isolamento: le operazioni di una singola transazione saranno isolate l’una dall’altra,
così anche le transazioni saranno eseguite in modo isolato;
-
Durabilità: i dati scritti sul database saranno memorizzati su disco e disponibili dopo il
riavvio del database.
21
Graph Database
3.3 Query in Neo4j
Riguardo alle operazioni sui dati connessi, Neo4j può eseguire molto più velocemente
rispetto ai classici e tradizionali database relazionali.
Esso aiuta a modellare e a risolvere problemi in modo più elegante ottenendo una migliore
esecuzione, anche quando si lavora con grandi quantità di dati.
Si consideri come esempio un social network, dove gli utenti collegati tra loro con le frecce
sono amici:
Neo4j memorizza i dati come vertici ed archi, che nella terminologia del graph database
sono rispettivamente nodi e relationship. Nell’esempio gli utenti sono rappresentati come
nodi e le loro amicizie come relationship tra i nodi.
C’è una differenza fondamentale tra un database relazionale e un Neo4j nell’interrogazione
(query) dei dati, poiché in Neo4j non ci sono tabelle né MySQL con i comandi select e join,
quindi le query vengono eseguite diversamente.
Neo4j, come tutti i graph database, usa un potente concetto matematico dalla teoria dei grafi
per effettuare query, chiamato graph traversal. Esso è uno dei principali strumenti che rende
22
Graph Database
Neo4j potente per poter trattare dati di larga scala.
I principali metodi per eseguire query su una base di dati a grafo e supportati da Neo4j sono
Cypher, Gremlin e Traversal.
Il traversal (attraversamento) è un’operazione che percorre un insieme di nodi nel grafo,
muovendosi solo tra nodi collegati con le relationship. E’ un’operazione fondamentale per il
retrieval dei dati in un grafo. Interrogare i dati attraverso gli attraversamenti porta in
considerazione solo i dati richiesti, mantenendo un rendimento prevedibile a prescindere dal
numero di dati, senza la necessità di eseguire costose operazioni di raggruppamento
sull’intero insieme di dati come avviene con le operazioni di join nei database relazionali.
Neo4j fornisce una Traversal API, utilizzata per poter navigare attraverso il grafo.
Inoltre è possibile utilizzare REST API o i linguaggi di query Neo4j per attraversare i dati
nel grafo.
Prima di avviare l’attraversamento, si seleziona un nodo da cui l’attraversamento avrà
inizio, dopodiché si esegue l’attraversamento, seguendo tutte le relationship (indicate dalle
frecce) e raccogliendo i nodi visitati, così l’attraversamento continua poi il suo viaggio da
un nodo a un altro attraverso le relationship che li collegano, fin quando non finisce di
eseguire il proprio compito e l’attraversamento termina.
In riferimento al precedente esempio di social network, lo scopo può essere quello di
visitare solo i nodi che sono di profondità 1 partendo da un nodo iniziale (trovare gli amici
dell’utente X), e una volta che questi nodi sono visitati l’attraversamento termina.
Quindi indipendentemente dal numero di nodi e di relationship esistenti nel grafo,
l'attraversamento visita solo i nodi collegati al nodo di partenza. Si ottiene così
l’attraversamento dei seguenti nodi e delle corrispondenti relationship:
23
Graph Database
Il vantaggio principale che si può ottenere utilizzando Neo4j è che fornisce ottime
prestazioni anche con i dati in larga scala. Infatti passando da un social network di mille
persone a uno che ne comprende un milione, l’aumento mille volte maggiore dei dati non
influenza in modo significativo le prestazioni del Neo4j, cosa che invece non avviene
lavorando con un qualsiasi database relazionale. Ovviamente più sono i nodi da visitare e
più è lento l’attraversamento, anche se questo aumento è lineare e non dipende dalle
dimensioni totali del grafo.
Inoltre l’utilizzo di un graph database Neo4j permette di preservare la struttura naturale a
grafo dei dati (con nodi e relationship), migliorando le prestazioni delle query in modo
significativo. Le query sono eseguite in modo efficiente grazie alle Neo4j Traversal API.
3.4 Cypher per le query sui grafi
Per utilizzare un database ed avere la possibilità di creare, manipolare e interrogare i suoi
dati, c’è bisogno di un linguaggio query. A differenza di ciò che avviene nei database
relazionali con lo standard SQL, per i database a grafo non c’è un linguaggio standard,
allora in questo paragrafo si farà riferimento a Cypher.
Oltre ad esso ci sono altri famosi linguaggi query come SPARQL del modello RDF
24
Graph Database
(utilizzato nel Web semantico) o anche il linguaggio query path-based Gremlin.
Cypher è un linguaggio query dichiarativo che consente di effettuare query espressive ed
efficienti e di aggiornare la struttura del grafo (in questo caso si esegue una transazione). E’
uno dei linguaggi query più facili ed utilizzati per descrivere e interrogare i dati nel property
graph ed è utilizzato anche in Neo4j.
Come la maggior parte dei linguaggi query, Cypher è composto da clausole. Le più
semplici query comprendono la clausola START, seguite dalle clausole MATCH e
RETURN.
A differenza di SQL che opera su insiemi, Cypher lavora prevalentemente sui sotto-grafi.
Esempio di query Cypher che usa queste tre clausole per trovare gli amici di un utente
chiamato Michael:
START
MATCH
a-node:user(name=’Michael’)
(a) – [ :KNOWS ] - > (b) – [ :KNOWS ] - > (c) , (a) – [ :KNOWS ] - > (c)
RETURN b, c
-
START
Specifica uno o più punti iniziali (nodi o relationship) nel grafo. Essi sono ottenuti
attraverso ricerche di indici o, molto raramente, acceduti direttamente basandosi sugli ID
del nodo o della relationship. Nell’esempio si cerca un nodo iniziale, attraverso un indice
chiamato ‘user’, con un nome il cui valore è ‘Michael‘. Il valore di ritorno da questa ricerca
è legato da un identificatore, nell’esempio chiamato ‘a’, che permette di far riferimento al
nodo iniziale. Da un punto di vista SQL, gli identificatori in START sono come i nomi delle
tabelle che indicano un insieme di nodi o di relationship.
-
MATCH
Permette a un utente (o a un’applicazione che lavora per lui) di chiedere al database di
trovare dati che corrispondono a uno specifico pattern.
25
Graph Database
La clausola MATCH evita quindi costose operazioni di join come avviene in SQL.
Nell’esempio abbiamo un semplice pattern che rappresenta un caso d’uso di tre amici:
Si trattano i dati di interesse usando i caratteri ASCII per rappresentare i nodi e le
relationship. La rappresentazione ASCII equivalente in Cypher è:
(a) – [ :KNOWS ] - > (b) – [ :KNOWS ] - > (c) , (a) – [ :KNOWS ] - > (c)
Questo pattern descrive un path, che comprende tre nodi (uno associato all’identificatore ‘a’, uno
a ‘b’ e l’altro a ‘c’), collegati attraverso le relationship ‘KNOWS’. Questo pattern potrebbe
teoricamente verificarsi molte volte, infatti con un grande set di utenti ci possono essere molte
relationship corrispondenti a questo pattern.
I pattern di Cypher seguono molto naturalmente il modo in cui si disegnano i grafi,
utilizzando istanze di nodi e relationship.
Una query Cypher considera una o più parti del pattern per specificare le locazioni di
partenza nel grafo, e allora va sulle parti non considerate per effettuare confronti locali. Le
locazioni di partenza sono scoperte principalmente attraverso l’uso di un indice (utilizzato
da Neo4j).
Con la clausola START si è cercato un nodo reale nel grafo, nell’esempio il nodo che rappresenta
‘Michael’, per poterlo legare all’identificatore ‘a’, il quale effettua la clausola MATCH. Cypher
allora confronta (match) il resto del pattern col grafo circostante il punto considerato, e scopre i nodi
26
Graph Database
da legare agli altri identificatori. Mentre ‘a’ sarà sempre associato a Michael, ‘b’ e ‘c’ saranno legati
a una certa sequenza di nodi a seconda dell’esecuzione della query.
-
RETURN
Questa clausola specifica quali nodi, relationship e proprietà dopo il match dovrebbero essere
ritornati. Con riferimento all’esempio, 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à;
-
FOREACH: esegue un’azione di aggiornamento per ogni elemento di una lista;
-
UNION: unisce i risultati di due o più query;
-
WITH: divide una query in multiple parti distinte.
3.5 Esempio con Cypher
27
Graph Database
Esempio di query che trova un utente chiamato John attraverso un indice e poi attraversa il
grafo in cerca di amici di amici di John prima di ritornare sia John che gli amici di amici
trovati:
Altro esempio: si consideri la lista di utenti (con ID del nodo) e si attraversi il grafo in
cerca di altri utenti, ritornando solo quelli che hanno la proprietà ‘name’ che inizia per ‘S’.
Quindi Cypher si concentra su COSA recuperare da un grafo e non COME.
28
Graph Database
Bibliografia e Sitografia
[1]
Ian Robinson, Jim Webber, Emil Eifrem 2013 “Graph Databases”
[2]
Jonas Partner, Aleksa Vukotic, Nicki Watt 2013 “Neo4j in Action”
[3]
http://www.nosql-database.org/
[4]
http://www.neo4j.org/
[5]
http://docs.neo4j.org/chunked/milestone/
29
Ringraziamenti
30
