MongoDB

Un database NoSQL Open-Source
MongoDB

Database Relazionali
 I dati sono divisi in tabelle.
 Ogni tabella è composta da diverse colonne fisse.
 Le tabelle possono avere riferimenti tra loro.

A.C.I.D.
 I database relazionali devono garantire quattro
proprietà fondamentali:

Database NoSQL
 Movimento Not-Only SQL
 Database che rinunciano alle proprietà
A.C.I.D.e allo scopo di avere:
 Maggiore flessibilità nella strutturazione dei dati
 Più semplicità nelle operazioni di scalabilità
 Migliore Availability (disponibilità)
 Alcuni software non seguono solo ad alcune
delle proprietà A.C.I.D.e, altri le ignorano tutte.

CAP Theorem
 Ex-congettura, dimostrata nel 2002 e divenuta
teorema
 ”è impossibile per un sistema informatico distribuito fornire
simultaneamente tutte e tre le seguenti garanzie:”

Not Only SQL!
 Alcuni applicativi richiedono consistenza forte:
 Banche
 Sistemi di controllo di Aerei/Aeroporti
 Sistemi di controllo di catene di montaggio
 Gli stessi esponenti del Movimento NoSQL
suggeriscono di usare un database relazionale
dove opportuno
 Nella maggior parte dei casi, una consistenza
eventuale è accettabile, a favore di Availability
e Partitioning

Consistenza eventuale
 Le scritture avvengono su una parte delle
repliche responsabili di quel dato
 I nodi che ricevono la scrittura propagano
l'informazione alle altre repliche
 Le letture avvengono su una parte (spesso 1)
delle repliche
 Se una lettura avviene su un nodo non
sincronizzato con l'ultima scrittura, viene
restituito un dato precedente (stale data)

Esempio
Scrittura su due delle tre repliche

Esempio
Scrittura avvenuta sulle due repliche

Esempio
Sincronizzazione tra le repliche

Esempio
Stale read: lettura prima della sincronizzazione

 Il nome deriva da humongous
 E' l'unico DBMS NoSQL presente nella Top10
dei DBMS più usati, al 6° posto
 E' probabilmente il più simile ad un database
relazionale, da cui la sua diffusione
 Rispetto ad un database relazionale, le rinunce
maggiori sono: Transazioni, JOINs, Integrità
referenziale e Vincolare e la Consistenza
Forte .

Perché dovrei...?
 Si può fare a meno delle JOINs
denormalizzando i dati.
 I vincoli di integrità vincolare e referenziale
possono essere facilmente sostituiti con
controlli eseguiti dall'applicazione utente.
 La Consistenza Forte non è quasi mai un
requisito di massima priorità.
 Se l'applicazione ha forte bisogno di
Consistenza e/o Transazioni, allora un
database relazionale è sempre più adatto.

E i vantaggi?
 Le tabelle (collections) non hanno struttura
(schema) prestabilite.
 Addio alle ALTER TABLE ADD/DROP COLUMN
che possono bloccare il sistema per minuti o ore.
 Ogni elemento (document) in una collection ha le
sue proprie colonne, ed i valori possono
rappresentare qualsiasi cosa:
 Numeri, Stringhe, Dati binari
 Oggetti (embedded documents)
 Array di Oggetti o Numeri/Stringhe/Dati
 Protezione dagli attacchi di SQL Injection!

Formato di memorizzazione
 JavaScript Object Notation (JSON):

E la normalizzazione?
 Dividere i dati in più tabelle risulta comodo in
fase di progettazione. Tutto sembra più
ordinato.
 In realtà la normalizzazione dei dati rende
molto più complicato l'accesso alle
informazioni.
 Se poi i dati sono distribuiti su più nodi, una
JOIN potrebbe letteralmente paralizzare l'intero
Cluster.
 Dimenticate tutto quello che il professore di
Basi di Dati vi ha mai insegnato.

JSON
 Coppie di chiave e valore separate da due
punti.
 Ogni coppia è separata da virgola.
 Tutte le coppie in un oggetto sono racchiuse in
parentesi graffa.
 Un array di qualsiasi tipo è contenuto in
parentesi quadre.

BSON
 Il formato che MongoDB utilizza sul disco è una
versione alleggerita di JSON, detta Binary
JSON (BSON)
 Quando si utilizza MongoDB non si vedrà mai il
formato BSON, ma sempre il JSON
 Sostituisce due punti e parentesi con particolari
valori binari che servono ad identificare i vari
contenuti.

Querying MongoDB
 MongoDB come MySQL e altri DBMS fornisce
una shell per inserire query direttamente.
 La shell utilizza un motore JavaScript.
 Si possono usare variabili, istruzioni
condizionali e iterative.
 La shell può eseguire operazioni molto
complesse come Map/Reduce.
 Da qui si possono anche eseguire le operazioni
ordinarie di Create, Read, Update & Destroy.

Esempio: Create
 Comando: db.[collection].insert([JSON-object]);
 Se non è specificato un campo _id viene
generato da MongoDB.
 Se la collection non esiste, verrà creata.

Esempio: Read
 Sintassi: db.[collection].find([criteria], [proj]);
 Restituisce tutti i document che rispettano i dati
criteria.
 Il secondo parametro può specificare quali
campi mostrare o nascondere.


 Il campo _id è stato aggiunto da MongoDB
anche se non lo abbiamo specificato!

Esempio: Read 2
 La ricerca può avvenire anche usando i soliti
operatori di >, <, >=, <=, not, or, and e altri
ancora.
 La sintassi è molto diversa dal familiare SQL:


 Richiesti i documenti la cui age era maggiore di
18, vediamo entrambi i documenti inseriti.

Esempio: Read 3
 La ricerca può essere effettuata anche in Array
o embedded documents:


 Trova tutti i Post che hanno almeno un
commento il cui autore è 'Pluto':

Esempio: Update
 Sintassi: db.[collection].update([query], [upd]);
 Il primo parametro indica quali documenti
aggiornare.
 Il secondo, come devono essere aggiornati.

 La precedente query sostituisce l'intero
documento, la prossima solo i campi specificati:

Esempio: Destroy
 Sintassi: db.[collection].remove([query]);
 Vengono eliminati tutti i documenti identificati
dalla query.
 Per svuotare una collection, basta non passare
alcun parametro.

Sharding
 Meccanismo di partizionamento di MongoDB.
 Si sceglie una Shard Key, generalmente _id.
 I dati sono distribuiti automaticamente sul
cluster dividendo lo spazio della Shard Key in
parti uguali, definite chunks.
 Il numero delle chunks è definito
dall'amministratore.
 In un sistema con 32 chunks e 4 nodi, ogni
nodo sarà responsabile di 8 chunks di dati.

Aggiungere un nodo
 L'aggiunta di un nodo consiste in due semplici
passaggi:
 Installare MongoDB sul nuovo server.
 Eseguire un semplice comando su una qualsiasi
delle shell del cluster:
 db.runCommand({addShard: "10.12.1.25:123"})
 Il Cluster inizierà il Rebalancing, i chunks saranno
redistribuiti nel modo più equo possibile tra tutti i nodi.
 Il Cluster continuerà ad essere utilizzabile durante
tutta l'operazione. Alta Disponibilità!

Replication
 Master-Slave replication.
 Ogni Shard ha le sue repliche.
 I nodi Master ricevono tutte le scritture e le
inoltrano ai nodi Slave
 I nodi Slave sono in sola lettura.
 Se il nodo Master ha un problema (system
crash, network error, mongod server crash) i
nodi Slave tengono una elezione per scegliere
un nuovo Master.

Perché non usare MongoDB
 Se sono necessarie transazioni
 Le query di ricerca sono Case-Sensitive
 Quando un nodo Master cade, il processo di
elezione può durare fino a 60 secondi durante i
quali la Shard non può accettare Write!
 Per efficienza, la durabilità non è sempre
garantita (configurabile)

Altri database NoSQL
 Cassandra
 Riak
 Redis (made in Italy)
 CouchDB
 HBase
 HyperTable
 Neo4j
 Scalaris

Link & Resources
 http://en.wikipedia.org/wiki/MongoDB
 http://www.mongodb.org
 http://docs.mongodb.org/
 http://en.wikipedia.org/wiki/MapReduce
 http://en.wikipedia.org/wiki/NoSQL
 http://en.wikipedia.org/wiki/CAP_theorem

MongoDB

Related slideshows

More Related Content

MongoDB