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’`e un NoSQL Database? Breve cenni storici. . . . . 1 1.2 Caratteristiche . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.2.1 Teorema di CAP e propriet`a 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`a . . . . . . . . . . . . . . . . . . . . . . . 11 3.1.2 Performance . . . . . . . . . . . . . . . . . . . . . . 11 3.1.3 Agilit`a . . . . . . . . . . . . . . . . . . . . . . . . . . 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`e 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, `e 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` a tali da riuscire a soddisfare le esigenze degli utenti. Inizialmente, per gestire queste problematiche si `e cercato di capire come poter migliorare i sistemi RDBMS per tali finalit`a. Si `e osservato che per migliorare le prestazioni legate alla velocit`a si poteva limitare l’uso del JOIN, costruendo tabelle pi` u annidate; ma questa soluzione comportava una serie di problematiche ancora pi` u 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 `e 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`o 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`a descritto che cos’`e un NoSQL DB attraverso la sua storia, le sue caratteristiche, e le di↵erenze rispetto ai Relational Databases. 1.1 Che cos’` e 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`a l’acronimo di questa sigla `e 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` u 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 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`a solo dopo il 2009, bisogna fare un piccolo cenno agli anni precedenti al fine di comprendere qual `e 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 `e 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`a 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`a varie al contrario di un RDBMS in cui fondamentali sono le propriet`a ACID. Dunque, non si ha pi` u come obiettivo principale quello di garantire le propriet`a ACID, ma si parla di propriet` a BASE, in relazione al Teorema di CAP. Dunque, cardine di questi DB, `e la disponibilit` a dei dati e la relativa velocit` a nel recuperare gli stessi a discapito della consistenza. 1.2.1 Teorema di CAP e propriet` a BASE Nei NoSQL DB, la consistenza non `e una propriet`a 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 `e impossibile per un sistema informatico distribuito fornire simultaneamente tutte e tre le seguenti garanzie: Coerenza, Disponibilit` a, Tolleranza di Partizione. Secondo il teorema, un sistema distribuito `e in grado di soddisfare al massimo due di queste garanzie allo stesso tempo, ma non tutte e tre, cit:[4]. Tale teorema pu`o essere espresso graficamente come in figura 4.1 Ora, applicando questo teorema ad un sistema che deve rispettare le propriet`a BASE, si osserva che tra le tre propriet`a sopra indicate, sacrificabile `e 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`o parlare di Latency. La Latency ci indica il limite di tempo che l’utente `e disposto a sopportare per definire un sistema 3 Capitolo 1. NoSQL Databases Figura 1.2: Teorema di CAP availability. Le propriet`a BASE esprimono le caratteristiche fondamentali di un NoSQL DB, infatti queste, sacrificando la consistenza, mirano a garantire la disponibilit`a dell’informazione e la scalabilit`a del sistema. Sono esprimibili dal seguente acronimo: • Basically Available: bisogna garantire la dispnibilit`a delle informazioni; • Soft State: il sistema pu`o 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`a detto, punta a garantire alte performance di velocit`a e disponibilit`a a costi contenuti, a discapito della 4 Capitolo 1. NoSQL Databases consistenza. Per fare ci`o questi devono avere i seguenti elementi fondamentali: • Ambiente Multi-Nodo: il sistema `e distribuito su pi` u 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 `e possibile gestire tali dati in maniera molto semplice; • Replica delle Informazioni: i dati distribuiti su pi` u nodi a loro volta vengono duplicati su ulteriori nodi per avere una maggiore integrit`a e performance; ` : grazie ai meccanismi usati per • Eliminazione della Complessita distribuire il carico si cerca di eliminare la complessit`a 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` a e Costo dei NoSQL. Standardizzazione: questo elemento `e a vantaggio degli RDBMS, poich`e 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 `e facilmente applicabile ad un altro database RDBMS; quindi anche lo stesso database realizzato in un dato ambiente `e 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`o non `e possibile perch´e 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` a 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 `e 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` u 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`a 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`o 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 `e data proprio dal value nei quali `e rappresentato da un tipo di cui sappiamo le caratteristiche, mentre qui il value pu`o essere definito come un blob(oggetto o struttura di cui non conosciamo come `e fatto). Proprio per la struttura appena descritta, bisogna osservare che questo database permette una facile scalabilit`a 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 `e 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`e `e possibile vedere i documenti contenuti come dei value esaminabili. Da ci`o `e semplice osservare che, in questo caso `e possibile estendere le query anche sulle informazioni contenute nei documenti. Questi DB sono molto usati oggi sul mercato, poich´e oltre ad avere dati aggregati, riescono bene a gestire le query. Tra essi uno dei pi` u di↵usi `e 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 `e possibile avere attributi multi-valore, poich`e 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 `e a sua volta un map di dati ; inoltre ogni column-family `e 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`e permettono di inserire link, categorie e tag nelle varie colonne. Un DB molto noto appartenente a tale categoria `e Cassandra. 2.4 Graph Databases Un Graph Database permette di scrivere entit` a e relazioni tra pi` u entit` a. Le Entit`a sono indicate dai Nodi, che hanno propriet`a. Un nodo pu`o essere visto come l’istanza di un oggetto in un’applicazione. Le Relazioni sono indicate dagli Archi, che a loro volta possono avere propriet`a, la cui direzione permette di definire o trovare gli schemi comuni tra i nodi. Fondamentale, come si vedr`a, `e 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 `e 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`o permetter`a una serie di vantaggi che verranno approfonditi in seguito. Tra i pi` u 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, `e utile definire il concetto di Grafo. Un grafo `e 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`a(attraverso i nodi) e come queste entit`a 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`a: • contenere Nodi e Relazioni; • i Nodi contengono Propriet`a(espresse da valori); • le Relazioni hanno un nome, sono dirette e hanno sempre un inizio e una fine; • le Relazioni possono anche contenere propriet`a; 10 Capitolo 3. Graph Database Un Graph database `e un on-line management system che rispetta i metodi CRUD(Create, Remove, Update, e Delete) ed `e associato ad un Graph Data Model. Come si `e 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` a, performance, e si accoppiano bene nei sistemi di sviluppo agile del software. 3.1.1 Flessibilit` a Grazie alla loro flessibilit`a, lo sviluppatore pu`o 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`a `e data dalla scalabilit`a orizzontale. I grafi sono additivi, ci`o 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`a applicative esistenti. 3.1.2 Performance Una problematica predominante negli RDBMS `e 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` a Si definiscono sistemi agili quei sistemi che sono in continua evoluzione. Oggi la necessit`a da parte delle aziende di cambiare sempre pi` u 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` u di↵usi. Inoltre, in parallelo a quelle che sono le necessit`a di evolvibilit`a del software, vi `e la necessit`a di ristrutturare e far evolvere anche i database da quest’ultimo usati. I Graph Databases sono dei sistemi che, grazie alla loro scalabilit`a orizzontale e verticale, e alla localit`a 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` u entit`a, hanno alla base strutture di tipo tabellare, e l’unico modo per esprimere una relazione `e attraverso il JOIN. Il JOIN per`o, a sua volta, comporta una serie di problematiche legate alla performance e alla quantit`a di dati inutili che essa genera e deve gestire. Di queste porblematiche ne mensioniamo le principali: • Le JOIN tables aggiungono un’accidentale complessit`a; • Overhead legato alla FOREIGN KEY; Inoltre se da una semplice JOIN passiamo ad una JOIN INNESTATA tra pi` u tabelle, tali problematiche si amplificano, cos`ı da ottenere che la complessit`a per la risoluzione di una query, dove vi sono JOIN INNESTATE, aumenta enormemente con la profondit`a. Questo problema `e 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`a all’ origine poich´e la loro struttura non `e tabellare, n`e 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`a vengono scritte su file di↵erenti. Figura 3.1: Struttura dati di un Graph DB Per dimostrare ci`o che `e stato appena detto abbiamo considerato un esperimento fatto da Partner e Vukotic, in cui `e 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` u 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`o osservare la di↵erenza dei tempi ottenuti con l’aumentare della profondit`a 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 `e un declarative graph query language che permette di fare efficientemente operazioni di query e update (CRUD) su un graph DB. Cypher `e un linguaggio potente, fluido e semplice da imparare e da comprendere. Come la maggior parte dei query language, Cypher `e composto da clausole, di cui alcune fondamentali ed altre opzionali, sia per le query che per altre operazioni sul database. La semplice query `e 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` u 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’`e tra i nodi. Essa pu`o mettere pi` u nodi in connessione attraverso un unico match. RETURN questa clausola specifica quali nodi, relazioni, e propriet`a 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`a. setta i valori delle Propriet`a. FOREACH: UNION: un’azione di update per ogni elemento della lista. unisce il risultato di due o pi` u 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`a 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 `e 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` u punti di START, chiamati bound nodes, inoltre, anche se meno frequente possiamo partire anche da una o pi` u 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`a 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`o essere associato a pi` u di due citt`a 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 `e 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`a 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 `e 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 `e scelto di utilizzare un Graph DB anzich`e un RDBMS o un altro tipo di NoSQL DB. 5.1 Perch` e le organizzazioni scelgono i Graph DB Gi`a abbiamo visto le potenzialit`a di un Graph DB legate alle performance e all’espressivit`a 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 `e legato alla performance delle query per le loro piattaforme. Essendo un DB rivolto per lo pi` u a sistemi transazionali online o applicazioni web di enormi dimensioni, un requisito fondamentale per l’utente finale `e che il sistema risponda in pochi millisecondi. Nel mondo relazionale, come gi`a si `e 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’`e 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`a 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`e senza schema, `e ben predisposto all’evoluzione. 5.2 Casi d’uso In questa sezione descriveremo alcuni casi d’uso reali in cui `e 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`a. 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`e la loro struttura `e 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 `e 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` u 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 `e sconsigliabile, poich`e 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`a 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`a, 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`a rispetto ai sistemi RDBMS, usati comunemente oggi. Ma per come si `e 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
© Copyright 2024 Paperzz
