Indice dei contenuti
I database NoSQL sono una realtà consolidata ormai da molti anni e godono di una grande diffusione a tutti i livelli: la maggior parte dei provider di servizi cloud (Amazon, Google, Microsoft, etc.) fornisce soluzioni NoSQL in modalità as-a-service per la gestione dei dati, utilizzate ad oggi da milioni di utenti in tutto il mondo anche a livello enterprise. In questo articolo cercheremo di far luce sulle principali caratteristiche di questa soluzione, sottolineandone le similarità e differenze rispetto ai database relazionali, con l'obiettivo di comprenderne al meglio i principali ambiti di utilizzo e individuare gli scenari in cui - perlomeno a nostro avviso - non rappresentano ad oggi la soluzione ottimale.
L'obiettivo di questo contributo è quello di rendere DBA e sviluppatori in grado di fare una scelta consapevole quando si deve prendere in considerazione l'utilizzo di una determinata base dati (RDBMS o NoSQL) all’interno di un progetto.
Definizione
SQL, acronimo di Structured Query Language, è un linguaggio volto all’interrogazione di dati altamente strutturati per mezzo di una sintassi grossomodo standardizzata, cosa che rende possibile migrare agevolmente da un sistema all’altro. L’approccio NoSQL, alternativo al precedente a partire dal nome, nasce dall’esigenza di dover rappresentare dati per loro natura eterogenei, per i quali ha poco senso (o sarebbe troppo oneroso) forzare una struttura.
Applicabilità
Da un punto di vista teorico, l’approccio SQL si rivela applicabile alla maggior parte dei contesti, in quanto la standardizzazione dei dati costituisce quasi sempre un obiettivo primario dello sviluppo software nella quasi totalità dei progetti IT: al tempo stesso, la versatilità dell’approccio NoSQL si sposa bene con un approccio iterativo ed evolutivo (tipico delle metodologie Agile), in quanto si prevede che ci sarà spesso bisogno di molte iterazioni, feedback e refactoring prima di poter raggiungere una standardizzazione effettiva della base dati.
Entrambe le argomentazioni sono ragionevoli e facilmente verificabili: di conseguenza, non esiste una soluzione “migliore” o “peggiore” in assoluto, ma entrambe possono essere più o meno adatte a seconda delle singole circostanze e scenari implementativi. Di seguito si propone un confronto tra i due sistemi, declinato nelle principali caratteristiche funzionali che ci si aspetta da un DBMS.
Transazioni
Il supporto delle transazioni ACID (Atomicity, Consistency, Isolation, Durability) è un punto di forza dei RDBMS; i DB NoSQL hanno un approccio diverso, basato sulla atomicità della singola istruzione, che però non è sufficiente a garantire una consistenza su una pluralità eterogenea di inserimenti a meno di non gestirla a livello applicativo (manualmente o con middleware ad hoc). Di conseguenza, se il supporto transazionale è importante, l’utilizzo di un RDBS è raccomandato.
Performance
I DB NoSQL garantiscono spesso prestazioni migliori e sono generalmente considerati più efficienti; i RDBMS più moderni sono in grado di garantire performance paragonabili, a patto di disegnare il database in modo efficiente, utilizzando gli indici in modo opportuno e strutturando le Query nel modo corretto e senza commettere errori: si tratta certamente di un lavoro più complesso, in assenza del quale i DB NoSQL risultano superiori.
Cache
Il punto di forza dei DB NoSQL è quando vengono utilizzati come cache, in quanto i datastore utilizzati a tale scopo (key-value pair, generalmente su standard Redis) sono estremamente veloci ed efficienti. Si tratta del resto di uno degli utilizzi più diffusi dei DB NoSQL, anche perché è compatibile con l’utilizzo di un RDBMS che operi “dietro” alla cache.
Data Normalization
La normalizzazione (o tipizzazione) dei dati è un altro punto di forza dei RDBMS, ma è spesso anche una debolezza a livello applicativo perché costringe a operare con query complesse (JOIN, MERGE etc.) qualora il Data Model presenti molteplici livelli di relazione. I DB NoSQL non hanno questo problema in quanto, lavorando in un contesto destrutturato e privo di un DB Schema definito a priori, supportano nativamente liste, nested entities e strutture relazionali.
Il “costo” di questo approccio porta però alla frequente duplicazione dei dati, che aumenta le dimensioni del DB e complica le cose in caso di aggiornamenti orizzontali dei dati “annidati” (oltre a rallentare le prestazioni). Questo problema, nelle versioni più recenti dei motori NoSQL più diffusi, viene risolto con l’implementazione dei “riferimenti”, che però a ben vedere altro non sono che relazioni.
Quando usare cosa?
Sulla base di quanto detto, cerchiamo di tirare le somme e individuare degli ambiti di utilizzo reali per i due approcci che abbiamo descritto.
In termini generali, potremmo affermare che l'utilizzo di un RDBMS è a tut'oggi preferibile in caso di dati strutturati, facili da rappresentare e con numero ridotto di relazioni, oltre che in tutti i casi in cui è importante garantire l’integrità dei dati in senso “ACID”.
Viceversa, l'approccio NoSQL risulta convincente in caso di dati “polimorfi”, ovvero dotati di una struttura estremamente variabile e tendenzialmente mutevole o soggetta a cambiamenti frequenti e/o imprevedibili; inoltre, si tratta di una modalità di storage e accesso ai dati che risulta estremamente efficace in tutte le situazioni legate al caching dei dati e alla gestione di informazioni destrutturate (o parzialmente strutturate) contraddistinte da una persistenza temporanea e variabile nel corso del tempo: HTTP session management, key-value pair, etc..
