Introduzione

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 per memorizzare i dati;
• le tabelle hanno uno schema fisso: un nome, un elenco di campi, ognuno con i rispettivi tipi (stringhe di caratteri, numeri, date e dati binari). Le tabelle possono avere una chiave primaria, ossia un campo speciale che identifica univocamente, senza ambiguità, una riga della tabella (ad esempio il codice fiscale di una persona). le tabelle possono avere dei vincoli, ossia delle condizioni che devono soddisfare (ad esempio l'età di una persona non può essere minore di 0)
• tra due o più campi di tabelle (chiavi esterne) può esserci una relazione ossia una condizione che lega tra loro le rispettive righe a cui i campi appartengono (ad esempio tra il codice del comune di nascita di una persona e il codice del comune nella tabella dei comuni). La validità del legame è garantito dai vincoli di integrità referenziale.
• l'accesso ai dati (transazione) viene garantito con le proprietà ACID (Atomicità, Consistenza, Isolamento e Durabilità). Questo significa che:
  • ogni transazione non può essere eseguita parzialmente, ma o solo totalmente con successo (commit) o deve fallire totalmente senza modificare il database (rollback). Ad esempio se la mia transazione prevede l'inserimento di una riga con 7 campi nel database, alla fine o avrò tutti e 7 i campi inseriti nella riga o nessuna nuova riga.
  • 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 non è uno specifico linguaggio, ma è il termine universalmente accettato per raggruppare un insieme di tecnologie per la persistenza dei dati che funzionano in modo sostanzialmente diverso dai database relazionali, quindi che non rispettino una o alcune delle caratteristiche indicate sopra.

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 memorizzano i dati in documenti, ossia in oggetti complessi codificati in qualche modo e senza uno schema rigido. MongoDB è basato proprio su questo modello;
• i database a grafo usano strutture a grafo con relazioni libere (non prefissate come nel caso dei database relazioni) tra nodi del grafo. Un esempio che utilizza questo schema è Neo4j;
• i database chiave-valore utilizzano il modello dell'array associativo (Memcached è un esempio);
• altri modelli più complessi come HBase o Cassandra fanno corrispondere, alle chiavi, valori formati da famiglie di colonne anch'esse indicizzate.

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à, dal momento che la replicazione di un database (Replica Set) può avvenire in modo molto semplice;
• garantisce la scalabilità automatica, ossia la possibilità di distribuire (Sharding) le collezioni in cluster di nodi, in modo da supportare grandi quantità di dati senza influire pesantemente sulle performance.

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).