Durante l’ultimo mezzo secolo i database relazionali (RDBMS) si sono imposti come lo standard per l’archiviazione dei dati.

Con essi è nato e si è evoluto il linguaggio SQL (Structured Query Language) che è tutt’oggi il metodo più popolare per interagire con le basi dati.

Recentemente (dal 2000 circa) l’avvento del cloud come piattaforma abilitante, la sempre più vasta diffusione di internet a livello mondiale e l’incessante crescita dei volumi di dati da gestire, hanno fatto emergere alcune limitazioni intrinseche a questi strumenti.

Per superare tali limitazioni è nata una nuova famiglia di database genericamente etichettata come NoSQL: l’idea fondamentale è quella di semplificare drasticamente sia il modo di archiviare le informazioni (passando dalla rappresentazione relazionale dei dati a uno schema destrutturato), sia il linguaggio usato per dialogare con il database.

Così come è avvenuto nel mercato dei database RDBMS, stiamo assistendo a un fiorire di prodotti NoSQL sia da parte dei tradizionali “big” dell’informatica (Google, Amazon, ecc.) sia da parte di nuovi attori in questo scenario.

Fondamentalmente questi prodotti si contraddistinguono per la facilità d’uso ed elevate scalabilità e disponibilità, caratteristiche indispensabili per database con un elevatissimo volume di dati e un altrettanto consistente numero di utenti concorrenti.

Le tipologie di database offerte sono differenti (Document Store, Key Value Store, ecc.), ma la loro disamina non è oggetto di questo breve articolo; piuttosto qui intendiamo illustrare i criteri che seguiamo per decidere quale delle due tecnologie adottare nei nostri progetti software.

Come scegliamo quale database utilizzare per ogni progetto

Il primo punto che ci preme sottolineare è che non crediamo che NoSQL sia un sostituto dei database tradizionali: i due hanno ovviamente dei punti in comune, ma ciascuno ha delle caratteristiche che lo rendono più o meno adatto a uno specifico progetto.
Per fare la scelta corretta è fondamentale avere un’idea il più precisa possibile di quali dati si dovranno manipolare e di come questi saranno interrogati dai vari componenti del progetto.

Tralasciando il volume di dati (non capita spesso di affrontare progetti di complessità e dimensioni paragonabili a quelle di Amazon), la discriminante principale secondo noi è la loro relazionalità.
Alcune applicazioni gestiscono dati con relativamente poche entità o comunque con un ridotto livello di relazioni tra di esse, altre hanno invece necessità di rappresentare gerarchie complesse e soddisfare sofisticati criteri di interrogazione dei dati.
Per i progetti di primo tipo tendiamo a preferire un database NoSQL, mentre per gli altri riteniamo sia più adatto un database tradizionale.

Un altro aspetto che merita considerazione è il tipo di transazioni che il progetto richiede.
È assolutamente indispensabile che ogni singola scrittura venga immediatamente propagata in modo che ciascun client abbia a disposizione l’ultima versione dei dati? Probabilmente è meglio adottare un RDBMS (e rinunciare alla distribuzione dei dati su nodi diversi).
Di contro, è possibile eseguire una transazione e demandare al sistema la sua propagazione in tutti i nodi quando questi saranno raggiungibili? In tal caso un NoSQL può essere un’ottima scelta (rinunciando alla consistenza immediata dei dati).

Ci sono ovviamente molti altri fattori di cui tener conto. Per citarne solo alcuni:

  • I dati sono principalmente in sola lettura?
  • Gli utenti sono geograficamente sparsi in zone diverse?
  • Su quale tipo di hardware sarà installato il database?

Naturalmente nella realtà è può essere arduo applicare dei concetti generali ai casi che ci si trova ad affrontare: spesso entrambi i tipi di database (se usati correttamente) possono essere adottati all’interno di un progetto. In tal caso altre considerazioni possono giocare un ruolo decisivo nella scelta: familiarità del proprio team tecnico con lo strumento, costi di licenze software, livelli di servizio offerti dal vendor, ecc.

A complicare ulteriormente le cose va detto che alcune delle differenze sopra descritte tendono a diventare meno discriminanti con l’evolversi delle tecnologie. Da un lato i database NoSQL stanno maturando offrendo caratteristiche sempre più simili a quelle della controparte (gestione delle transazioni, avanzate funzionalità di data recovery, ecc.) mentre gli RDBMS stanno aggiungendo alle loro funzionalità la gestione di dati destrutturati tipica dei NoSQL (vedasi ad esempio il supporto di JSON data nelle ultime versioni di Oracle DB).

Database NewSQL

Segnaliamo, infine, la nascita di una nuova generazione di database, detta NewSQL, che promette di combinare i benefici dei due mondi:

  • elevata consistenza dei dati
  • supporto di transazioni ACID
  • livelli di scalabilità e performance tipiche dei NoSQL

In pratica la confutazione del teorema CAP.

È ancora troppo presto per sapere se questo approccio avrà successo ma, in un mondo in cui la disponibilità della rete sta raggiungendo livelli impensabili fino a qualche anno fa, non ci sentiamo di escludere che questo possa rappresentare il futuro dell’archiviazione dati.