Introduzione a MongoDB

_Logo MongoDB è un database document oriented. Nelle prime posizioni per popolarità in compagnia di tanti database relazionali, offre i tipici vantaggi della famiglia noSQL. La sua alta flessibilità e robustezza ne fanno un ottimo candidato per molte tipologie di applicazioni, non solo nell’ambito dei grandi volumi tipici del cloud.

Possiamo sintetizzare MongoDB dicendo che permette la memorizzazione di documenti in insiemi (detti collection) in cui non è necessario mantenere lo stesso schema per ogni elemento. Ogni documento ha un proprio id univoco che ne permette il rapido recupero.

Per documento non si intende un file nel senso comune del termine, ma una struttura dati simile ad un dizionario in cui le coppie nome/valore, detti field, definiscono un’entità. Nella stessa collezione, come detto, ogni documento può avere il suo insieme di field e un field con un certo nome può essere, in documenti diversi, di tipo diverso. Molto importante è il fatto che ogni documento può contenere altri documenti e, oltre ai tipi di dati primitivi, è possibile definire un campo come array. Gli array possono contenere qualsiasi altro tipo, compresi altri array e documenti. Questo offre una struttura dati molto completa e flessibile che in parte compensa le funzionalità dei database tradizionali che Mongo non può offrire.

Come per gli altri database noSQL non esiste il concetto di relazione e di transazione tipica dei database tradizionali, perché non vi sono relazioni tra i documenti che normalmente porterebbero a creare lock di scrittura che si propagano su più tabelle e righe. In MongoDB l’atomicità delle scritture è solo sul documento in modifica. In particolare non vi è un lock tra collezioni diverse. Ad esempio, non è possibile forzare l’eliminazione di documenti presenti in una collezione alla cancellazione di documenti presenti in un altro insieme: sarà compito dell’applicazione garantire la consistenza dei dati.

Altra importante caratteristica riguarda il fatto che il modello di coerenza non è rigido. Come discusso nell’ambito del teorema CAP un database distribuito deve sacrificare la consistenza per offrire disponibilità o viceversa. Il team di MongoDB ha cercato di offrire un compromesso davvero interessante tra la possibilità di gestire enormi quantità di dati e la loro coerenza: per comprendere la complessità di tale architettura si pensi ad un database suddiviso in centinaia di server che concorrono contemporaneamente a rispondere il più velocemente possibile ad un’altrettanta enorme mole di richieste.

Come è possibile gestire questa mole di dati e richieste? Offrendo un’incredibile supporto alla scalabilità orizzontale e alla robustezza: sia duplicando i database tramite repliche sia suddividendo le collezioni in parti (dette sharding). Le repliche garantiscono la disponibilità dei dati anche in caso di crash di un server, mentre i sharding permettono l’esecuzione di query in parallelo anche su server diversi. Non c’è limite al numero di server utilizzabili.

In un sistema noSQL, nato soprattutto nell’ambito distribuito come il web/cloud, si sacrifica coerenza a favore della disponibilità. Quindi in generale un client può aggiornare i dati ma vi è un certo periodo in cui il dato non risulta sincronizzato su tutte le repliche. Le modifiche vengono infatti accettate solo dal database primario e poi propagate sui database replica. Durante questa diffusione i dati risultano non coerenti: un client che accede ad una replica potrebbe ottenere una copia non aggiornata del documento. Si parla di eventual consistence, quindi di coerenza non immediata.

In MongoDB questo processo è ampiamente configurabile specificando il livello di Write Concern. Se un client richiede la modifica di un documento, tale operazione verrà eseguita in modo atomico sul server. Ma il flusso di una richiesta di modifica comporta diversi passi e MongoDB può essere configurato per indicare in quale punto si ha il ritorno del risultato al client:

  • In modalità fire and forget, detta anche relax, il client invia la richiesta e il server la prende in carico liberando subito il chiamante. In questo caso la modifica si trova nella cache del server che viene poi elaborata periodicamente. Quindi, in caso di errore, il dato potrebbe non essere nemmeno stato salvato sul server primario.
  • In base alla configurazione il client potrebbe attendere almeno la conferma del salvataggio effettivo del dato nello storage fisico, ma verrebbe liberato dall’attesa della replicazione sui nodi secondari.
  • L’ultima possibilità è quella di attendere sia la ricezione della richiesta, sia la persistenza sia la replicazione. In questi casi è possibile indicare il livello di replicazione, ad esempio indicando di attendere l’aggiornamento della maggioranza dei nodi.

Si parla di consistency e durability: la prima riguarda la coerenza dei dati tra nodo primario e secondari ed è un coerenza non immediata (Eventual Consistency), la seconda riguarda l’effettiva persistenza dei dati su dischi del nodo primario. Infatti un particolare sistema di cache, necessario per garantire elevati prestazioni, razionalizza l’accesso al disco.

Questi sono solo alcuni appunti relativi a MongoDB e l’intenzione è quello di introdurre alcuni concetti base. I vantaggi di MongoDB riguardano:

  • La scalabilità, quindi la distribuzione dei carichi di lavoro su più server.
  • La velocità, in particolare là dove è possibile accedere tramite chiave primaria.
  • L’integrazione diretta con il proprio modello Object Oriented, quindi nessun impendance mismatch e una maggiore velocità di sviluppo.
  • La possibilità di configurare il livello di coerenza, sia a livello di database, sia di collezione e sia di singola operazione.
  • La semplificazione della migrazione dei dati in caso di aggiornamento del modello dati.
  • La semplificazione della collaborazione nel team: è più semplice "visualizzare" un database MongoDB che un classico database relazionale.
  • La possibilità di estendere il proprio modello in modo più semplice grazie al polimorfismo dei dati e alla mancanza di schemi (un partner potrebbe salvare dati aggiuntivi nei documenti senza dover metter mano al database).
  • Il supporto ai dati di grandi dimensioni (tramite GridFS).
  • E’ un progetto in continua evoluzione: con la versione 3.0 è stato introdotto un nuovo motore che permette prestazioni e compressione dati notevolmente superiori rispetto alla precedente versione.
  • Tale le risorse a disposizione tra libri, presentazioni, meetup, webinar… Fondamentali l’Univerità MongoDB e la documentazione ufficiale.

MongoDB è un progetto Open Source scritto in prevalenza in C++. E’ distribuito come release stabile oppure in versione beta con compilazioni notturne. E’ disponibile per Windows, Linux, Mac OS X e Solaris. Il sito ufficiale è MongoDB.org mentre esistono molti servizi business per il supporto o l’hosting, in particolare MongoLab e MMS.

Infine, è interessante notare come MongoDB sia il database noSQL più richiesto nelle offerte di lavoro ed è, attualmente, il quinto database più popolare nella classifica di db.engines.com.

Tag: MongoDB, noSQL