MongoDB è un database NoSQL orientato ai documenti, che nasce nel 2007 in California come servizio da utilizzare nell'ambito di un progetto più ampio, ma che presto è diventato un prodotto indipendente ed open-source. Esso memorizza i documenti in JSON, formato basato su JavaScript e più semplice di XML, ma comunque dotato di una buona espressività.
In questa guida analizzeremo le principali caratteristiche di MongoDB, partendo dalle basi e passando poi alla sintassi ed alle sue caratteristiche fondamentali. Prima però, è bene capire cosa significa avere a che fare con un database NoSQL, e qual è la differenza tra questa categoria di basi di dati, ed i più tradizionali database SQL.
SQL vs NoSQL
SQL è l'acronimo di Structured Query Language, il linguaggio di programmazione usato per l'interrogazione e la gestione dei database relazionali (RDBMS), quelli cioè che utilizzano il modello logico basato su tabelle e relazioni. Per questo motivo, spesso i due termini database relazionali e database SQL, vengono usati come sinonimi.
I database relazionali si contraddistinguono quindi per:
- l'uso di tabelle e campi
- le tabelle hanno uno schema fisso
- tra due o più campi di tabelle (chiavi esterne) può esserci una relazione vincoli di integrità referenziale
- l'accesso ai dati (transazione) viene garantito con le proprietà ACID
- ogni transazione non può essere eseguita parzialmente, ma o solo totalmente con successo (commit rollback
- alla fine della transazione il database si trova in uno stato consistente, ossia tutti i vincoli dello schema del database sono rispettati, altrimenti la transazione avrebbe fallito. Se interrogo il database dopo la transazione vedo che le modifiche sono entrate e sono consistenti.
- se eseguo due transazioni in contemporanea, l'effetto finale è lo stesso che avrei avuto se avessi eseguito le transazioni una di seguito all'altra, ossia l'effetto temporaneo di una transazione non ancora completata non è visibile alle altre transazioni.
- una volta che una transazione è terminata con successo, le modifiche sono diventate persistenti anche in caso di crash del sistema subito dopo la transazione.
NoSQL
Questo significa che i database NoSQL possono avere le caratteristiche più disparate: alcuni non utilizzano il modello relazionale, altri usano tabelle e campi ma senza schemi fissi, alcuni non permettono vincoli di integrità referenziale, e altri ancora non garantiscono transazioni ACID. E naturalmente ci possono essere varianti che combinano le precedenti.
Vediamo quali sono i più importanti modelli logici alternativi al modello relazionale:
- i database orientati ai documenti
- i database a grafo Neo4j
- i database chiave-valore utilizzano il modello dell'array associativo Memcached
- altri modelli più complessi come HBase Cassandra
Per quanto riguarda le proprietà ACID, alcuni database NoSQL ne garantiscono solo alcune. Per esempio non sempre è garantita la consistenza (si parla in questo caso di eventual consistency), ossia ci può essere una certa latenza prima che una modifica al database sia visibile. Altri non garantiscono la durabilità: ad esempio, in alcuni database distribuiti il malfunzionamento di un nodo dopo una transazione potrebbe impedire la corretta sincronizzazione di tutta la rete. Queste proprietà vengono rilassate allo scopo di fornire performance migliori e alta disponibilità.
Vantaggi e svantaggi
Non è facile valutare vantaggi e svantaggi dei database NoSQL rispetto ai RDBMS, appunto perché ogni database NoSQL merita un discorso a parte. Tuttavia si possono individuare alcune caratteristiche comuni.
In primis, poiché il database NoSQL viene scelto in base al contesto dell'applicazione che implementiamo, generalmente esso è più vicino al modello dei dati dell'applicazione. Ad esempio, se implementiamo un'applicazione che gestirà molte relazioni tra oggetti di vario tipo, un modello logico di dati come quello a grafi può rendere l'applicazione molto più semplice da sviluppare.
Un noto problema di quando si sviluppa con linguaggi orientati ad oggetti è, infatti, il cosiddetto O/R impedance mismatch, ossia il fatto che i due modelli, relazionale e ad oggetti, sono molto diversi tra loro. Ciò può dar luogo a problematiche che vanno dalla gestione del polimorfismo alla conversione dei tipi di dati, che generalmente vengono lasciate in carico ad un ORM.
Tra gli svantaggi più significativi dei database NoSQL possiamo riportare la carenza di tool: per una tecnologia consolidata da molto tempo come SQL, esistono tantissimi strumenti di gestione e sviluppo, a differenza di quanto accade per la maggior parte dei database NoSQL.
MongoDB: caratteristiche di base
Come già detto, MongoDB è un database orientato ai documenti, ognuno dei quali è memorizzato nel formato JSON. Il documento è fondamentalmente un albero che può contenere molti dati, anche annidati. Un primo esempio è il seguente:
{
nome: "Dante", cognome: "Alighieri",
nato: 1265, morto: 1321,
lingue: ["italiano", "latino" ],
opere: [
{ titolo: "Divina Commedia",
iniziata: 1300,
lingua: "italiano",
tipo: "poesia",
versi: "endecasillabi",
libri: ["Inferno", "Purgatorio", "Paradiso"] }
]
}I documenti sono raggruppati in collezioni che possono essere anche eterogenee. Ciò significa che non c'è uno schema fisso per i documenti. Tra le collezioni non ci sono relazioni o legami garantiti da MongoDB: in altre parole, non esiste un concetto analogo al vincolo di integrità referenziale.
Modello logico a parte, le caratteristiche chiave di MongoDB sono:
- consente servizi di alta disponibilità Replica Set
- garantisce la scalabilità automatica Sharding
MongoDB si adatta a molti contesti, in generale quando si manipolano grandi quantità di dati eterogenei e senza uno schema. Non è invece opportuno quando si devono gestire molte relazioni tra oggetti, e si vuole garantire l'integrità referenziale tra essi (ad esempio in un ERP).