Database NoSQL: i GraphDB

Transcript

1 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

2

3

4 Indice Introduzione vi 1 NoSQL Databases Che cos è un NoSQL Database? Breve cenni storici Caratteristiche Teorema di CAP e proprietà BASE Elementi Fondanti RDBMS vs NoSQL Panoramica dei NoSQL Key-Value Databases Document Databases Column-Family Stores Graph Databases Graph Database I Grafi applicati ai Database: Graph Databases Flessibilità Performance Agilità Storing Connection Data iii

5 Indice 4 Realizzazione di un Graph DB Cypher Esempio di implementazione di Graph DB: Shakespeare example CREATE del Grafo QUERY sul Grafo Grafi nel mondo Reale Perchè le organizzazioni scelgono i Graph DB Casi d uso Conclusione 24 Bibliografia 26 iv

6 Elenco delle figure 1.1 Ricapitolazione storica Teorema di CAP Struttura dati di un Graph DB Confronto tra RDBMS e GRAPH DB Esempio CREATE Esempio Query v

7 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

8 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

9 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

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

11 Capitolo 1. NoSQL Databases 1.2 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 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. Perl 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

12 Capitolo 1. NoSQL Databases Figura 1.2: Teorema di CAP availability. Le proprietà BASE esprimono le caratteristiche fondamentali di un No- SQL 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 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

13 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

14 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

15 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 ela 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

16 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 Column- Family. 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

17 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

18 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, ounsetdinodes(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 eunafine; le Relazioni possono anche contenere proprietà; 10

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

20 Capitolo 3. Graph Database 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 INNESTA- TE, aumenta enormemente con la profondità. Questo problema è ereditato 12

21 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

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

23 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 e cientemente 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

24 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 mettere 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 a nare le query stesse: WHERE: ci permette di stabilire dei criteri per filtrare i risultati del matching. CREATE, CREATE UNIQUE: ci permette di creare nuove Relationships e Nodi. DELETE: rimuove Relazioni, Nodi e proprietà. SET: setta i valori delle Proprietà. FOREACH: un azione di update per ogni elemento della lista. UNION: unisce il risultato di due o più query. 16

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

26 Capitolo 4. Realizzazione di un Graph DB Figura 4.1: Esempio CREATE 18

27 Capitolo 4. Realizzazione di un Graph DB 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 Cypher 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

28 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 indica 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 Figura 4.2: Esempio Query 20

29 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 e cienza 21

30 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, essendo 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

31 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

32 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

33 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

34 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 Databases, [4] CAPcite note-3 (visualizzato il ) [5] Neo4j Manual. 26