Facoltà di Ingegneria Corso di Studi in Ingegneria Informatica Basi di Dati Graph Database MARCO DE MASI matr. N

Transcript

1 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. N

2

3 Indice Introduzione 4 Capitolo 1. Graph Database: Cosa sono Classificazione dei database NoSQL Teoria dei grafi applicata al graph database Nascita ed utilizzo del graph database Caratteristiche del graph database 9 Capitolo 2. Differenze tra database relazionale e a grafo Relationship nei database relazionali e a grafo Differenze tra query con esempio Confronto tra efficienze con esempio Confronto tra modellazione relazionale e a grafo 16 Capitolo 3. Progetti di graph database. Neo4j e Cypher Introduzione a Neo4j Neo4j: un database completamente transazionale Query in Neo4j Cypher per le query sui grafi Esempio con Cypher 27 Bibliografia 29 Ringraziamenti 30 III

4 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

5 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

6 - 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

7 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

8 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

9 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

10 - 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

11 - 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

12 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

13 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

14 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

15 Esempio. Trovare tutti gli indirizzi 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

16 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

17 - 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

18 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 , che nel modello normalizzato potrebbero essere memorizzati in una tabella . 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

19 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

20 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

21 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

22 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

23 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

24 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

25 (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 a-node:user(name= Michael ) MATCH (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

26 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

27 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

28 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

29 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] [4] [5] 29

30 Ringraziamenti 30