Vantaggi e svantaggi dei database non relazionali (NoSql)

I database non relazionali, pur non essendo una novità assoluta, hanno registrato una crescita esponenziale nel loro sviluppo e utilizzo negli ultimi mesi grazie al sempre più crescente bisogno di scalare in orizzontale, dove i classici RDBMS (database relazionali) presentano diverse limitazioni. Si pensi infatti ai sempre più in voga sistemi cloud dove i nodi possono diventare veramente molti, gestire un RDBMS in un ambiente del genere risulta complicato e la potenza computazionale non viene sfruttata in modo ottimale.

Viste queste problematiche, i giganti del web, che si trovano a dover gestire database di dimensioni veramente imponenti, hanno sviluppato (o contribuito allo sviluppo) vari NRDBMS (database non relazionali) con approcci leggermente diversi, ma tutti con gli stessi principi di base, si raggruppano infatti sotto la dicitura di movimento NoSQL (Not Only SQL).Come in ogni nuovo modello nei database NoSQL si sono riscontrati sia dei vantaggi che dei svantaggi. Tra i vantaggi si notano sicuramente le performance più alte per i tempi di risposta, infatti nei database non relazionali un elemento contiene tutte le informazioni necessarie e dunque non serve usare i dispendiosi “join” come invece avviene per i database relazionali.

Inoltre la semplicità di questi database è uno degli elementi fondamentali, è proprio questo che permette di scalare in orizzontale in maniera così efficiente, molti NRDBMS, infatti, permettono di aggiungere nodi a caldo in maniera impercettibile dall’utente finale. Infine scegliendo un database adatto alla mappatura più diretta alle object classes del proprio applicativo si possono ridurre di molto i tempi dedicati allo sviluppo del metodo di scambio dati tra il database e l’applicativo stesso (il cosiddetto object-relational mapping che è invece necessario in presenza di database relazionali).La semplicità di questi database comporta però anche degli svantaggi: mancando i controlli fondamentali sull’integrità dei dati, il compito ricade quindi totalmente sull’applicativo che dialoga con il database che ovviamente dovrebbe essere testato in modo molto approfondito prima di essere messo in produzione. Per fare un esempio, se avessimo un database dei clienti coi relativi ordini effettuati immagazzinati in elementi diversi, anche se è possibile definire una relazione attraverso le chiavi, in un database non relazionale alla cancellazione di un cliente tutti gli ordini resterebbero comunque nel database, è quindi l’applicativo che una volta impartito il comando di cancellazione dell’utente X deve anche andare a cancellare tutti i relativi ordini, cosa che invece in un database relazionale è gestita direttamente dal database stesso.

Altra pecca è la mancanza di uno standard universale, come può essere l’SQL. Ogni database ha infatti le proprie API e il suo metodo di storing e di accesso ai dati. Pertanto il passaggio da un database ad un altro non è sicuramente immediato, ma richiederebbe alcuni cambi più o meno radicali da apportare all’applicativo; q quindi necessario tenere in considerazione la cosa al momento del brainstorming iniziale.Nonostante ciò, i database non relazionali, seppur non essendo la soluzione definitiva al problema del salvataggio e recupero dei dati, visto l’avvento di Social Network e del cloud, risultano la miglior soluzione in questi contesti dove ogni giorno bisogna salvare un numero elevatissimo di dati e solo grazie alla scalabilità orizzontale dei database No-SQL e quindi all’aggiunta di server facili da gestire, è possibile ottenere delle performance soddisfacenti, molto migliori rispetto ai soliti database relazionali. Esempi di applicazioni che utilizzano questo modello sono infatti Twitter, Facebook e Amazon.