Elaborato Buonocore Salvatore N46000498

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. N46000498
Indice
Indice .................................................................................................................................................. III
Introduzione ......................................................................................................................................... 4
Capitolo 1: Sistemi NoSQL ................................................................................................................. 5
1.1 Il Teorema CAP ......................................................................................................................... 6
1.2 Classificazione dei Database NoSQL ........................................................................................ 6
1.2.1 Key-Value stores ................................................................................................................. 8
1.2.2 Document-Oriented stores .................................................................................................. 9
1.2.3 Graph stores ...................................................................................................................... 10
1.2.4 Column-oriented stores ..................................................................................................... 11
Capitolo 2: MongoDB ........................................................................................................................ 12
2.1 Caratteristiche e strumenti ....................................................................................................... 12
2.1.1 Interrogazione ................................................................................................................... 12
2.1.2 Persistenza e velocità ........................................................................................................ 13
2.2 La Shell di MongoDB .............................................................................................................. 13
2.2.1 Inserimento........................................................................................................................ 13
2.2.2 Lettura ............................................................................................................................... 14
2.2.3 Cancellazione .................................................................................................................... 14
2.3 Aggiornamento di un documento ............................................................................................. 14
Capitolo 3: CouchDB ......................................................................................................................... 16
3.1 Modello dei dati ....................................................................................................................... 17
3.1.1 JSON ................................................................................................................................. 17
3.1.2 Replicazione ...................................................................................................................... 17
3.2 Le API di CouchDB ................................................................................................................. 18
3.2.1 Server API ......................................................................................................................... 18
3.2.2 Database API..................................................................................................................... 18
3.2.3 Document API................................................................................................................... 19
3.2.4 Replication API ................................................................................................................. 19
3.3 Confronto con MongoDB ........................................................................................................ 20
Capitolo 4: Neo4j ............................................................................................................................... 21
4.1 Caratteristiche e strumenti ....................................................................................................... 21
4.1.1 Proprietà ............................................................................................................................ 22
4.2 Creazione di un grafo Neo4j .................................................................................................... 22
4.3 Query in Neo4j ......................................................................................................................... 23
4.3.1 Traversal............................................................................................................................ 24
Conclusioni ........................................................................................................................................ 26
Bibliografia ........................................................................................................................................ 27
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
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
• 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
• 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
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.
1.2.1 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
• 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.
1.2.2 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
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.
1.2.3 Graph stores
Questa tipologia di Base di Dati
utilizza nodi e archi per rappresentare
e
archiviare
risultando
più
le
informazioni,
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
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.
1.2.4 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
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.
2.1.1 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
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.
2.1.2 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.
2.2.1 Inserimento
Il metodo insert permette di inserire un documento in una collezione. Un esempio di linea
di comando è il seguente:
13
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.
2.2.2 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:
2.2.3 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
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 email del documento specificato.
Questo secondo approccio consente migliori prestazioni, in quanto elimina il tempo di
andata e ritorno del documento dal server.
15
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
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.
3.1.1 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
3.1.2 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
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.
3.2.1 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:
3.2.2 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
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:
3.2.3 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.
3.2.4 Replication API
Per replicare un DB in locale, ad esempio per funzioni di backup, si deve innanzitutto
19
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
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
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
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
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.
4.3.1 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. 4.2
24
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
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
Bibliografia
[1]
Jonas Partner, Aleksa Vukotic, Nicki Watt, 2013, “Neo4j in Action”
[2]
http://www.nosql-database.org/
[3]
http://www.neo4j.org/
[4]
http://docs.neo4j.org/chunked/milestone/
[5]
http://www.wikipedia.org
[6]
http://www.Mongodb.org
[7]
http://www.couchdb.apasche.org
[9]
Alessandro Rezzani, “Big Data: Architettura, tecnologie e metodi per l’utilizzo di
grandi basi di dati”, Maggioli Editore, 2013
[10] http://www.html.it/articoli
27