Database NoSQL e miti da sfatare

I database NoSQL [1] sono una realtà consolidata ormai da diversi anni e una valida alternativa ai database relazionali. Tuttavia è importante anche comprendere quali sono i limiti di questa soluzione, in modo da essere consapevoli di quali sono i possibili campi di utilizzo e in quali scenari invece non rappresentano la soluzione ottimale, così da essere in grado di fare una scelta consapevole quando si deve prendere in considerazione il loro utilizzo all’interno di un progetto.

Le origini dei database NoSQL

Per comprendere i plus e i minus dei database NoSQL conviene partire dalle ragioni che hanno portato alcune aziende nel corso degli anni a superare il modello relazionale, a favore di un database che fosse in grado di meglio gestire certi problemi.
Aziende come Google [2], Amazon [3] o Facebook avevano la necessità di gestire volumi di dati eccezionalmente grandi, con la necessità di avere dei tempi di risposta bassi anche con insiemi di dati enormi, pur mantenendo una elevata disponibilità del servizio. Queste problematiche difficilmente sono risolvibili attraverso un database relazionale.
La ragione per cui un database relazionale non è in grado di gestire volumi enormi di dati deriva in parte dal modo in cui esso viene utilizzato nella maggior parte dei casi: per gestire dati organizzati su tabelle normalizzate.

La normalizzazione dei dati [4] è una tecnica consolidata per la progettazione di una base dati che prevede di evitare la ripetizione dei dati su più tabelle, in modo da escludere la duplicazione di dati e rendere più semplici le operazioni di scrittura: inserire, modificare o cancellare dati diventa un’operazione molto semplice e snella, perchè i dati non sono mai ridondati su più tabelle.
Per contro, un database relazionale in cui i dati sono stati normalizzati tende a disperdere il contenuto informativo su più tabelle: ciò significa che le operazioni di recupero dei dati sparsi su più tabelle diventa più complicato, perchè è necessario recuperare le informazioni combinando i dati provenienti da molteplici tabelle (operazione di join [5]) ed il risultato è che i tempi di sviluppo di applicazioni che leggono dati si allungano, come pure i tempi di attesa per la lettura dei dati possono diventare eccessivamente lunghi.

Caratteristiche principali

Partendo da queste considerazioni, i database NoSQL (Not Only SQL) non prevedono il recupero di informazioni memorizzate su più tabelle, perchè l’approccio in questo caso è l’inverso: il database deve essere denormalizzato, cioè tutte le informazioni necessarie in fase di lettura di dati devono essere disponibili su una singola entità e questo si traduce in ridondare le informazioni su ogni entità in cui è richiesta la stessa informazione.
Per esempio, se si deve visualizzare su una lista i dati relativi ad un ordine di vendita, comprese informazioni anagrafiche del cliente a cui l’ordine si riferisce, tutte le informazioni anagrafiche del cliente devono essere state salvate (duplicate) anche nell’entità dell’ordine, così da non avere bisogno di recuperare dati da altre entità.

Per contro, se le operazioni di lettura sono diventate molto più semplici e con ridotti tempi di risposta, le operazioni di scrittura si sono complicate: ora ogni volta che si deve aggiornare un dato ridondato in più entità, diventa necessario aggiornare il dato su tutte le entità in cui è stato duplicato.

Va inoltre precisato che ci sono diverse implementazioni di database NoSQL, caratterizzate da approcci implementativi diversi, che si possono ricondurre a 4 categorie principali: database chiave-valore, documentali, colonnare, a grafo.

Indipendentemente dall’approccio adottato dallo specifico database NoSQL, le considerazioni espresse si possono considerare comunque valide.

Un confronto

In realtà, quanto detto finora potrebbe portare a concludere che la progettazione della base dati (normalizzazione o denormalizzazione dei dati) rappresenti un aspetto chiave nella riduzione dei tempi di lettura dei dati: meno un database è normalizzato, meno sono le entità da combinare, più veloci sono i tempi di risposta. Sembra che il tipo di database (relazionale o NoSQL) non sia un aspetto determinante, mentre in realtà lo diventa con grossi volumi di dati.
A titolo di esempio [6], si possono riportare questi tempi di risposta, al crescere del volume dei dati, con un database relazionale (MySQL) ed uno NoSQL (Mongo DB), dove la base dati è stata in entrambi i casi denormalizzata.

Documenti archiviati	MySQL con base dati normalizzata	MySQL con base dati denormalizzata	Mongo DB con base dati denormalizzata
2.000	0.03 secondi	0.01 secondi	0.044 secondi
500.000	12.66 secondi	3.56 secondi	3.2 secondi
1.500.000	2 min 46 secondi	33.95 secondi	9.66 secondi

Come si può osservare, quando i dati sono denormalizzati, un database relazionale ha dei buoni tempi di risposta, anche se non buoni tanto quanto quelli di un database NoSQL.
La maggiore velocità in lettura di un database NoSQL deriva dalla sua implementazione, diversa da quella dei database relazionali: essa è ottimizzata per grossi volumi di dati e con un linguaggio di interrogazione più semplice (meno potente) del linguaggio SQL usato dai database relazionali. Maggiore è il volume di dati e più conveniente diventa l’adozione di un database NoSQL.

Pro & contro

I principali vantaggi derivanti dall’uso di database NoSQL si possono riassumere in:

• elevata velocità computazionale, anche al crescere del volume dei dati, legata alla mancanza di operazioni di aggregazione dei dati (no join) e ad una implementazione del database ottimizzata per la gestione di enormi quantità di dati; questa velocità è anche il frutto di alcune semplificazioni introdotte nella maggior parte dei database NoSQL: il mancato supporto delle transazioni ACID (descritte più sotto)
• riduzione significativa dei tempi di sviluppo, grazie alla definizione di logiche di lettura dati molto più semplici rispetto a quelle da scrivere con database relazionali che operano su dati normalizzati (come si è visto prima, questo in realtà dipende dal fatto di dover denormalizzare i dati, più che ad un plus dei database NoSQL in sè).
• supporto per la scalabilità orizzontale, cioè la capacità di garantire tempi di risposta sostanzialmente invariati al crescere del carico, tramite l’aggiunta di nuovi server
• un elevato livello di disponibilità del servizio, anche grazie al supporto della data-replication (database distribuiti), più semplice da realizzare per i database NoSQL
• schemaless, cioè i database NoSQL sono privi di schema in quanto l’entità contiene tutti i campi necessari, senza necessità di una definizione formale e rigida del suo contenuto. In questo modo, è possibile arricchire le applicazioni di nuovi dati e informazioni, senza dover sottostare ad una rigida struttura dei dati.

E’ fondamentale a questo punto tenere presente che non ci sono solo vantaggi nell’adozione di database NoSQL: è vero che diventano determinanti al crescere della mole di dati da gestire, ma è altrettanto vero che per avere questo e altri plus, si sono introdotte anche delle importanti limitazioni, che si devono conoscere, in modo da capire quando è realmente il caso di utilizzare un database NoSQL e quando no.

Le principali criticità si possono riepilogare in:

• mancanza di una gestione delle transazioni completa: i database relazionali normalmente forniscono una gestione atomica, consistente, isolata e persistente dei dati, dall’inglese ACID (Atomicity, Consistency, Isolation, Durability); i database NoSQL tipicamente garantiscono l’atomicità di singole operazioni ma non di una sequenza di singole operazioni. Come conseguenza, diventa onere dell’applicazione (sempre se possibile) garantire il completamento della transazione in uno stato consistente ed atomico rispetto ad una sequenza di operazioni.
• mancanza di supporto per il data fixing: il linguaggio di interrogazione non è espressivo come l’SQL per i database relazionali; come conseguenza, operazioni di correzione massiva dei dati sul database sono più difficili da realizzare, se non attraverso complesse logiche applicative
• mancanza di supporto per il reporting: di nuovo, il linguaggio di interrogazione non è sufficientemente potente per condurre una analisi statistica dei dati memorizzati (es. Business Intelligence), che andrà quindi realizzata attraverso logiche applicative complesse e potenzialmente con lunghi tempi di attesa; parziali soluzioni a questo problema potrebbero essere la tecnica del Map Reducing [7] o più semplicemente accostare ad un database NoSQL anche un database relazionale che meglio può gestire logiche di recupero dati complesse
• mancanza di supporto per l’export dati: non sempre sono disponibili meccanismi (es. API) per l’estrazione di tutti i dati e questo rende più difficile l’eventuale porting dei dati da un database NoSQL ad un altro, qualora si volesse migrare un giorno ad una soluzione migliore (lock-in della soluzione)
• mancanza di standard per il linguaggio di interrogazione: ad oggi le implementazioni di database NoSQL usano un proprio linguaggio di interrogazione proprietario e diverso da quello di altre soluzioni; non c’è qualcosa di equivalente al linguaggio SQL e quindi la portabilità dei dati e delle logiche applicative non è così semplice come può esserlo nel caso di migrazione tra database relazionali
• le operazioni di scrittura si sono complicate: ora ogni volta che si deve aggiornare un dato ridondato in più entità, diventa necessario aggiornare il dato su tutte le entità in cui è stato duplicato; questo di fatto tende ad allungare i tempi di sviluppo, anche se le operazioni di lettura si sono notevolmente semplificate
• essendo i dati ridondati, non ci può più essere un controllo sull’integrità dei dati da parte del database: il compito ricade totalmente sull’applicativo che comunica con il database.

Conclusioni

In conclusione, i database NoSQL vengono spesso contrapposti ai database relazionali, presentandoli come una soluzione alternativa, da impiegare negli stessi scenari applicativi. In realtà i database NoSQL risolvono specifici problemi (scalabilità, migliore gestione di grossi volumi di dati) a patto di accettare determinate limitazioni.
Non è perciò scontato che la loro adozione rappresenti la scelta più corretta in qualunque scenario. Nè vanno usati necessariamente in sostituzione dei database relazionali: essi dovrebbero essere utilizzati con determinate strutture dati (denormalizzate) e a patto che sia accettabile per l’applicazione da costruire la limitata gestione delle transazioni ed infine in presenza di logiche applicative compatibili con il linguaggio di interrogazione fornito con il database NoSQL (no analisi dati, no logiche di business eccessivamente complesse).
In un prossimo articolo, vedremo alcuni esempi concreti di database NoSQL e come semplificarne l’utilizzo attraverso uno strumento di sviluppo rapido.