MongoDB
0 likes35 views
Il documento illustra le differenze tra database relazionali e NoSQL, con focus su MongoDB, un database NoSQL che utilizza un formato simile a JSON per la memorizzazione dei dati. Viene evidenziato come MongoDB offra maggiore flessibilità e semplicità per la scalabilità, sacrificando alcune proprietà ACID. Inoltre, si discute di pratiche come lo sharding, la replica e le limitazioni di MongoDB rispetto ai database relazionali.
![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.](https://image.slidesharecdn.com/mongodbboffa-190210163011/85/MongoDB-21-320.jpg)
![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!](https://image.slidesharecdn.com/mongodbboffa-190210163011/85/MongoDB-22-320.jpg)
![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:](https://image.slidesharecdn.com/mongodbboffa-190210163011/85/MongoDB-25-320.jpg)
![Esempio: Destroy
Sintassi: db.[collection].remove([query]);
Vengono eliminati tutti i documenti identificati
dalla query.
Per svuotare una collection, basta non passare
alcun parametro.](https://image.slidesharecdn.com/mongodbboffa-190210163011/85/MongoDB-26-320.jpg)
MongoDB
- 1. Un database NoSQL Open-Source MongoDB
- 2. Database Relazionali I dati sono divisi in tabelle. Ogni tabella è composta da diverse colonne fisse. Le tabelle possono avere riferimenti tra loro.
- 3. A.C.I.D. I database relazionali devono garantire quattro proprietà fondamentali:
- 4. 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.
- 5. CAP Theorem Ex-congettura, dimostrata nel 2002 e divenuta teorema ”è impossibile per un sistema informatico distribuito fornire simultaneamente tutte e tre le seguenti garanzie:”
- 6. 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
- 7. 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)
- 8. Esempio Scrittura su due delle tre repliche
- 9. Esempio Scrittura avvenuta sulle due repliche
- 10. Esempio Sincronizzazione tra le repliche
- 12. Esempio Stale read: lettura prima della sincronizzazione
- 13. 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 .
- 14. 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.
- 15. 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!
- 16. Formato di memorizzazione JavaScript Object Notation (JSON):
- 17. 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.
- 18. 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.
- 19. 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.
- 20. 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.
- 21. 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.
- 22. 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!
- 23. 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.
- 24. 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':
- 25. 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:
- 26. Esempio: Destroy Sintassi: db.[collection].remove([query]); Vengono eliminati tutti i documenti identificati dalla query. Per svuotare una collection, basta non passare alcun parametro.
- 27. 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.
- 28. 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à!
- 29. 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.
- 30. 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)
- 31. Altri database NoSQL Cassandra Riak Redis (made in Italy) CouchDB HBase HyperTable Neo4j Scalaris
- 32. 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