Sarà  un Database relazionale lo strumento giusto
per gestire una così grande mole di dati?

 

Questa è stata la domanda che mi sono posto mentre svolgevo l'analisi preliminare sulla fattibilità del io ultimo progetto.
Sicuramente tutte le conoscenze universitarie e tutti gli anni passati lavorando su schemi E-R e database SQL forniscono una base estremamente versatile e consolidata da cui partire per lo sviluppo dell'applicazione ma, visto che prerogativa di un buon sviluppatore (secondo me) è usare lo strumento migliore e non sempre quello che si conosce meglio, ho orientato il mio sguardo verso i database document-oriented.
Fra tutte le possibilità che mi si sono presentate ho scelto MongoDB per vari motivi:

  1. la comunity di sviluppatori è in forte aumento; 
  2. la quantità di documentaione disponibile;
  3. l'ottima integrazione con il mio framework preferito, CAKEPHP

Dopo un paio di  settimane di studio, di prove, di installazioni fallite e riuscite, di query astruse via via ottimizzate, di normalizzazione e denormalizzazione sono riuscito a padroneggiare con discreta maestria (almeno spero!!!) questo fantastico database.

MongoDB, infatti, mi è sembrato subito un strumento molto potente, flessibile, scalabile ed utilizabile in numerosi scenari. Combina la capacità di essere estremamente scalabile con alcune caratteristiche come gli indici secondari, l'ordinamento, l'aggregazione e gli indici geospaziali davvero molto interessanti.

Facilità d'uso

MongoDB è un database orientato al documento, non un DB relaionale e questo consente una facilità nella scalabilità orizzontale che il modello relazionale non possiede oltre ad altri numerosi benefici. 
Il concetto di righa è rimpiazzato da quello di documento, un modello più flessibile che permette di incorporare altri documenti ed array. Infatti con questo approccio document-oriented è possibile rappresentare delle relazioni gerarchiche anche molto complesse in un singolo record, comportandosi concettualmente in maniera molto simile ad un linguaggio di programmazione Object-Oriented.

Non ci sono schemi predefiniti : infatti chaivi e valori di un documento non sono di tipo e dimensione fissa e questo permre di aggiungere e rimuove i campi molto più facillmente. Lo sviluppo mi è sembrato molto più rapido e anche l'approccio mi è sembrato molto più facile.

Scalabilità

Grazie all'aumento della disponibilità della banda e alla diminuzione dei prezzi dello storage oggi anche una piccola applicazione ha la necessità di stoccare più data di quanto molto database avrebbero fatto solo qualche anno fa. Questa necessità mi ha spinto verso la ricerca di uno strumneto che potesse essere il più scalabile possibile; ma che tipo di scalabiltà?
Parlando di databse ci sono due tipi di scalabilità fra cui scegleire:

  1. Scalabilità verticale;
  2. Scalabilità orizzontale;

La scalabilità verticale si verifica quando, avendo bisogno di aumentare le performance del no DB decidiamo di aumentare le risorse delle macchina che ospita il nostro database. Questa scelta di solito è la più immeddiata e la più facilmente perseguibile ma ha comunque un limite fisico: cosa succede quando non possiamo comprare una macchina più potente di quella attuale (per non parlare dei costi).

La scalabilità orizzontale consiste nell'aggiungere spazio o risorse comprando un secondo server o aggiungendone uno al nostro cluster. Questo è ovviamente più scalabile e meno costoso; unico inconveniente: è molto più difficile amministrare e ottimizzare un cluster di macchine piuttosto che un singolo server.

MongoDB è nato per sfruttare la scalabilità orizzontale: il modello document-oriented permette naturalmente il frazionamento del database su diverse macchine e questo DB fornisce di default alcun strumenti che ci permettono di gestire facilmente questo aspetto ed accuparci principalmente della programmazione.

Altre caratteristiche...

MongoDB ha molte altre caratteristiche estremamente interessanti:

  • Indici: MongoDB supporta gli indici secondari che consentono di effettuare le query molto più velocemente;
  • Aggregazione: MongoDB supporta l' "aggregation pipeline" che permette di costruire complesse aggregazioni da elementi più semplici con conseguente ottimizzazione del database;
  • Collection speciali: MongoDB supporta della collection speciali come la time-to-live (TTL) collection estremamente utile per lo storage solo dei dati recenti
  • File storage: protocollo semplificato per lo storage di file di grandi dimensioni e file metadata.

 

Performance, performance, performance...

L'aspetto di maggior interesse comunque restano le incredibili performance che questo DB può esprimere. MongoDB, infatti, usa quanta più RAM possibile come cache e cerca automaticamente di scegliere il miglior indice per le query: tutto è stato disegnato per le performance.

 

e per tutto il resto c'è... SQL... ovvero quando non usare MongoDB

Nonostate MongoDB sia davvero un database molto versatile credo che in alcune occasioni sia più indicato ricorrere ad un DB relazionale:

  1. Quando vogliamo utilizzare le transazioni dato che MongoDB non le supporta;
  2. Quando abbiamo bisogno di fare dei "JOIN" fra diversi tipi di dati attraverso "dimensioni" differenti 
  3. Infine quando si vogliono usare dei tool che non supportano MongoDB (putroppo!!!!) come Wordpress o SQLAlchemy...

 

e CAKEPHP...

Dimenticavo di dire che ci sono numerose librerie che permettono di utilizzare questo DB con il framework CAKEPHP.