Database NoSQL: i GraphDB

Scuola Politecnica e delle Scienze di Base
Corso di Laurea in Ingegneria Informatica
Elaborato finale in Basi di Dati
Database NoSQL: i GraphDB
Anno Accademico 2013/2014
Candidato:
Daniele Passaretti
matr.N46/001340
Indice
Introduzione
1
vi
NoSQL Databases
1
1.1
Che cos’è un NoSQL Database? Breve cenni storici. . . . .
1
1.2
Caratteristiche . . . . . . . . . . . . . . . . . . . . . . . . .
3
1.2.1
Teorema di CAP e proprietà BASE . . . . . . . . . .
3
1.2.2
Elementi Fondanti . . . . . . . . . . . . . . . . . . .
4
RDBMS vs NoSQL . . . . . . . . . . . . . . . . . . . . . . .
5
1.3
2 Panoramica dei NoSQL
7
2.1
Key-Value Databases . . . . . . . . . . . . . . . . . . . . . .
7
2.2
Document Databases . . . . . . . . . . . . . . . . . . . . . .
8
2.3
Column-Family Stores . . . . . . . . . . . . . . . . . . . . .
8
2.4
Graph Databases . . . . . . . . . . . . . . . . . . . . . . . .
9
3 Graph Database
3.1
3.2
10
I Grafi applicati ai Database: Graph Databases
. . . . . .
10
3.1.1
Flessibilità . . . . . . . . . . . . . . . . . . . . . . .
11
3.1.2
Performance
. . . . . . . . . . . . . . . . . . . . . .
11
3.1.3
Agilità . . . . . . . . . . . . . . . . . . . . . . . . . .
12
Storing Connection Data . . . . . . . . . . . . . . . . . . . .
12
iii
Indice
4 Realizzazione di un Graph DB
4.1
Cypher . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.2
Esempio di implementazione di Graph DB: Shakespeare exam-
15
15
ple . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
17
4.2.1
CREATE del Grafo . . . . . . . . . . . . . . . . . .
17
4.2.2
QUERY sul Grafo . . . . . . . . . . . . . . . . . . .
19
5 Grafi nel mondo Reale
21
5.1
Perchè le organizzazioni scelgono i Graph DB . . . . . . . .
21
5.2
Casi d’uso . . . . . . . . . . . . . . . . . . . . . . . . . . . .
22
6 Conclusione
24
Bibliografia
26
iv
Elenco delle figure
1.1
Ricapitolazione storica
. . . . . . . . . . . . . . . . . . . .
2
1.2
Teorema di CAP . . . . . . . . . . . . . . . . . . . . . . . .
4
3.1
Struttura dati di un Graph DB . . . . . . . . . . . . . . . .
13
3.2
Confronto tra RDBMS e GRAPH DB . . . . . . . . . . . .
14
4.1
Esempio CREATE . . . . . . . . . . . . . . . . . . . . . . .
18
4.2
Esempio Query . . . . . . . . . . . . . . . . . . . . . . . . .
20
v
Introduzione
Storicamente, con la nascita del web e la divulgazione delle informazioni attraverso tale mezzo, per la gestione delle informazioni venivano usati
dei database di tipo relazionale. Negli ultimi anni, con l’enorme sviluppo
della rete, il notevole aumento degli utenti e quindi delle informazioni da
gestire, la nascita dei social network e delle web apps, è emersa l’esigenza
di dover gestire database di dimensioni sempre maggiori, ossia
con dati in continuo cambiamento sia orizzontalmente che verticalmente, i quali fossero capaci di rispettare vincoli di velocità
tali da riuscire a soddisfare le esigenze degli utenti.
Inizialmente, per gestire queste problematiche si è cercato di capire come
poter migliorare i sistemi RDBMS per tali finalità. Si è osservato che per
migliorare le prestazioni legate alla velocità si poteva limitare l’uso del
JOIN, costruendo tabelle più annidate; ma questa soluzione comportava
una serie di problematiche ancora più complesse da gestire e andava ulteriormente a contribuire al primo problema suddetto, ossia l’ aumento delle
dimensioni del database.
Per ovviare a tutte queste problematiche, si è deciso di ricorrere ad una
nuova tipologia di database, i NoSQL Database (Not Only SQL Database).
Alla famiglia dei NoSQL DB appartengono varie tipologie di database,
vi
Introduzione
ognuna con caratteristiche in comune e non.
In questo elaborato faremo solo un accenno ai NoSQL DB con relative caratteristiche, e una panoramica generale delle varie tipologie di NoSQL DB
presenti sul mercato. Ci so↵ermeremo soprattutto sulla famiglia dei GraphDB, partendo dalla descrizione del concetto di grafo, su come questo
può essere sfruttato e applicato per modellare un database, e sulle caratteristiche e la struttura implementativa di una query in un GraphDB, per
capirne i vantaggi sia teorici che applicati a casi reali.
vii
Capitolo 1
NoSQL Databases
In questo capitolo verrà descritto che cos’è un NoSQL DB attraverso
la sua storia, le sue caratteristiche, e le di↵erenze rispetto ai Relational
Databases.
1.1
Che cos’è un NoSQL Database? Breve cenni
storici.
Spesso, quando si sente il termine NoSQL DB si pensa che questo faccia
riferimento a tutti quei database che non usano SQL; in Realtà l’acronimo
di questa sigla è Not Only SQL,che sta ad indicare tutti quei database
che vanno oltre l’utilizzo di SQL; ossia che possono sfruttare anche SQL
ma hanno una struttura molto più complessa del classico SQL. Il termine
NoSQL viene utilizzato per la prima volta nel 1998, quando Carlo Strozzi pubblica un database open-source non basato sulla struttura tipica di
SQL. Si ritornerà a parlare di SQL solo dopo alcuni anni. Infatti tale termine diventa protagonista nel 2009 come hashtag di twitter per indicare
un evento di basi di dati distribuite. Al centro dell’evento troviamo i due
1
Capitolo 1.
NoSQL Databases
database che potrebbero essere definiti i precursori dei NoSQL DB: Dynamo e BigTable. Anche se diventa una realtà solo dopo il 2009, bisogna
fare un piccolo cenno agli anni precedenti al fine di comprendere qual è
stato l’e↵ettivo sviluppo e l’esigenza da parte delle aziende di perseguire
questa strada. Nel 2004 Google, per dover gestire e migliorare i sistemi
legati ai propri servizi on-line decide di investire su un nuovo progetto:
MapReduce, un sistema distribuito che nel 2006 è stato utilizzato per implementare BigTable. Sulle orme di BigTable, Amazon sviluppa Dynamo
e lo presenta nel 2007. Da questi due grandi progetti prendono spunto
vari hobbisti per realizzare DB di↵erenti che puntassero a risolvere problematiche di diversa natura, che con i classici database relazionali, non
si riuscivano a risolvere in maniera performante. Contemporaneamente
anche altre società tra cui IBM, Facebook, Yahoo, EBay, Netflix investono
e sviluppano nuovi sistemi che poi rientreranno tra i NoSQL BD. Oggi
noi classifichiamo varie tipologie di NoSQL DB, ognuna con determinate
caratteristiche in comune e non.
Figura 1.1: Ricapitolazione storica
2
Capitolo 1.
1.2
NoSQL Databases
Caratteristiche
Sulla base di quanto suddetto i NoSQL DB nascono e si sviluppano
per cause e necessità varie al contrario di un RDBMS in cui fondamentali
sono le proprietà ACID. Dunque, non si ha più come obiettivo principale
quello di garantire le proprietà ACID, ma si parla di proprietà BASE,
in relazione al Teorema di CAP. Dunque, cardine di questi DB, è la disponibilità dei dati e la relativa velocità nel recuperare gli stessi a discapito
della consistenza.
1.2.1
Teorema di CAP e proprietà BASE
Nei NoSQL DB, la consistenza non è una proprietà stringente come
negli RDBMS, quindi possiamo parlare di Relax Consistency. A supporto
di tale caratteristica troviamo il teorema di CAP. Tale teorema fu originariamente proposto da Eric Brewer nel 2000 e poi formalmente espresso da
Seth Gilbert e Nancy Lynch. Il Teorema di CAP a↵erma che è impossibile per un sistema informatico distribuito fornire simultaneamente tutte e
tre le seguenti garanzie: Coerenza, Disponibilità, Tolleranza di Partizione.
Secondo il teorema, un sistema distribuito è in grado di soddisfare al massimo due di queste garanzie allo stesso tempo, ma non tutte e tre, cit:[4].
Tale teorema può essere espresso graficamente come in figura 4.1
Ora, applicando questo teorema ad un sistema che deve rispettare le
proprietà BASE, si osserva che tra le tre proprietà sopra indicate, sacrificabile è la consistency. Per l’ availability dobbiamo fare un’ulteriore
osservazione. Nei sistemi in cui si vuole trovare un compromesso tra availability e consistency, si può parlare di Latency. La Latency ci indica il
limite di tempo che l’utente è disposto a sopportare per definire un sistema
3
Capitolo 1.
NoSQL Databases
Figura 1.2: Teorema di CAP
availability.
Le proprietà BASE esprimono le caratteristiche fondamentali di un NoSQL DB, infatti queste, sacrificando la consistenza, mirano a garantire la
disponibilità dell’informazione e la scalabilità del sistema. Sono esprimibili
dal seguente acronimo:
• Basically Available: bisogna garantire la dispnibilità delle informazioni;
• Soft State: il sistema può cambiare stato nel tempo anche in
assenza di Letture o Scritture;
• Eventual Consistency: la consistenza va garantita nel tempo
attraverso sistemi di recupero della consistenza.
1.2.2
Elementi Fondanti
Ogni NoSQL DB, come abbiamo già detto, punta a garantire alte performance di velocità e disponibilità a costi contenuti, a discapito della
4
Capitolo 1.
NoSQL Databases
consistenza. Per fare ciò questi devono avere i seguenti elementi fondamentali:
• Ambiente Multi-Nodo: il sistema è distribuito su più cluster,
che a loro volta singolarmente possono essere aggiunti o rimossi dal
sistema;
• Sharding dei Dati: con algoritmi ottimizzati, i dati vengono distribuiti sui vari nodi; grazie a tali algoritmi è possibile gestire tali
dati in maniera molto semplice;
• Replica delle Informazioni: i dati distribuiti su più nodi a loro
volta vengono duplicati su ulteriori nodi per avere una maggiore
integrità e performance;
• Eliminazione della Complessità: grazie ai meccanismi usati per
distribuire il carico si cerca di eliminare la complessità riscontrata in
molti sistemi RDBMS;
• Correlazione dei Dati: escludendo i sistemi Graph DB in cui
le Relazioni variano nel tempo e hanno meccanismi di↵erenti dai
restanti NoSQL BD, si cerca di gestire e distribuire i dati in maniera
aggregata, cosı̀ da facilitare le correlazioni tra i dati;
1.3
RDBMS vs NoSQL
Confrontando queste due tipologie di database si osserva che due sono
i fattori fondamentali su cui si poggia tale confronto:Standardizzazione
degli RDBMS e Scalabilità e Costo dei NoSQL.
Standardizzazione:
questo elemento è a vantaggio degli RDBMS, poichè
si osserva che i vari RDBMS sono standardizzati tra loro; cosı̀ si ha che
5
Capitolo 1.
NoSQL Databases
una data query fatta in un determinato linguaggio o ambiente di lavoro
è facilmente applicabile ad un altro database RDBMS; quindi anche lo
stesso database realizzato in un dato ambiente è facilmente interfacciabile
con un altro RDBMS o con un determinato ambiente di sviluppo software
applicativo.
Invece per i NoSQL DB, come vedremo meglio in seguito, ciò non è possibile perché sono tra loro molto di↵erenti sia a livello concettuale teorico,
che implementativo. Questi sono il risultato di esigenze avvenute negli
anni, infatti puntano a risolvere determinate problematiche senza pensare
al resto.
Scalabilità e Costo: si osserva che proprio a fronte delle problematiche
che i NoSQL DB sono chiamati a risolvere, devono essere flessibili e scalabili. Infatti, questi sono progettati per essere scalabili orizzontalmente
a costi ridotti, mantenendo performance altissime, cosa che non è assolutamente applicabile a sistemi RDBMS, in quanto questi ultimi hanno una
struttura schematica tabellare. Inoltre gli RDBMS puntano proprio ad
evolversi prettamente in verticale e, in parallelo a tale evoluzione, per rimanere performanti richiedono un hardware dedicato e sempre più costoso,
contrariamente all’hardware richiesto da un NoSQL DB.
6
Capitolo 2
Panoramica dei NoSQL
Finora sono state implementate varie tipologie di NoSQL DB, in base
alle esigenze, ognuna con peculiarità e scopi di↵erenti. In questo capitolo
faremo una panoramica sui principali NoSQL DB presenti sul mercato,
spiegandone le caratteristiche e i vantaggi in relazione al loro utilizzo.
2.1
Key-Value Databases
Un Key-Value Database può essere definito come una semplice hashtable, principalmente usato quando bisogna accedere al database prettamente attraverso la PRIMARY KEY. Di base possiamo vedere un keyvalue DB come un RDBMS con due colonne: la prima per la key e la
seconda per il value.
La di↵erenza fondamentale con gli RDBMS è data proprio dal value nei
quali è rappresentato da un tipo di cui sappiamo le caratteristiche, mentre
qui il value può essere definito come un blob(oggetto o struttura di cui
non conosciamo come è fatto). Proprio per la struttura appena descritta,
bisogna osservare che questo database permette una facile scalabilità orizzontale, ma permette query solo sulla key, non conoscendo nulla sui dati
7
Capitolo 2. Panoramica dei NoSQL
del value.
A tal porposito importante ricordare DynamoDB, il primo key-value DB,
lanciato da Amazon.
2.2
Document Databases
Il concetto base su cui sono fondati tali Database è quello dei documenti. Il database scrive e restituisce documenti, che possono essere
XML, JSON, BSON, e altri ancora. Questi documenti possono trovarsi in
molteplici forme e strutture. Tali database sono spesso confrontati con i
Key-Value DB, poichè è possibile vedere i documenti contenuti come dei
value esaminabili. Da ciò è semplice osservare che, in questo caso è possibile estendere le query anche sulle informazioni contenute nei documenti.
Questi DB sono molto usati oggi sul mercato, poiché oltre ad avere dati
aggregati, riescono bene a gestire le query.
Tra essi uno dei più di↵usi è MongoDB.
2.3
Column-Family Stores
I database di questa categoria introducono il concetto di ColumnFamily. A di↵erenza di un database relazionale dove non è possibile avere
attributi multi-valore, poichè gli attributi vengono divisi in attributi atomici, qui vengono raggruppati in column-family. Infatti un column-family
stores permette di scrivere dati chiave mappati con i valori a loro volta
raggruppati in column family multiple. Ogni column family è a sua volta un map di dati ; inoltre ogni column-family è costituita da molteplici
righe, ognuna formata da un chiave e una serie di colonne contenenti i
valori. Spesso tali database sono realizzati per consentire accessi a blog,
8
Capitolo 2. Panoramica dei NoSQL
poichè permettono di inserire link, categorie e tag nelle varie colonne. Un
DB molto noto appartenente a tale categoria è Cassandra.
2.4
Graph Databases
Un Graph Database permette di scrivere entità e relazioni tra più entità. Le Entità sono indicate dai Nodi, che hanno proprietà. Un nodo può
essere visto come l’istanza di un oggetto in un’applicazione. Le Relazioni
sono indicate dagli Archi, che a loro volta possono avere proprietà, la
cui direzione permette di definire o trovare gli schemi comuni tra i nodi.
Fondamentale, come si vedrà, è che qui i dati sono scritti, indicizzati ed
interpretati in vari modi in base alle Relazioni.
Un elemento che li contraddistingue e che ha permesso la di↵usione di tali
DB è legato al modo in cui vengono realizzate le query sui grafi: esse sono
localizzate solamente alla zona o ai nodi di interesse del grafo; ciò permetterà una serie di vantaggi che verranno approfonditi in seguito. Tra i più
noti Graph DB dobbiamo ricordare Neo4j.
9
Capitolo 3
Graph Database
3.1
I Grafi applicati ai Database: Graph Databases
Prima di parlare dei Graph DB, è utile definire il concetto di Grafo.
Un grafo è una collezione di vertices ed edges, o un set di nodes(nodi) e
relationships(relazioni espresse da archi con frecce) che connettono questi. I grafi rappresentano le Entità(attraverso i nodi) e come queste entità
sono connesse(attraverso le relationships). In questo modo tale struttura
permette di modellare tutti i tipi di scenari. Un grafo inoltre deve avere le
seguenti proprietà:
• contenere Nodi e Relazioni;
• i Nodi contengono Proprietà(espresse da valori);
• le Relazioni hanno un nome, sono dirette e hanno sempre un inizio
e una fine;
• le Relazioni possono anche contenere proprietà;
10
Capitolo 3. Graph Database
Un Graph database è un on-line management system che rispetta i metodi CRUD(Create, Remove, Update, e Delete) ed è associato ad un Graph
Data Model.
Come si è detto precedentemente i grafi, se da un lato ci permettono di
esprimere concetti molto complessi in maniera semplice, dall’altro presentano una problematica non trascurabile: non ci sono tecniche universali
abbastanza adeguate che ci permettono di modellare facilmente tale struttura rispetto ad un qualsivoglia problema. In compenso i Graph Databases
o↵rono flessibilità, performance, e si accoppiano bene nei sistemi di
sviluppo agile del software.
3.1.1
Flessibilità
Grazie alla loro flessibilità, lo sviluppatore può non conoscere a priori
le caratteristiche del DB, e quindi tutte le problematiche del dominio che
in futuro si potrebbero presentare con l’espansione dello stesso. Infatti
la flessibilità è data dalla scalabilità orizzontale. I grafi sono additivi, ciò
significa che possiamo aggiungere nuovi tipi di relazioni, nuovi nodi, e
nuovi sotto-grafi per una struttura esistente, senza dover modificare query
e le funzionalità applicative esistenti.
3.1.2
Performance
Una problematica predominante negli RDBMS è legata al costo del
JOIN nelle query, soprattutto in relazione alla dimensione del database.
In un Graph DB il costo tende a rimanere costante al crescere del Data-set,
dal momento che le query sono localizzate alla sola porzione del grafo su
cui agiscono.
11
Capitolo 3. Graph Database
3.1.3
Agilità
Si definiscono sistemi agili quei sistemi che sono in continua evoluzione.
Oggi la necessità da parte delle aziende di cambiare sempre più spesso e
in breve tempo le loro politiche e metodologie di business, ha fatto si
che metodi evolutivi, tra cui le metodologie agili, diventassero sempre più
di↵usi. Inoltre, in parallelo a quelle che sono le necessità di evolvibilità del
software, vi è la necessità di ristrutturare e far evolvere anche i database
da quest’ultimo usati. I Graph Databases sono dei sistemi che, grazie alla
loro scalabilità orizzontale e verticale, e alla località delle query rispetto a
possibili modifiche della stessa struttura del database, si accoppiano bene
con tali metodologie.
3.2
Storing Connection Data
Si osserva che i database relazionali, anche se riescono ad esprimere le
relazioni tra due o più entità, hanno alla base strutture di tipo tabellare,
e l’unico modo per esprimere una relazione è attraverso il JOIN. Il JOIN
però, a sua volta, comporta una serie di problematiche legate alla performance e alla quantità di dati inutili che essa genera e deve gestire. Di
queste porblematiche ne mensioniamo le principali:
• Le JOIN tables aggiungono un’accidentale complessità;
• Overhead legato alla FOREIGN KEY;
Inoltre se da una semplice JOIN passiamo ad una JOIN INNESTATA
tra più tabelle, tali problematiche si amplificano, cosı̀ da ottenere che la
complessità per la risoluzione di una query, dove vi sono JOIN INNESTATE, aumenta enormemente con la profondità. Questo problema è ereditato
12
Capitolo 3. Graph Database
anche da molti altri NoSQL DB, che pur risolvendo molti problemi legati
ai campi nulli e alla ridondanza dei dati grazie alla loro struttura aggregata, non sono performanti rispetto alle relazioni che ci sono all’interno di un
database. I graph DB, basati proprio sul concetto di Relazione, risolvono
questo problema già all’ origine poiché la loro struttura non è tabellare,
nè aggregata. Qui si parla di stored as connection data. Per risolvere tale
problema, i Graph DB usano l’ index-free adjacency dove ogni nodo
ha un esplicito riferimento ai nodi adiacenti e non ha bisogno di ulteriori
indici per trovare questi. Inoltre qui per ottimizzare le graph traversal performance, le informazioni sui nodi, sulle relazioni e sulle proprietà
vengono scritte su file di↵erenti.
Figura 3.1: Struttura dati di un Graph DB
Per dimostrare ciò che è stato appena detto abbiamo considerato un
esperimento fatto da Partner e Vukotic, in cui è stata fatta una query su
13
Capitolo 3. Graph Database
un database di un social networks che avesse l’obiettivo di trovare gli amici
degli amici; date due persone scelte casualmente e un percorso che connettesse loro al più di una profondita di cinque relationships. In un social
network con 1000000 di persone sono stati ottenuti i risultati in figura 3.2,
dove si può osservare la di↵erenza dei tempi ottenuti con l’aumentare della
profondità tra Neo4j (graphDB) e un RDBMS.
Figura 3.2: Confronto tra RDBMS e GRAPH DB
14
Capitolo 4
Realizzazione di un Graph
DB
In questo capitolo descriveremo come modellare un graph DB, quindi
ci serviremo di un graph query language, per mostrare come creare un
database e come fare query. A tale scopo abbiamo deciso di adoperare
Cypher.
4.1
Cypher
Cypher è un declarative graph query language che permette di fare
efficientemente operazioni di query e update (CRUD) su un graph DB.
Cypher è un linguaggio potente, fluido e semplice da imparare e da comprendere. Come la maggior parte dei query language, Cypher è composto
da clausole, di cui alcune fondamentali ed altre opzionali, sia per le query
che per altre operazioni sul database. La semplice query è formata da una
clausola START, seguita da una MATCH e una RETURN.
15
Capitolo 4. Realizzazione di un Graph DB
START:
specifica uno o più punti di partenza (nodi o relationships)
in un grafo. Questi punti di partenza sono ottenuti via indice o accesso
diretto basato su ID del nodo o della relationship.
MATCH:
questa clausola ci permette di indicare come e quali nodi met-
tere in connessione nella query, ossia indica la relazione che c’è tra i nodi.
Essa può mettere più nodi in connessione attraverso un unico match.
RETURN
questa clausola specifica quali nodi, relazioni, e proprietà
espresse dal MATCH dovrebbero ritornare come risultato della query.
Oltre alle tre clausole sopra descritte, essenziali per una query, possiamo usare ulteriori clausole che ci permettono di fare operazioni sul DB o
affinare le query stesse:
WHERE:
ci permette di stabilire dei criteri per filtrare i risultati del
matching.
CREATE, CREATE UNIQUE:
ci permette di creare nuove Rela-
tionships e Nodi.
DELETE:
SET:
rimuove Relazioni, Nodi e proprietà.
setta i valori delle Proprietà.
FOREACH:
UNION:
un’azione di update per ogni elemento della lista.
unisce il risultato di due o più query.
16
Capitolo 4. Realizzazione di un Graph DB
WITH:
concatena parti di query avanzando dalla prima in avanti (simile
al comando piping di UNIX ).
4.2
Esempio di implementazione di Graph DB:
Shakespeare example
In questo paragrafo abbiamo preso un esempio già implementato per
spiegare approfonditamente come realizzare un graph DB e come fare
query, su quest’ultimo.
4.2.1
CREATE del Grafo
Per creare il DB presente in figura 4.1 abbiamo usato la CREATE;
tale create è eseguibile a runtime e ci permette di implementare l’intero
grafo in un unico statement. La procedura in figura 4.1 Crea nodi(rigo 1) e
relazioni(rigo 3) contemporaneamente. Noi potremmo modificare il grafo
in 2 modi: aggiungendo nuove relazioni e nodi al grafo, oppure modificando
le esistenti.
17
Capitolo 4. Realizzazione di un Graph DB
Figura 4.1: Esempio CREATE
18
Capitolo 4. Realizzazione di un Graph DB
4.2.2
QUERY sul Grafo
Ora spiegheremo come realizzare una query che ci restituisca tutte le
performance dei spettacoli scritti da Shakespeare nel Teatro ’Teatre Royal’
di ’Newcastle’.
START
Creato il grafo, dobbiamo fare delle query su questo. In Cy-
pher dobbiamo iniziare una query da uno o più punti di START, chiamati
bound nodes, inoltre, anche se meno frequente possiamo partire anche
da una o più relazioni. Nel nostro esempio se vogliamo scoprire delle informazioni sugli eventi, sul Teatro e su Shakespeare usiamo come punti di
STARD quelli mostrati in figura 4.2.
MATCH
Dopo aver definito i punti di START da cui deve partire la
query, viene la parte chiave della query, attraverso la clausola MATCH.
Qui descriviamo cosa desideriamo trovare all’interno del database. La
clausola MATCH si serve di elementi sintattici opzionali per descrivere
le relazioni su cui vuole fare la ricerca e i criteri della ricerca da fare.
Nell’esempio analizzato in figura 4.2, osserviamo che attraverso il primo rigo restringiamo la ricerca del theater (”Theatre Royal” come indicato dalla START) alla sola città di Newcastel, definita sempre dalla
START con la relazione city; infatti qui associamo theater attraverso la
relazione ” <-[STREET—CITY*1..2]- ” che indica che tale teatro non
può essere associato a più di due città o strade Newcastle. Poi troviamo ”
(theater)<-[:VENUE]-() ”, qui si osserva che non siamo interessati ad un
specifica relazione (in questo caso performance) con tale teatro infatti si
ha un anonymous node, poi siccome non siamo interessati a specificare
nessuna produzione di interesse troviamo ” ()-[:PERFORMANCE OF]>()-[:PRODUCTION OF]-> ” . Infine, troviamo ” (play)<-[:WROTE
19
Capitolo 4. Realizzazione di un Graph DB
PLAY]-(bard) ” che ci indica l’autore (bard:=Shakespeare) e soprattutto
a cosa siamo interessati (che con riferimento al nostro esempio è il ’play’).
RETURN
In questo esempio usiamo la RETURN DISTINCT che in-
dica quale nodo restituire in relazione a possibili vincoli e quali attributi
restituire. nel nostro caso siamo interessati al titolo.
Come abbiamo già detto oltre alle tre clausole fondamentali, per fare
una query possiamo aggiungere delle ulteriori clausole che ci permettono
di filtrare ulteriormente i risultati della RETURN, ad esempio,ne nostro
caso con la WHERE otteniamo solo gli spettacoli la cui data di scrittura
è successiva al 1608.
Figura 4.2: Esempio Query
20
Capitolo 5
Grafi nel mondo Reale
In questo capitolo mostreremo alcuni casi di Graph DB nel mondo
reale, motivando le cause, per cui si è scelto di utilizzare un Graph DB
anzichè un RDBMS o un altro tipo di NoSQL DB.
5.1
Perchè le organizzazioni scelgono i Graph DB
Già abbiamo visto le potenzialità di un Graph DB legate alle performance e all’espressività che questo ci o↵re nella risoluzione di molteplici problemi, ma spesso le organizzazioni prediligono un Graph Database
anche per le seguenti ragioni:
”Minutes to millisenconds” performance
L’obiettivo principale di
molte organizzazioni è legato alla performance delle query per le loro piattaforme. Essendo un DB rivolto per lo più a sistemi transazionali online
o applicazioni web di enormi dimensioni, un requisito fondamentale per
l’utente finale è che il sistema risponda in pochi millisecondi. Nel mondo relazionale, come già si è detto, a causa dell’ enorme dimensione del
data-set e del costo computazionale della JOIN, tali parametri di efficienza
21
Capitolo 5. Grafi nel mondo Reale
sono irraggiungibili. Invece un graph DB, grazie all’ index-free adjacency,
risolve questo problema.
Drastically accelerated development cycles
I graph DB, grazie al
modello basato sui grafi, riduce in maniera naturale il gap semantico che
c’è tra il modello ad ogetti e il modello tabulare. Inoltre anche per quanto
riguarda il dominio su cui verte il database in questione grazie a tale modello, risulta semplice da leggere e comprendere lo stesso modello da parte
di tutti coloro che devono lavorare sul progetto: sia per gli sviluppatori
che per chi si occupa delle problematiche di business, dal momento che entrambi utilizzano i grafi per comprendere e rappresentare le problematiche
in question.
Extreme business responsiveness
In passato i sistemi database, es-
sendo RDBMS, avevano una struttura dati di tipo tabulare e non erano
molto scalabili orizzontalmente; motivo per cui, con l’evoluzione del business era richiesta un’enorme quantità economica per aggiornare tali sistemi
e riadattarli o per fare vere e proprie migrazioni in nuovi sistemi. Di contro
un graph DB, avendo una struttura di tipo free nature, cioè senza schema,
è ben predisposto all’evoluzione.
5.2
Casi d’uso
In questa sezione descriveremo alcuni casi d’uso reali in cui è conveniete
utilizzare un graph DB.
Social
I Social networks, data la loro struttura e i loro scopi, che sono
basati sul concetto di relationship. Dunque per poter migliorare le loro
22
Capitolo 5. Grafi nel mondo Reale
performance e facilitare il loro utilizzo devono avere un database ottimizzato per tali finalità. Basti pensare a Facebook, a cui possiamo associare
il termine ”social graph”. Nei social networks attraverso la semantica dei
graph DB riusciamo farcilmente ad identificare le relazioni dirette o indirette che ci sono tra persone e gruppi. Le relazioni sociali potrebbero
essere esplicite o implicite. Le relazioni Esplicite occorrono in presenza di
un link diretto, come un link di Facebook (amici di facebook); un caso di
relazione implicita si ha quando in un legame tra due nodi, nel caso di facebook tra due amici, si hanno degli intermediari che legano tale relazione
(amico dell’amico).
Geospatial
Nelle applicazioni Geospaziali vengono usati i Graph DB,
poichè la loro struttura è molto performante nel calcolo di rotte tra due
posti in una rete astratta, come ad esempio una strada o una rete ferroviaria, o per trovare dei punti di interesse in una determinata area.
Spesso se il dominio di interesse è quello geospaziale, per la struttura dei
dati viene predileto un R-tree.
23
Capitolo 6
Conclusione
In questo elaborato siamo partiti dal presentare i NoSQL DB muovendoci attraverso le problematiche che hanno portato hobbisti ed aziende ad
investire risorse umane ed economiche per lo sviluppo di tali sistemi, spiegandone caratteristiche, vantaggi e svantaggi rispetto ai sistemi RDBMS.
Poi ci siamo so↵ermati sui GraphDB, partendo dal concetto di Grafo, con
le relative caratteristiche arrivando a spegare come, tale struttura possa
essere utilizzata per modellare un database per un problema di dominio
comune. Inoltre ci siamo concentrati sulle motivazioni per cui tali database fossero, per determinati casi d’uso, molto più performanti rispetto ad
un RDBMS, sia dal punto di vista semantico che prestazionale.
Dopo aver fatto un esempio di Graph DB, abbiamo fatto accenno ad alcuni
casi reali di utilizzo di tale tipologia di database.
Possiamo concludere partendo con un’osservazione fatta sui NoSQL
DB. Se nel nostro dominio applicativo non ci sono tantissime Relazioni
ma il database deve contenere moltissimi dati da dovere gestire e su cui
fare molte operazioni un RDBMS è sconsigliabile, poichè potrebbe non riu-
24
Capitolo 6. Conclusione
scire a soddisfare le performance richieste. Contrariamente con un NoSQL
DB di tipo Key-Value DB o Document DB riusciremmo bene a gestire i
dati, anche se sono eterogenei (presenza di attributi NULL o multi-valore).
Se si ha un dominio in cui le relazioni sono fondamentali e le operazioni da
fare riguardano prettamente i legami che ci sono tra le entità coinvolte si
predilige un Graph DB. I Graph DB grazie alla loro semantica riescono ad
esprimere ed a far emergere informazioni sulle Relazioni che ci sono tra le
Entità, direttamente o indirettamente. Questi sono semplici da comprendere anche per coloro che non conoscono i database.
Certamente si osserva che siamo ancora in uno stato embrionale per poter
comprendere la loro potenzialità rispetto ai sistemi RDBMS, usati comunemente oggi. Ma per come si è evoluta e si sta evolvendo l’informazione,
questi, fra qualche anno, rappresenteranno una gran fetta dei sistemi di
basi di dati.
25
Bibliografia
[1] Pramod J. Sadalage, Martin Fowler, “NoSQL Distilled: A
Brief Guide to the Emerging World of Polyglot Persistence”,
Pearson - Addison-Wesley.
[2] Ian Robinson, Jim Webber e Emil Eifrem, “Graph
Databases”, O’REILLY.
[3] Massimo
Carro,
”NoSQL
http://arxiv.org/pdf/1401.2101.pdf.
Databases”,
[4] http://it.wikipedia.org/wiki/Teorema CAPcite note-3 (visualizzato il 16-11-2014)
[5] Neo4j Manual.
26