Quando sento parlare di “confronti” tra NOSQL e SQL rimango sempre stupito.
Spesso i programmatori non osservano le cose che hanno sotto gli occhi e quella che sembra una banalità viene vista come una rivoluzione tecnologica.
Capita, purtroppo troppo spesso, che mi trovo a trasformare documenti NOSQL in strutture relazionali su database classici (tipicamente MySQL e PostgreSQL), quasi sempre per ovviare a problemi sui dati che erano stati sottovalutati e che invece hanno un grande impatto sullo sviluppo dell’applicazione o del sito web.
Ma andiamo per ordine.
I Database non sono solo contenitori di dati
Chi come me è fissato con l’organizzazione sa che i database non servono solo a contenere testi e numeri, ma servono più che altro a tenerli in ordine e a recuperare facilmente le cose di cui hai bisogno.
Così come mettiamo in ordine le camicie per colore nell’armadio, e se non lo fate è il caso che iniziate a farlo, allo stesso modo dovete tenere i dati ben ordinati nel vostro database.
Ammucchiare dati in una tabella o in un documento è sempre sbagliato. Il vantaggio che avrete nella prima fase dello sviluppo lo pagherete caro quando il progetto andrà avanti.
Un piccolo sforzo iniziale porta ad un grande vantaggio futuro.
Il formato non è la struttura dati
Con la moda di Node JS i NOSQL hanno avuto una grande spinta, perché il formato di lettura e scrittura è facilmente lavorabile in javascript.
Ma il formato dei NOSQL non è una struttura dati.
Un documento NOSQL è, per sua natura, un aggregato di differenti dati che vengono utilizzati insieme.
Questo lo si capisce quando trasformiamo un documento NOSQL nella corrispettiva struttura di un database relazionale.
Un semplice esempio:
{
"_id": "5099803df3f4948bd2f98391",
"user": {
"first": "Francesco",
"last": "Contini",
"nation": "Italy"
},
"contact": {
"phone": {
"cell": "123-456-789",
"work": "987-654-321"
},
"email": ["email@email.com", "email_2@email.com]
}
}
Questo documento identifica un utente, c’è il documento principale con 3 campi 2 dei quali sono sottodocumenti.
Il primo, “user”, è un sottodocumento semplice, il secondo, “contact”, è a sua volta composto da 1 sottodocumento e un campo fisso.
Se volessimo trasformarlo in SQL avremmo 3 tabelle (PK è Primary Key, FK è Foreign Key):
CREATE TABLE user (id serial PK, first varchar[32], last varchar[32], nation varchar[128]); CREATE TABLE contact (user_id integer FK, email varchar[128]) CREATE TABLE phone (user_id integer FK, type varchar[16], number varchar[32])
Queste 2 strutture sono equivalenti, con un layer che trasforma i dati SQL in json neanche sapresti quale database stai usando.
Ma quindi dov’è la reale differenza tra un database e l’altro?
Quali sono i vantaggi e gli svantaggi nell’usare uno o l’altro database?
La reale differenza tra SQL e NOSQL
Per capire la reale differenza tra queste 2 famiglie di database dobbiamo fare uno sforzo di fantasia ed astrarre la gestione dei dati ad un livello più alto.
I database relazionali sono stati ideati e costruiti per la sicurezza dei dati e gestire sequenze di operazioni di modifica come una sola operazione, le famose transazioni, per rispettare quello che in gergo si chiama ACID (Atomicità, Consistenza, Isolamento e Durabilità).
Rispettare le quattro regole ACID ha un costo abbastanza elevato, ad esempio la quantità dei dati ha un peso elaborativo esponenziale, ma il grosso problema che ancora oggi non è stata risolta appieno, è la scalabilità dei database.
I database NOSQL invece sono stati costruiti proprio per risolvere questo problema, purtroppo non rispettando le regole ACID.
Uno dei problemi più grandi per i database NOSQL era quello di mantenere le relazioni tra i dati, quindi la scelta più efficace era quella di eliminare le relazioni creando una struttura di base più complessa, che permette di avere il gruppo di dati necessari tutti assieme in un unico posto.
In gergo si dice che il NOSQL usa il principio della consistenza finale. In pratica se non ci sono nuovi aggiornamenti per un determinato dato, in un certo periodo di tempo, tutti gli accessi al dato restituiranno l’ultimo valore aggiornato.
Di contro se abbiamo 10 client che in contemporanea modificano e leggono il dato potremmo avere 10 risultati diversi per un lasso di tempo anche abbastanza lungo.
I NOSQL applicano così le regole BASE: Basically Available, Soft state, Eventual consistency.
Si avete letto bene: Eventualmente Consistente.
Quando perdere i dati non è un problema
Se usate NOSQL per salvare massivamente dei dati, beh, non affezionatevi ad un documento in particolare, perché non è detto che resti lì per sempre.
Se ci fate caso i NOSQL sono largamente usati nei social network, che sono applicazioni che per loro natura non hanno bisogno di avere una sicurezza o una regolarità sulla pubblicazione dei dati.
Se pubblicate un post su Facebook e questo non è disponibile ai vostri amici se non dopo 5 minuti nessuno se ne accorge.
Se sparisce un vostro tweet nessuno se ne accorge (o quasi, leggete: Twitter al lavoro per evitare che i tweet spariscano )
Questa è la natura del NOSQL, per questo raramente vengono usati in campo finanziario, economico e statistico.
Se ci fate caso il database più usato per l’Intelligenza Artificiale è Postgresql, che è il database open source che garantisce più sicurezza sui dati, e non un NOSQL, nonostante la quantità di dati sia ENORME!!!
Quando il NOSQL ti salva la vita
Quando dobbiamo lavorare su una applicazione che ha bisogno di una grandissima quantità di dati, di letture e di scritture o di modifiche sugli stessi, ma che non necessità una lavorazione o una pubblicazione in tempo reale allora il NOSQL è una soluzione papabile.
La struttura dati e l’applicazione ovviamente va pensata per questo tipo di database.
Considerate che se va cambiata la struttura del documento spesso conviene caricare massivamente una nuova collezione con la nuova struttura che andare a modificare la collezione corrente.
Questo perché, se nei database relazionali aggiungere una colonna ha un impatto tutto sommato accettabile, in NOSQL il rischio di avere documenti dalla struttura mista nuova/vecchia può avere un impatto importante, quindi è più rapido costruire uno scriptino che faccia il lavoro sporco che andare ad aggiungere tonnellate di controlli sull’applicazione per gestire le differenze.