bozza tesi - Ingegneria Informatica

Scuola Politecnica e delle Scienze di Base
Corso di Laurea in Ingegneria Informatica
Elaborato finale in Basi di Dati
Tecnologie NoSQL: SESAME
Anno Accademico 2014/2015
Candidato:
Antonio Giordano
matr. N46000441
Alla mia famiglia
ai miei amici
a me
Indice
Indice .................................................................................................................................................. III
Introduzione ......................................................................................................................................... 4
Capitolo 1: Sistemi NoSQL ................................................................................................................. 6
1.1 Il Teorema CAP..........................................................................................................................9
1.2 Parametri di qualità .................................................................................................................. 10
1.3 Vantaggi ................................................................................................................................... 12
1.4 Svantaggi .................................................................................................................................. 12
Capitolo 2: RDF Store........................................................................................................................ 13
2.1 Implementazione ...................................................................................................................... 14
2.2 Inferenza................................................................................................................................... 15
2.3 Triplestore vs NoSQL Graph Database ................................................................................... 17
Capitolo 3: SESAME ......................................................................................................................... 18
3.1 Database manager .................................................................................................................... 19
3.2 Portabilità ................................................................................................................................. 20
3.3 Specifiche tecniche .................................................................................................................. 21
3.3.1 Applicazioni integrate ....................................................................................................... 21
3.3.2 Pannello sempre disponibile……............…………………...………...…………………21
3.3.3 Anteprima del lavoro di progettazione..............................................................................21
3.3.4 Potenti funzionalità di ricerca............................................................................................22
3.3.5 Importazione ed esportazione ...........................................................................................22
3.3.6 Report................................................................................................................................22
Conclusioni ........................................................................................................................................ 23
Bibliografia ........................................................................................................................................ 24
Introduzione
La rivoluzione introdotta da internet nell'era del web 2.0 ha completamente stravolto
l'approccio ingegneristico alla gestione, memorizzazione e trasmissione dell'informazione.
Le esigenze degli utenti si sono modificate facendo quindi in modo che l'attenzione si
focalizzasse su cosa fosse veramente importante per un servizio online: la disponibilità
delle informazioni, la consistenza dei dati, i tempi di risposta.
Per comprendere facilmente quanto descritto sopra basti pensare alla classifica dei film più
venduti del 2015, aggiornata fino al momento in cui l'utente decide di visualizzarla: dal
punto di vista dell'utente è molto meglio accedere istantaneamente alla pagina della
classifica (anche se non aggiornata perfettamente) piuttosto che aspettare un tempo
indefinito ed ottenere un informazione consistente o aggiornata al secondo.
In casi come questi le caratteristiche rigide dei sistemi relazionali possono diventare un
vero e proprio collo di bottiglia per sistemi che potrebbero svincolarsi, seppur
marginalmente, dall'affidabilità delle informazioni.
In aggiunta l’arrivo di internet negli anni 90 ha indotto una vera e propria crescita
esponenziale dei servizi online; il caso più esemplare che possiamo citare è Amazon, nata
solo nel 1994 ma con un fatturato accertato di 61 miliardi di dollari nel 2012.
4
Sono aumentate inoltre le aziende che operano esclusivamente online (Facebook, Twitter e
FourSquare ad esempio) fornendo contenuti sempre più numerosi e articolati; la
disponibilità e l'affidabilità dei servizi unita alla necessità di coordinare una grande
quantità di contenuti molto correlati tra loro è diventato un requisito quasi obbligatorio.
Dunque la direzione intrapresa è stata quella di assicurare più il servizio o il contenuto a
danno della correttezza delle informazioni o alla consistenza dei dati, fatto salvo dei casi di
servizi sotto protocollo sicuro: ad esempio il settore bancario o alcune fasi di sicurezza dei
dati nel commercio elettronico.
I fautori di questo nuovo approccio sono stati Google e Amazon con i loro sistemi
proprietari (rispettivamente BigTable e Dynamo) ma da subito si sono sviluppati sistemi di
gestione equiparabili e diversi dai DBMS Relazionali (RDBMS).
A questi nuovi sistemi è stato dato il nome di DBMS NoSql proprio per specificare il suo
carattere determinante, sia come garanzia che come inflessibilità: la mancanza delle
relazioni.
Analizzeremo quindi la struttura principale e le caratteristiche di alcuni sistemi NoSql,
fino ad arrivare al Sesame, un DBMS NoSQL nativo che si propone di rivoluzionare il
tradizionale schema relazionale dei database in uso, per potenziarne le prestazioni, i tempi
di risposta e l'adattabilità alle sempre crescenti esigenze di sicurezza e consistenza dei dati.
5
Capitolo 1: Sistemi NoSQL
In passato i database relazionali venivano usati veramente ovunque, poichè ricchi di
specifiche e funzionalità uniche che sembravano adattarsi perfettamente a qualsiasi
compito che si potesse ragionevolmente affidare ad una banca dati.
Tuttavia i loro punti di forza si sono rivelati nel tempo essere anche i loro più grandi
difetti, in quanto la progettazione e la realizzazione di un database relazionale distribuito
spesso risulta notevolmente complessa.
In particolar modo è complicato, ed anche molto poco efficiente, effettuare transazioni ed
operazioni di unione (join) nei sistemi distribuiti odierni, molto utilizzati nelle piattaforme
social come Facebook, Twitter e altri colossi di servizi online come Google e Amazon.
Ecco perché la limitatezza delle caratteristiche intrinseche di tali database tradizionali ha
indotto dapprima all'ideazione e poi alla progettazione di nuove tecnologie di
archiviazione dati, maggiormente appropriate per un utilizzo in ambienti distribuiti.
Tali banche dati sono oggi chiamate database NoSQL.
6
In prima battuta il nome suggerisce un completo allontanamento, come sarebbe lecito
aspettarsi, dalla logica relazionale e dal sistema di interrogazione dei database SQL. Ma
ciò è vero solo in parte. Infatti l’acronimo esatto è “Not Only SQL”, una filosofia
certamente innovativa, ma non completamente contraria alla logica relazionale.
Il concetto è dunque chiaro: una singola tecnologia non basta.
La maggior parte dei database NoSQL sono stati sviluppati per funzionare su cluster di
computer, per interagire tra loro in maniera distribuita e orizzontale ed essere tolleranti
agli eventuali fallimenti che potrebbero subire. Per raggiungere tali obbiettivi è necessario
effettuare una rivalutazione delle classiche proprietà ACID del modello relazionale
(Atomicità, Consistenza, Isolamento e Durabilità) in quanto non tutte possono essere
rispettate contemporaneamente. Solitamente i database NoSQL sono progettati
direttamente in funzione dei requisiti della maggior parte dei servizi web, e la maggior
parte di essi sono liberi da schemi predefiniti (schemaless) e liberi di introdurre, o
mantenere, un proprio linguaggio di interrogazione.
7
Le principali esigenze comuni a tutti i più recenti fruitori di database NoSQL sono :
• Inarrestabile crescita del volume dei dati da gestire.
• Bisogno improrogabile di elaborare grandi quantità di dati in poco tempo.
Per comprendere questo concetto è opportuno riportare qualche numero :
3 miliardi della popolazione mondiale è costantemente online.
35 miliardi di ore vengono trascorse online ogni mese, l’equivalente di 4000 anni.
1,75 miliardi di utenti usano uno smartphone, ed il numero è in costante crescita.
Tali dati, uniti alla continua espansione dell’OpenID e allo sviluppo tecnologico dei
fornitori di servizi, hanno generato delle nuove necessità che subito hanno trovato il modo
di essere soddisfatte.
8
1.1 Il Teorema CAP
Nell’oramai già lontano 2000, Eric Brewer alla conferenza "Principle of Distribuited
Computing" illustrò per la prima volta il Teorema del CAP, che rispondeva alle predette
esigenze. Ogni lettera del teorema rappresenta una caratteristica ben precisa:
9
•
Consistency (Coerenza): ogni utente vede in ogni istante la stessa versione del dato.
•
Availability (Disponibilità): tutti gli utenti possono sempre leggere e scrivere nel
database.
•
Partition tolerance (Tolleranza al partizionamento): il sistema lavora bene
nonostante sia fisicamente ripartito nella rete.
Secondo il Teorema del CAP occorre scegliere solo due delle tre caratteristiche in ogni
istante di tempo, poichè è impossibile farle coesistere in un sistema distribuito
contemporaneamente.
Per fare un esempio chiaro, Amazon ha scelto scientemente le ultime due, volendo
privilegiare l'esperienza utente rispetto alla certezza di avere un sistema sempre
consistente.
1.2 Parametri di qualità
E' possibile mettere a confronto diversi tipi di database NoSQL tenendo conto di alcuni
parametri di qualità:
• Scalabilità: capacità del database di incrementare le proprie prestazioni in funzione
delle risorse fornite.
• Prestazione: capacità che verifica i vantaggi rispetto a determinati tipi di attività
svolte con il database.
• Consistenza: capacità del sistema di migrare sempre da uno stato consistente ad un
altro.
10
Dunque in aggiunta alla configurazione CAP, in base ai parametri sopra riferiti
distinguiamo i seguenti modelli di database NoSQL:
• Relational: sistemi in cui ogni dato è rappresentato da una relazione ed è gestito da
operazioni relazionali (join).
• Key-Value: sistemi dove il dato è univocamente definito da una coppia "chiavevalore" e che supporta le operazioni basilari di get(), put(), e delete().
• Column-oriented: sistemi che non supportano l'operazione di join dove il dato è
memorizzato in colonna e non in riga.
• Document-oriented: sistemi dove il dato è strutturato come un documento (ad
esempio JSON o XML) e le operazioni di join non sono previste.
11
1.3 Vantaggi
L'operazione di JOIN, fondamentale nei database relazionali classici, è evitabile grazie al
fatto che l'intera informazione è contenuta in ogni singolo elemento, in ogni singola tripla.
I DBMS non relazionali (NRDBMS) sono molto più semplici da realizzare: l'inserimento
o la cancellazione di un nodo nel sistema è impercettibile dall'utente finale e molto più
veloce.
Infine la progettazione di tali database viene mappata direttamente sul software applicativo
dell'azienda committente, e dunque sulle classi oggetto del proprietario del database (ad
esempio negozi virtuali come Amazon, o archivi di grosse quantità di dati come Google) e
questo aspetto riduce di molto i tempi di sviluppo.
1.4 Svantaggi
La semplicità con cui è stato presentata la "filosofia" NoSQL nasconde ovviamente dei lati
negativi. Il principale è che tutto il controllo sull'integrità dei dati viene affidato al
software applicativo che gestisce il database, che dunque deve essere testato
accuratamente prima di essere messo in funzione. Giusto per porre un esempio, nel caso di
un database relativo ad un negozio online (ad esempio Ebay), nel momento in cui un tente
decide di cancellarsi dal sistema, il vecchio DBMS relazionale avrebbe provveduto a
cancellare anche i relativi ordini di quel cliente e tutta la sua cronologia acquisti, attributi,
feedback etc.. mentre nel database non relazionale deve essere il software di Ebay a
provvedere all'integrità della banca dati.
Infine la mancanza di uno standard universale è un’altra delle pecche di questi database
non relazionali, ogni database ha infatti le proprie API e il suo metodo di memorizzazione
e di accesso ai dati.
12
Capitolo 2: RDF Store
Un RDF Store (o Triplestore) è un gestore di database costruito espressamente per
l'archiviazione e il recupero di triple tramite query semantiche. Una tripla è un'entità di
dati composta da soggetto-predicato-oggetto, come "Antonio ha 24 anni" o "Antonio
desidera la laurea".
Con il termine "web semantico", coniato dal suo ideatore, Tim Berners-Lee, si intende il
progetto (ancora in itinere) che prevede la trasformazione del World Wide Web in un
ambiente dove i documenti pubblicati (pagine, file, immagini, video) sono aggregati ad
informazioni e dati (metadati) che ne determinano il contesto semantico in un formato
idoneo all'interrogazione e l'interpretazione (facilitandone la ricerca) e, più in generale,
all'elaborazione automatizzata.
Con l'interpretazione del contenuto dei documenti che il Web semantico prevede, saranno
possibili ricerche molto più evolute delle attuali, e altre azioni significative come la
costruzione di reti di relazioni tra documenti che seguono logiche più elaborate del
genuino - ma oramai superato - collegamento ipertestuale.
A differenza di un database relazionale, un Triplestore è ottimizzato per la
memorizzazione e il recupero di triple che possono essere importate ed esportate
utilizzando il Resource Description Framework (RDF) e altri formati.
I Triplestore sono Database Management Systems (DBMS) che gestiscono dati modellati
con RDF. Il Resource Description Framework (RDF) è infatti lo strumento base proposto
13
da W3C per la codifica, lo scambio e il riutilizzo di metadati strutturati e consente
l'interoperabilità tra applicazioni che condividono le informazioni sul Web.
A differenza dei database relazionali che memorizzano i dati nelle relazioni (o tabelle) e
vengono interrogati utilizzando SQL, i Triplestore utilizzano triple e vengono interrogati
utilizzando un linguaggio di interrogazione chiamato SPARQL.
Una caratteristica fondamentale di molti Triplestore è la capacità di fare inferenza. È
importante notare che un DBMS tipicamente offre la capacità di gestire concorrenza, la
sicurezza, la registrazione, il recupero e aggiornamenti, oltre al caricamento e
memorizzazione dei dati. Non tutti Triplestore offrono tutte queste funzionalità (o almeno
non ancora).
2.1 Implementazione
Triplestores possono essere classificati in tre tipi di categorie:
• I Triplestore nativi sono quelli che sono stati creati da zero per sfruttare appieno il
modello dei dati RDF e memorizzare in modo efficiente. Questi includono: 4Store,
AllegroGraph, BigData, Jena TDB, Sesame, Stardog, OWLIM and uRiKa.
• I Triplestore RDBMS-backed sono costruiti con l'aggiunta di uno strato specifico
RDF ad un RDBMS già esistente. Questi includono: Jena SDB , IBM DB2 e
Virtuoso .
• I NoSQL Triplestore sono state recentemente oggetto di studio come possibili
gestori di archivi RDF.
Diversi studi comparativi sono stati fatti per valutare le prestazioni dei Triplestore, ad
esempio dei Benchmark popolari sono Lehigh University Benchmark (LUBM), Berlin
SPARQL Benchmark (BSBM) , SP2Bench e recentemente il Benchmark DBpedia.
14
Qual è il miglior Triplestore? Si dovrebbero controllare tutti i risultati in funzione di
ciascun criterio di riferimento. Non esiste una risposta giusta.
2.2 Inferenza
Una caratteristica fondamentale di un RDF Store è la capacità di fare inferenza per le
query. L'inferenza è il processo grazie al quale da una affermazione presa come vera si
passa a una seconda affermazione la cui verità deriva dal contenuto della prima.
Per comprendere tale concetto, procediamo con un esempio di facile intendimento.
Si consideri il seguente ontologia OWL:
ex1:FullProfessor rdf:subClassOf ex1:Professor.
ex1:AssistantProfessor rdf:subClassOf ex1:Professor.
ex1:Professor owl:equivalentClass ex2:Teacher
In cui si afferma che un professore ordinario e un assistente sono entrambi professori.
Abbiamo che l'insegnante semplice, appartiene ad una classe equivalente al professore.
Consideriamo in seconda battuta i seguenti dati:
ex1:Bob rdf:type ex1:FullProfessor
ex1:Alice rdf:type ex1:AssistantProfessor
ex2:Mary rdf:type ex2:Teacher
Viene dichiarato quindi che Bob è un professore ordinario, Alice è un Assistant Professor
e Maria è un insegnante semplice.
Analizziamo la risposta del NRDBMS alla seguente query SPARQL:
15
SELECT ?x
WHERE {
?x rdf:type ex1:Professor
}
Se la funzionalità di inferenza non è abilitata, la risposta alla domanda è vuota poichè i
dati non affermare in maniera esplicita che qualcuno è un professore. Tuttavia, è possibile
dedurre che sia Bob, sia Alice, sia Mary sono tutti professori perché sappiamo che
professori ordinari e professori associati sono entrambi professori, e gli insegnanti sono
anche professori.
Un altro predicato ampiamente usato per l'inferenza in OWL è il costrutto sameAs.
Consideriamo a tal proposito i seguenti dati:
ex1:Bob foaf:name "Bob Smith" .
ex1:Bob owl:sameAs ex2:Smith .
ex2:Smith foaf:phone "555-1234" .
Analizziamo la risposta del NRDBMS a questa nuova query SPARQL:
SELECT ?name ?phone
WHERE {
ex1:Bob foaf:name ?name .
ex1:Bob foaf:phone ?phone .
}
Senza inferenza, la risposta alla query sarebbe vuota poichè non c'è tripla che abbia come
soggetto "Bob" e predicato "telefono". Tuttavia, se l'inferenza è abilitata, si può dedurre
che Bob ha come numero di telefono "555-1234", proprio perché si tiene conto che "Bob"
è la stessa cosa (sameAs) di Smith, e che Smith ha numero di telefono "555-1234".
16
2.3 Triplestore vs NoSQL Graph Database
Database come Neo4j, HyperGraphDB e InfiniteGraph, archiviano e gestiscono dati
rappresentandoli come grafici. Dato che il modello di dati RDF può essere interpretato
come un grafico particolare, è giusto affermare che Triplestore è un tipo di database
grafico. Tuttavia è possibile evidenziare diverse sue peculiarità. I Triplestore sono stati
implementati per memorizzare RDF, che è assimilabile ad un particolare tipo di grafico:
un grafico direttamente etichettato. Un database NoSQL è in grado di memorizzare diversi
tipi di grafici: grafici senza etichetta, grafi non orientati, grafici pesati, ipergrafi, etc..
Un database grafico non supporta necessariamente il modello RDF, o il linguaggio
SPARQL, o comunque qualsiasi tipo di inferenza. Tuttavia esso potrebbe essere utilizzato
per memorizzare RDF ma potrebbe, al contempo, non fornire lo stesso set di funzionalità
che ci si aspetta da un RDF Store.
In definitiva possiamo dire che un RDF è un database grafico, ma non tutti i database
grafici sono degli RDF Store.
17
Capitolo 3: Sesame
Sesame è un ambiente di esecuzione open source Java per l'elaborazione di dati RDF.
Questo include analisi, conservazione, inferenza e interrogazione di su tali dati. Esso gode
chiaramente di tutte le caratteristiche finora incontrate nel trattamento dei sistemi NoSQL,
ed offre una API di facile impiego che può essere collegata a tutte le principali
applicazioni di archiviazione RDF. Esso permette di connettersi con gli endpoint SPARQL
e creare applicazioni che sfruttano il legame dei dati connessi grazie al Web Semantico.
Sesame offre due tipi di database RDF (quella interna ad esso e quella nativa), e in
aggiunta sono disponibili anche molte altre soluzioni di memorizzazione fornite da
aziende di terze parti. Tale ambiente offre una ampia scala di strumenti messi a
disposizione degli sviluppatori per sfruttare la potenza di RDF e i relativi standard.
Sesame supporta pienamente il linguaggio di interrogazione e aggiornamento SPARQL
che consente l'esecuzione di query espressive ed offre inoltre l'accesso trasparente al
repository remoto RDF utilizzando esattamente la stessa API utilizzata per l'accesso
locale. Infine, Sesame supporta tutti i formati di file, tra cui il tradizionale RDF, RDF /
XML, Turtle, N-triple, N-Quads, JSON-LD, trig e TriX.
18
3.1 Database manager
Sesame è un potente gestore di database, flessibile e progettato per soddisfare le esigenze
di una vasta gamma di usi e utenti. Che sia una piccola impresa, un amministratore
aziendale, uno sviluppatore di applicazioni professionali, o la persona il cui compito è
quello di tenere traccia di qualcosa, Sesame ha tutto il necessario per creare rapidamente
applicazioni di database, organizzare e presentare le informazioni contenute in essi.
L'intuitività e la semplicità sono le sue caratteristiche centrali. Esso presenta infatti
un'interfaccia basata su form coerente e query intiuitive (se si digita Giordano nel campo
Cognome e si preme F10 si ottiene il record Giordano), ed è inoltre portatile in HTML
(web-ready) consentendo di creare applicazioni funzionanti in breve tempo.
Sesame offre inoltre strumenti più avanzati per migliorare ulteriormente le applicazioni già
operanti.
19
3.2 Portabilità
Se si passa a Sesame da un altro DBMS, Sesame dispone di una varietà di servizi integrati
in grado di aiutare l'utente a semplificare questa transizione. Se si sta attualmente
utilizzando un altro software è infatti possibile usufruire di servizi di importazione dati
attraverso un apposito strumento, in grado di effettuare anche importazioni gerarchiche
durante la migrazione da un database relazionale.
Sesame fornisce funzionalità client-server come se fossero diverse "personalità" dello
stesso programma. Ciò significa che una copia di Sesame può funzionare in modalità
standalone su un singolo computer o servire gli altri utenti connettendosi a un server
Sesame.
Sesame è infine un software multipiattaforma, attualmente disponibile sia per Microsoft
Windows ™ sia per Linux, e il futuro della gestione dei dati personali e del business non
potrà prescindere da questa sua semplice ma rivoluzionaria proprietà.
20
3.3 Specifiche tecniche
3.3.1 Applicazioni integrate
Sesame ha gli strumenti che consentono di creare applicazioni aziendali complesse come
immissione di ordini fatturazione, gestione dei contatti e sistemi di pianificazione. In
un'applicazione che gestisce gli inserimenti degli ordini di acquisto di un azienda, per
esempio, è possibile collegare i clienti, i prodotti e la fattura e aggiungere la
personalizzazione in modo che gli ordini possano essere completati semplicemente
puntando e cliccando su liste di selezione pop-up, ed ottenere la fattura stampata con un
semplice clic.
3.3.2 Pannello sempre disponibile
Sesame offre due modi per ottenere una visione chiara della struttura del database da
gestire. Strutture, funzioni e comandi di navigazione possono essere visualizzati con un
menu ad albero o tasti ad eventi. La maggior parte delle funzioni sono accessibili con la
tastiera o il mouse. L'innovazione principale consiste nel fatto che non è più necessaria la
noiosa caccia attraverso una confusa matrice di tasti a discesa per trovare l'attività che si
desidera eseguire, infatti il menu del pannello può essere opzionalmente nascosto tramite il
menu Visualizza/Nascondi.
3.3.3 Anteprima del lavoro di progettazione
La modalità di anteprima consente di visualizzare in anteprima e testare la struttura delle
applicazioni prima della loro integrazione nell'applicazione da implementare. Questo
approccio è rivoluzionario per la gestione di un database, in quanto vuol dire che si può
lavorare, modificare e migliorare le proprie applicazioni parallelamente al suo utilizzo, e
quindi valutandone in tempo reale le prestazioni.
21
3.3.4 Potenti funzionalità di ricerca
La possibilità di cercare i record che soddisfino i criteri delle query è una funzione
fondamentale in qualsiasi gestore di database. Sesame offre una serie completa di
strumenti per descrivere ed adattare i record recuperati fino a restituire esattamente i
record richiesti nella query. Questi includono le ricerche normali, le ricerche additive,
sottrattive, le ricerche drill-down, le ricerche invertite e universali.
3.3.5 Importazione ed esportazione di record
Sesame può importare ed esportare intere gerarchie di record. Un import gerarchico crea
automaticamente sia il record padre sia il sotto-record. Questo è un grande strumento sia
per esportare i dati in un altro programma (come Microsoft Word) o per importare dati da
un altro RDBMS. Sesame importa i file ASCII in stile CSV ed esporta file di testo ASCII
con una vasta scelta di opzioni di esportazione per personalizzare il modo in cui il file
esportato verrà formattato.
3.3.6 Report
I report, basati su HTML, combinati con un veloce ed intuitivo Report Designer crea
possono immediatamente essere inviati via email, caricati su un sito web, stampati o
visualizzati in un qualsiasi browser. Poiché i report di Sesame sono HTML, possono
essere facilmente importati in molti altri programmi di videoscrittura, fogli elettronici e
database framework.
Sesame supporta sia il formato in colonna sia le relazioni in formato libero, o ancora, una
combinazione di entrambi gli stili.
22
Conclusioni
In definitiva, il NoSQL è un concetto articolato e multiforme, che va analizzato sotto
diversi punti di vista e sfaccettature per capirne la reale portata ed i benefici che esso può
portare alla comunità.
Sicuramente la capacità di gestire Big Data fa parte oramai di un qualsiasi strumento di
analisi evoluto e proiettato al futuro, e questo aspetto porterà le tecnologie NoSQL ad
essere protagoniste e pioniere del mondo virtuale del futuro, il Web Semantico.
23
Bibliografia
[1] http://www.nosql-database.org/
[2] http://www.wikipedia.org
[3] “Big Data: Architettura, tecnologie e metodi per l’utilizzo di
grandi basi di dati”, Maggioli Editore, 2013
[4] http://www.html.it/articoli
[5] http://blog.nahurst.com/visual-guide-to-nosql-systems
[6] http://www.internetpost.it/i-database-non-relazionali-cosa-significa-nosql/
[7] http://arxiv.org/ftp/arxiv/papers/1401/1401.2101.pdf
[8] http://www.sesamedatabase.com/features_detail.html
24