Per decenni i database degni di questo nome sono stati database relazionali: l'approccio relazionale alla gestione dei dati e il relativo linguaggio di riferimento per le query (SQL) sono stati punti inamovibili dell'IT. A buona ragione: il modello relazionale è collaudato, conosciuto e adatto alle applicazioni più esigenti. È in sostanza molto affidabile, elemento essenziale per il mondo aziendale e le applicazioni business in cui è ampiamente adottato.

In altri ambiti però, specialmente nello sviluppo di applicazioni aperte al web, la grande affidabilità del modello relazionale è stata messa in secondo piano dal prezzo che si paga per averla. I database SQL di norma non sono molto scalabili e non puntano al massimo delle prestazioni. Ma quando si pensa ad applicazioni che possono essere usate da milioni di utenti via Internet e con profili di carico a volte imprevedibili, scalabilità e performance diventano più importanti dell'affidabilità. Serviva quindi un'alternativa ai database SQL classici, ecco lo sviluppo del mondo NoSQL.

Il tratto caratteristico dei database NoSQL è l'abbandono della rigidità del modello relazionale, in cui i dati sono precisamente strutturati. Nella rappresentazione classica tabellare, ogni record corrisponde a una riga e i suoi campi costituiscono le colonne della tabella stessa. Lo schema del database indica precisamente che tipo di dato può trovarsi in un campo, e quindi in una colonna. Nei database NoSQL non esiste uno schema così rigido e in linea teorica un record può contenere qualsiasi tipo di dato, senza che i suoi contenuti debbano essere normalizzati con quelli degli altri record.



Così abbiamo database NoSQL in cui i record contengono generici "documenti" (in realtà oggetti JSON) da cui la definizione di document database (come MongoDB), ma anche database strutturati per colonne invece che per righe (come Cassandra) e altri che rappresentano i dati come grafi fra oggetti generici non strutturati (i graph database come Neo4j). Questa destrutturazione è un vantaggio se non si vuole essere limitati da uno schema rigido da mantenere nel tempo o se si gestiscono dati che sono di per sé stessi destrutturati.

Ma il vantaggio principale è probabilmente la scalabilità dei database NoSQL, che sono pensati da zero per gestire i dati distribuiti su un cluster di nodi. L'approccio NoSQL vuole tra l'altro che i nodi siano autonomi fra loro, quindi è facile aggiungere un nuovo nodo quando serve più potenza complessiva e la gestione delle query è molto veloce: il primo nodo che può "rispondere" con i dati giusti lo farà.

Questa destrutturazione ha un prezzo: è l'affidabilità tipica del mondo SQL, intesa soprattutto come consistenza e coerenza dei dati. Il problema può essere considerato da due punti di vista: applicativo e architetturale. Il primo riguarda il controllo sui dati che memorizziamo e gestiamo in un database: qualsiasi verifica di coerenza dei dati (anche banalmente che un nome sia una stringa di testo, ad esempio) deve essere fatta a livello applicativo e non "viaggia" con il database, quindi andrà replicata (se necessario) in qualsiasi applicazione che usi quella base dati.



La consistenza dei dati è anche una questione architetturale. Un cluster di un database NoSQL a priori non si preoccupa di garantire le proprietà dette in gergo ACID, ossia che le operazioni sui dati siano atomiche (tutte le parti di una operazione sono completate o non lo è nessuna), consistenti (i dati non variano al variare del nodo o di chi li consulta), isolate (le operazioni non sono in competizione fra loro) e durevoli (la caduta di un nodo non le fa "scomparire"). Questo, in estrema sintesi, vuol dire che a seconda dello specifico database qualcuna di queste proprietà potrebbe essere ignorata. In particolare, non è detto che in un dato momento tutti i nodi di un cluster "vedano" i dati allo stesso modo: alcune modifiche possono richiedere tempo per propagarsi tra i nodi, altre potrebbero anche essersi perse.

Un altro limite dei database NoSQL è che hanno seguito linee di sviluppo autonome e quindi possono essere davvero molto diversi. Passare dall'uno all'altro, anche all'interno di gruppi di database simili, non è necessariamente semplice. Ogni database ha ad esempio un suo linguaggio di query più o meno simile a SQL e un suo modo per restituire i risultati. Questo significa che un'applicazione sviluppata per funzionare con, ad esempio, MongoDB dovrà molto probabilmente essere modificata se decidiamo di usare un altro document database. Non basterà migrare i dati da un tipo di database all'altro.

Tirando le somme, i mondi SQL e NoSQL sono concettualmente così differenti che sono alternative molto meno in competizione di quanto alcune software house indichino. Molto spesso la scelta tra un approccio e un altro è quasi automatica in funzione di quello che si intende fare. Una maggiore sovrapposizione arriverà con il tempo: già ora alcuni database NoSQL cercano ad esempio di garantire una maggiore consistenza dei dati, mentre alcune piattaforme SQL si aprono alla gestione di dati sempre meno strutturati. Ma per ora il dilemma fra una soluzione NoSQL e una classica è poco problematico.