Panoramica dei più diffusi NoSQL Database

Transcript

1 Scuola Politecnica e delle Scienze di Base Corso di Laurea in Ingegneria Informatica Elaborato finale in Basi di Dati Panoramica dei più diffusi NoSQL Database Anno Accademico 2013/2014 Candidato: Buonocore Salvatore matr. N

2

3 Indice Indice... III Introduzione... 4 Capitolo 1: Sistemi NoSQL Il Teorema CAP Classificazione dei Database NoSQL Key-Value stores Document-Oriented stores Graph stores Column-oriented stores Capitolo 2: MongoDB Caratteristiche e strumenti Interrogazione Persistenza e velocità La Shell di MongoDB Inserimento Lettura Cancellazione Aggiornamento di un documento Capitolo 3: CouchDB Modello dei dati JSON Replicazione Le API di CouchDB Server API Database API Document API Replication API Confronto con MongoDB Capitolo 4: Neo4j Caratteristiche e strumenti Proprietà Creazione di un grafo Neo4j Query in Neo4j Traversal Conclusioni Bibliografia... 27

4 Introduzione Negli ultimi anni tecniche e strumenti per la persistenza e la ricerca dei dati hanno avuto una forte crescita. In particolare nel 1998 l'italiano Carlo Strozzi conia il termine NoSQL, acronimo di Not only SQL, usato per identificare tutti quei database che non fanno uso di un modello di dati relazionale. In questi, concetti come tabella, indici e chiavi non è detto che siano presenti. Solo a partire dal 2009 però questo movimento ha mostrato una rapida crescita, sono infatti già molte le aziende che decidono di passare a questo tipo di database. Tra i pionieri troviamo Google con il suo BigTable e Amazon che ha dato vita a DynamoDB. Entrambi i DB hanno dimostrato la necessità di uscire dai classici schemi relazionali per permettere un'efficiente scalabilità dei loro servizi. Da questi esperimenti sono nati i primi database NoSql, ognuno caratterizzato da strutture dati diverse e altamente ottimizzate, ma che comunque presentano caratteristiche in comune quali: - Schema free. - Gestione di un'enorme quantità di dati garantendone un rapido accesso. - Facilità di replicazione. - Utilizzo di api per l'interfacciamento con i più noti linguaggi di sviluppo. 4

5 Capitolo 1: Sistemi NoSQL La necessità di sviluppare nuove applicazioni che non possono essere affrontate con il tradizionale approccio relazionale, ha portato a ricercare una soluzione alternativa ai database relazionali che può essere spiegata da due principali esigenze: La continua crescita del volume di dati da memorizzare. La necessità di elaborare grandi quantità di dati in poco tempo. Queste nuove necessità sono dovute all aumento esponenziale del numero di utenti della rete, alla diffusione sempre maggiore dell OpenID, allo sviluppo di sinergie tra le varie community e i fornitori di servizi, ma anche alla crescente disponibilità di dispositivi con accesso ad Internet. Per far fronte alla necessità di gestire quantità di dati sempre maggiori e a velocità sempre più elevate, i nuovi sistemi di memorizzazione si sono evoluti per essere più flessibili, utilizzando modelli di dati meno complessi per aumentare le prestazioni nella gestione e nell interrogazione dei dati. Inoltre, questi sistemi mostrano peculiarità che possono tornare molto utili: Abbracciano totalmente la filosofia open-source, a differenza dei database relazionali che invece spesso non lo sono. I dati sono altamente portabili su sistemi differenti. 5

6 Non si definisce uno schema rigido per cui non esistono limiti o restrizioni ai dati memorizzati. Velocità di esecuzione, interrogazione di grosse quantità di dati e possibilità di distribuirli su più sistemi, con un meccanismo totalmente trasparente all utilizzatore. Si focalizzano su una scalabilità orizzontale e non verticale come quelli relazionali. 1.1 Il Teorema CAP Nel 2000 Eric Brewer alla conferenza Principle of Distributed Computing presentò il Teorema del CAP, dove ogni lettera dell'acronimo è una caratteristica del sistema distribuito su cui si sta lavorando: Consistency (Coerenza): dopo una modifica tutti i nodi del sistema distribuito riflettono la modifica. Availability (Disponibilità): ad una richiesta, il sistema è sempre in grado di dare una risposta. Partition Tollerance (Tolleranza al Partizionamento): se le comunicazioni si interrompono tra due punti del sistema, il sistema non fallisce ma continua ad essere disponibile. Secondo il teorema, avere tutte e tre queste caratteristiche in un sistema distribuito in un determinato momento è impossibile, ma si può scegliere quale delle due avere a discapito della terza. Amazon, ad esempio, per garantire una migliore esperienza all utente, e avendo a che fare con la tolleranza al partizionamento, scelse di privilegiare le caratteristiche AP del CAP, rinunciando ad avere un sistema sempre consistente. 1.2 Classificazione dei Database NoSQL I Criteri fondamentali in base ai quali possiamo confrontare i diversi Database NoSQL sono: Scalabilità: Capacità di un sistema di accrescere o decrescere le proprie prestazioni a seconda delle necessità. 6

7 Prestazione: Solitamente viene stimata tramite un applicazione di benchmark che verifica i vantaggi su certi tipi di operazioni. Consistenza: Capacità di eseguire una transizione dall inizio alla fine senza l interferenza di altre transizioni., cioè portare la base di dati da uno stato consistente ad un altro. Sulla base di questi criteri distinguiamo principalmente 4 grandi gruppi di basi di dati NoSQL: 1. Key/Value: Definiti da un semplice dizionario/mappa che permette all'utente di recuperare e aggiornare il valore memorizzato conoscendo la sua chiave. 2. Document-oriented: Memorizza le informazioni come collezioni di documenti. Un documento ha un formato riconosciuto (JSON, XML, etc.) che permette poi al server di eseguire delle query sui dati. 3. Graph: Rappresentano perfettamente una realtà composta da una fitta rete di connessioni e la modellano sotto forma di nodi e rami di un grafo. Ai nodi, come ai singoli rami, vengono associate le informazioni attraverso Key-Value store. 4. Column-oriented: Sistemi che utilizzano ancora le tabelle ma che non fanno alcun tipo di join. Le informazioni non sono memorizzate per riga bensì per colonna. 7

8 Altre importanti categorie sono: 5. Multi-Model: sono in grado di memorizzare diversi tipi di modelli di dati, agendo come un Key/Value store o anche come un document store e fornendo meccanismi di query per tutti i modelli di dati. Oltre alla struttura "multi-livello" questi DB possono non avere nient'altro in comune. 6. Object-oriented: Modello nel quale l informazione è rappresentata sotto forma di oggetti, così come nei linguaggi di programmazione ad oggetti quali java e c++. Attualmente la più grande base di dati del mondo, allo Stanford Linear Accelerator Centre, utilizza questa tipologia di DBMS; contenendo oltre 1000 TB di dati e con un tasso di assorbimento record, per un DB commerciale, di 1 TB per ora. 7. Multidimensional: DB strutturati per ottimizzare l elaborazione analitica online (OLAP online analytical processing) e il data warehouse. I dati vengono presentati agli utenti come un ipercubo, ovvero un array multidimensionale dove ogni singolo dato è contenuto in celle accessibili attraverso diversi indici. 8. Multivalue: hanno un metodo di archiviazione dei dati più flessibile della tabella bidimensionale dei DB relazionali, consentendo di memorizzare più campi all interno di un unico campo. In questi sistemi, il DB viene chiamato ACCOUNT, la tabella FILE e la colonna è un ATTRIBUTO composto da un ATTRIBUTO MULTIVALUE e un ATTRIBUTO SUBVALUE, per poter memorizzare valori multipli nello stesso attributo Key-Value stores Basati sul concetto di Associative array, ossia una semplice struttura in grado di contenere le coppie chiave/valore. Generalmente la chiave, come nei database relazionali, è un identificativo univoco grazie al quale è possibile ricercare ed identificare i dati presenti nel database. Solitamente gli Associative array sono implementati attraverso Hash Table e consentono le seguenti operazioni: ADD: Per aggiungere un elemento all array. 8

9 REMOVE: Per eliminare un elemento dall array. MODIFY: Per cambiare il valore associato ad una data chiave. FIND: Per trovare un valore nell array tramite la chiave. Queste appena elencate risultano essere anche le operazioni fornite dai database di tipo Key/Value, operazioni semplici, che garantiscono tempi di esecuzione costanti. Le basi di dati appartenenti a questa famiglia presentano un modello di dati abbastanza semplice, ma per quanto riguarda la scalabilità orizzontale, ossia la capacità di far fronte alla crescita dei dati aggiungendo nodi alla struttura, mostrano aspetti notevolmente più sofisticati Document-Oriented stores Sistemi di questo tipo possono essere implementati come strato sopra un DB relazionale o a oggetti. I dati non sono memorizzati più in tabelle con campi uniformi per ogni record come nei database relazionali, ma ogni record è salvato come documento. Quest ultimo possiede determinate caratteristiche e gli si possono aggiungere un qualsiasi numero di campi con qualsiasi lunghezza. Documento Ogni implementazione di questo sistema differisce nei dettagli della definizione del documento, ma comunque dati o informazioni vengono incapsulati e codificati in base ad uno standard, i più comuni sono XML, YAML, PDF. In figura 1.1, alla pagina successiva, è mostrato un esempio di documento: 9

10 Fig. 1.1 Differentemente dai campi delle basi di dati relazionali, che possono rimanere vuoti, in sistemi Document-oriented non ci sono campi vuoti in nessun documento. I documenti sono indirizzati nella base dati attraverso keys univoche e solitamente il DB mantiene un indice delle chiavi che consente un più veloce recupero del documento. Il recupero può avvenire non solo attraverso la semplice ricerca per chiave, ma anche attraverso API o con un semplice linguaggio di query in base al contenuto, ossia basandosi sul valore di un determinato campo Graph stores Questa tipologia di Base di Dati utilizza nodi e archi per rappresentare e archiviare le informazioni, risultando più veloce nell associazione di insiemi di dati rispetto ai DB strettamente relazionali. Inoltre essi non richiedono le onerose operazioni di join, permettono di scalare più facilmente grandi quantità di dati e sono molto più adeguati nello gestire dati mutevoli con schemi evolutivi. 10

11 Modelli di riferimento Facendo riferimento alla teoria dei grafi, attualmente, i modelli di riferimento per l implementazione di basi di dati con questo schema sono due: il property graph model e il resource description framework graph (RDF). Il secondo è il modello di riferimento del Web semantico e i database che lo utilizzano sono anche noti come Triple Store, Quad Store, o RDF Store Column-oriented stores In questa tipologia di BD i dati, come indica il nome stesso, sono memorizzati assieme per colonna, mantenendo così la classica organizzazione in righe e colonne. Per evitare la presenza di dati null, i database orientati a colonna permettono ad ogni riga di avere un set diverso di colonne, che possono essere aggiunte se necessario o tolte se inutilizzate. Per quanto riguarda la struttura dei dati, in questi sistemi, ogni valore può essere una stringa, o se l implementazione lo permette, qualsiasi altro tipo di dato primitivo. Non avendo uno schema formale, non c è nessuna specifica che indichi gli attributi obbligatori e il loro tipo. I vantaggi offerti da questo tipo di orientamento si vedono soprattutto in lettura: Le query mirano a recuperare valori soltanto da determinate colonne e quindi non da tutta la riga. Essendo composte da tipi di dati uniformi, le colonne risultano essere più facili da comprimere, a vantaggio della velocità di esecuzione. 11

12 Capitolo 2: MongoDB MongoDB possiede un modello di dati orientato ai documenti per poter ottenere elevate prestazioni in lettura e in scrittura e risultare facilmente scalabile. Progettato per essere flessibile e potente, combina le caratteristiche dei Key-Value stores, semplici, veloci e scalabili, con le caratteristiche dei DB relazionali, per il loro potente linguaggio di interrogazione. Per questo motivo, esso è stato adottato anche da importanti aziende come ebay che usa MongoDB per i suggerimenti della ricerca o The New York Times che usa MongoDB nella sua applicazione di caricamento di fotografie. 2.1 Caratteristiche e strumenti Partendo dall alto, MongoDB gestisce più basi di dati, ognuna delle quali contiene un insieme di collezioni, le quali sono composte da più documenti costituiti da un certo numero di campi che sono coppie chiave-valore Interrogazione MongoDB permette interrogazioni dinamiche o ad hoc, ovvero si può evitare di definire in anticipo quali interrogazioni il sistema dovrà accettare, permettendo agli utenti di trovare i 12

13 dati usando qualsiasi condizione. Si può quindi, in base ai valori che si vogliono cercare, scrivere un interrogazione sempre diversa. Una classica interrogazione in MongoDB potrebbe essere: che ritorna tutti i posts taggati come politics che hanno 10 voti o più. Potendo effettuare interrogazioni con qualsiasi condizione, MongoDB raggiunge il suo scopo di mantenere alta la potenza di interrogazione. Per migliorare ulteriormente le prestazioni sulle interrogazioni, il query optimizer di MongoDB utilizza una struttura dati che raccoglie informazioni sui valori dei campi indice nei documenti di una collezione, permettendo così di ordinarli e attraversarli più velocemente. Ogni collezione può avere più di 64 indici utilizzabili anche per i documenti Persistenza e velocità Definiamo la velocità in scrittura come il volume di operazioni di inserimento, aggiornamento o cancellazione che il sistema può elaborare in un determinato periodo di tempo. La persistenza invece, si riferisce alla garanzia che queste operazioni siano effettuate in modo permanente. In MongoDB è possibile scegliere tra diverse semantiche di scrittura, quelle di default sono di tipo fire-and-forget, ossia le operazioni di scrittura sono inviate attraverso un socket TCP senza richiesta di risposta da parte del DB. Se l utente richiede una risposta, si può usare la modalità safe mode. 2.2 La Shell di MongoDB La shell è uno strumento che permette di amministrare e manipolare i dati del DB e in MongoDB è basata sul linguaggio JavaScript. In questi sistemi, database e collezioni vengono creati solo quando viene inserito un documento Inserimento Il metodo insert permette di inserire un documento in una collezione. Un esempio di linea di comando è il seguente: 13

14 Tramite questa operazione si aggiunge al documento una chiave detta _id, che rappresenta l identificatore unico e globale nel sistema. Infatti, in MongoDB ogni documento deve necessariamente avere un _id, che se non presente, verrà creato in automatico. Dopo l inserimento, la struttura dati viene convertita in BSON (formato binario che memorizza qualsiasi documento come stringa di byte) e poi ricevuta dal DB che controlla la validità del campo _id e la dimensione, 4MB massimo Lettura Popolato il DB, è possibile cercare un documento all interno di esso grazie al metodo find, che ritorna tutti i documenti di una collezione. Si può però aggiungere a questo metodo un query selector, ovvero un documento che viene confrontato con tutti quelli presenti nella collezione per trovare quello che si sta cercando. Un esempio può essere: Cancellazione Per eliminare documenti da una collezione si invoca il metodo remove che, chiamato senza alcun parametro, elimina tutti i documenti della collezione, altrimenti è necessario specificare un criterio di rimozione come nella seguente linea di codice: che elimina un documento con il valore mario associato alla chiave username. 2.3 Aggiornamento di un documento MongoDB offre due metodi per aggiornare un documento: Rimpiazzare completamente il documento. Usare combinazioni di operatori di aggiornamento per modificare uno specifico campo del documento (aggiornamento mirato). Per rimpiazzare completamente un documento il DB deve prima ritornarlo. In seguito, il documento viene modificato dal lato client e si emette l aggiornamento con il documento 14

15 modificato. Si può anche modificare uno specifico campo se si è a conoscenza dell _id del documento da modificare. Infine il documento modificato viene passato al metodo update. Con l aggiornamento mirato invece, il metodo update richiede due argomenti, il primo identifica il documento da aggiornare e il secondo come deve essere aggiornato, ad esempio: che aggiorna il campo del documento specificato. Questo secondo approccio consente migliori prestazioni, in quanto elimina il tempo di andata e ritorno del documento dal server. 15

16 Capitolo 3: CouchDB Scritto in Erlang e sviluppato da Apache Software Foundation, CouchDB è una base di dati open source che presenta un approccio nuovo rispetto alle basi di dati relazionali. I vantaggi si riscontrano soprattutto nel modo di strutturare, salvare e compiere operazioni di interrogazione, filtraggio e replicazione dei dati. Risulta inoltre essere di facile comprensione perché: La comunicazione con il DB è effettuata grazie al protocollo HTTP, infatti è scelto già da molti sviluppatori che lavorano in ambito Web. Basato sui documenti, esso consente più flessibilità ai dati che evolvono la loro struttura nel tempo Se si verifica un problema, questo rimane isolato nella sua operazione, senza propagarsi nel server. (fault-tolerant) La struttura di CouchDB è basata anche sui Key-value stores consentendo così accessi rapidi ai documenti sia in lettura che in scrittura grazie all utilizzo di una chiave. 16

17 3.1 Modello dei dati Come in MongoDB, essendo orientato ai documenti, anche CouchDB offre un formato per i dati molto flessibile, consentendo di modificare la struttura con semplicità. Scritti in linguaggio JSON i documenti permettono di rappresentare meglio le informazioni reali JSON Basato su un sottoinsieme della sintassi di JavaScript, JSON risulta essere un formato semplice e chiaro, facile da generare e analizzare. JSON viene utilizzato da CouchDB per ogni comunicazione contenente strutture dati. Alcuni dei tipi di dati supportati, come in JavaScript, sono: Numbers: interi positivi e negativi. String: caratteri Unicode. Boolean: valori booleani (true o false). Array: liste di valori. Object: liste di coppie Chiave-Valore Replicazione La replicazione dei dati in CouchDB è un processo unidirezionale, ossia passa da un DB sorgente a uno destinatario ed è incrementale, in modo tale che in caso di interruzione dell operazione si possa riprendere dal punto in cui il processo si era interrotto. CouchDB svolge l operazione di replicazione dei dati in maniera molto efficiente. Esso confronta prima di tutto i due DB per trovare quali documenti sono diversi, per poi trasmettere i soli documenti che hanno una versione più aggiornata, grazie al numero di sequenza. In questi sistemi, in caso di malfunzionamenti della rete, un singolo server può continuare a fornire operazioni in lettura e scrittura, per poi sincronizzare i dati con gli altri server al ripristino del collegamento. CouchDB rispetta solo le proprietà di disponibilità e tolleranza al partizionamento del teorema CAP, ed è così eventualmente coerente. 17

18 3.2 Le API di CouchDB Il DBMS fornisce quattro principali categorie di API per poter interagire con esso: 1. Server 2. Database 3. Documents 4. Replication Per analizzare queste categorie verrà utilizzato curl, strumento per il trasferimento dei dati con sintassi URL, che ovviamente supporta il metodo HTTP Server API Digitando la riga di comando: si ricevono informazioni riguardo l istanza di CouchDB in esecuzione. Nell URL viene specificato l indirizzo IP del server, 5984 è invece la porta di default. La risposta del server è una stringa in formato JSON: Database API Creare un database Usando l opzione curl -X, che consente di usare il metodo PUT, è possibile realizzare un database specificandone il nome nella seconda parte dell URL: In caso di esito positivo dell operazione il server risponde con: Informazioni sul database Il comando che permette di ottenere informazioni su uno specifico DB è invece il GET: La stringa di risposta del server contiene varie informazioni, tra cui: il numero di 18

19 documenti contenuti nel DB in questione, la data della sua creazione e la dimensione dei dati. Eliminare un database Fornendo il percorso, per eliminare un database basta usare il comando DELETE: Document API In CouchDB, come in MongoDB, la struttura dati centrale è il documento, sul quale è possibile compiere diverse operazioni: Inserimento L inserimento può essere effettuato grazie a due metodi: il POST inserisce un nuovo documento senza specificare l identificatore, invece il PUT inserisce l identificatore alla fine dell URL. In entrambi i casi, il documento da inserire nel body della richiesta si indica con il comando d: Lettura Per ottenere un documento è necessario specificare l identificatore nell URL e usare il metodo GET: Così facendo il server restituisce il documento con tutti i suoi campi, l identificatore e il numero di revisione Replication API Per replicare un DB in locale, ad esempio per funzioni di backup, si deve innanzitutto 19

20 creare il database di destinazione: Creato recipes-replica come destinazione si procede alla copia con il metodo POST: Questo processo mantiene aperta la connessione tra i due database per tutta la durata dell operazione e può richiedere molto tempo. 3.3 Confronto con MongoDB CouchDB oltre che ad un affidabilità maggiore ha come punto di forza un interfaccia utente semplice ed intuitiva, non proprio come la shell con interprete javascript di MongoDB. Aggiornamento dati CouchDB offre maggiore libertà di design introducendo però il problema della compattazione. MongoDB invece, mette a disposizione una maggiore velocità in scrittura e offre un notevole risparmio di memoria di archiviazione, non tenendo però memoria delle versioni. Query MongoDB permette query dinamiche offrendo inoltre un valido strumento per ottimizzarle, con la creazione di indici se necessario. CouchDB invece, usa un particolare sistema per generare indici e ottimizzare le query, che però devono essere predefinite necessariamente. 20

21 Capitolo 4: Neo4j Sviluppato completamente in java, Neo4j è un DB a grafo open source totalmente transazionale che emerge rispetto alla concorrenza. Infatti supporta Cypher, Gremline e Traversal, i principali metodi per eseguire query su una base di dati a grafo. Inoltre grazie alle diverse librerie che possiede, è possibile utilizzare questo DB con java, PHP etc. 4.1 Caratteristiche e strumenti Questa base di dati trova utilizzo sia in modalità embedded che server. Nella prima modalità il DB viene incorporato nell applicazione ed eseguito all interno della macchina virtuale java (JVM), ossia nello stesso processo ma accettando thread concorrenti. In modalità server il database è un processo a sé stante, a cui si accede facendo delle query e ricevendo i dati in remoto. Inoltre, il server consente l utilizzo di plugin per filtrare i dati in input e in output e per servizi aggiuntivi come ad esempio le query spaziali. Per l uso comune Neo4j si basa sulle transazioni e solo dopo averne aperta una è possibile creare nodi e assegnarvi delle proprietà. 21

22 4.1.1 Proprietà Differentemente da tutti gli altri database non relazionali Neo4j supporta completamente le proprietà ACID: Atomicità: Le esecuzioni parziali non sono ammesse; ossia una transazione, che può contenere operazioni multiple al suo interno, è indivisibile (se fallisce una delle operazioni allora fallisce l intera transazione). Coerenza: Dopo una scrittura, tutti i client che accederanno al DB leggeranno gli ultimi aggiornamenti. Isolamento: Le operazioni di una specifica transazione sono isolate l una dalle altre, di conseguenza tutte le transazioni saranno eseguite in modo isolato. Durabilità: I dati scritti e memorizzati saranno disponibili anche dopo il riavvio del DB. 4.2 Creazione di un grafo Neo4j Il primo passo per la creazione di un grafo Neo4j, attraverso le API native dello stesso, consiste nell istanziare il database, come mostrato nella seguente linea di codice: Considerando un esempio di un grafo, rappresentante due stanze collegate in entrambe le direzioni da un passaggio, bisogna definire, tramite enum, un tipo di relazione: In questo esempio è stato creato il tipo di relazione PASSAGGIO, che servirà a collegare le due room implementate di seguito: 22

23 Queste stanze rappresentano i nodi del grafo, collegati tra di loro attraverso il metodo createrelationshipto() : Ottenendo una relazione che collega i nodi in entrambe le direzioni. 4.3 Query in Neo4j A differenza dei classici database relazionali Neo4j è in grado di eseguire molto più velocemente le operazioni sui dati connessi. Per comprendere meglio come opera Neo4j prendiamo come esempio il caso di un social network. Nello schema rappresentato in figura 4.1, gli utenti collegati tra loro sono amici. Fig. 4.1 In questo esempio gli utenti rappresentano i nodi, le loro amicizie rappresentano le relationship tra i nodi stessi. Essendo strutturato a grafo, neo4j non presenta né tabelle né comandi come select e join, quindi le query vengono effettuate grazie ad un potente concetto matematico della teoria dei grafi, chiamato graph traversal, che rende il DB 23

24 potente per poter trattare dati di grandi volumi. Ma questo non è l unico metodo messo a disposizione da Neo4j, infatti per eseguire query su basi di dati è possibile scegliere tra: Cypher, Gremlin, Traversal Traversal L attraversamento è un operazione (fondamentale per il retrival dei dati) che percorre il grafo muovendosi solo tra nodi collegati con le relationship. Interrogando il DB con questo metodo si portano in conto solo i dati richiesti, mantenendo così, a prescindere dalla quantità dei dati, un rendimento prevedibile. Per poter avviare l attraversamento, si deve prima selezionare il nodo dal quale si desidera partire, dopodichè è possibile effettuare l attraversamento seguendo le relationship e raccogliendo i nodi visitati. L attraversamento continua poi da nodo a nodo, fin quando non finisce il proprio compito e termina. Ritornando al precedente esempio del social network, supponiamo di voler trovare gli amici di un utente X, ossia di voler visitare i nodi di profondità 1 partendo da X. L attraversamento in questo caso indipendentemente dal numero di nodi e relazioni nel grafo, visita solo i nodi collegati direttamente a X. Fig

25 Come si può intuire da questo semplice esempio in figura 4.2, Neo4j è in grado di fornire ottime prestazioni anche con i dati in larga scala. Infatti passando dal caso esaminato a un caso con un milione di utenti, l aumento di più di mille volte del volume dei dati, non influenza le prestazioni di Neo4j. 25

26 Conclusioni In questa tesi dapprima si sono spiegati i motivi che hanno portato alla nascita del movimento NoSQL, come la necessità di dover gestire grosse quantità di informazioni pur mantenendo una struttura flessibile nel tempo, dopodiché si è passati al classificare questi DBMS in diverse famiglie. Le principali di queste, sono state oggetto di analisi, accennando ai concetti strutturali sulle quali si basano, per poi spiegarne il funzionamento. Sono poi stati analizzati nello specifico tre database, i primi due, MongoDB e CouchDB, sono entrambi document-oriented, mentre il terzo Neo4j ha una struttura organizzata a grafo. Di questi, si sono approfonditi i dettagli strutturali, i concetti sui quali si basano e gli obiettivi che si pongono, per poi andare ad analizzare nello specifico importanti funzioni, come le operazioni di inserimento e cancellazione, ma anche il modo di interrogare il database. Vantando ottime prestazioni e capacità di adattamento ad una tecnologia in frequente aggiornamento, i sistemi NoSQL sono subito stati adottati e sviluppati dalle più grandi aziende, ottenendo in alcuni casi un efficienza irraggiungibile dai classici DB relazionali. 26

27 Bibliografia [1] Jonas Partner, Aleksa Vukotic, Nicki Watt, 2013, Neo4j in Action [2] [3] [4] [5] [6] [7] [9] Alessandro Rezzani, Big Data: Architettura, tecnologie e metodi per l utilizzo di grandi basi di dati, Maggioli Editore, 2013 [10] 27