Gli esperti di Ibm, sul blog ufficiale dell’azienda dedicato ai temi riguardanti il cloud computing, hanno fatto il punto su cosa sono i database SQL e NoSQL, le loro differenze e l’opzione migliore da scegliere per la situazione della propria azienda.

Ci sono centinaia di database diversi disponibili sul marcato tra cui scegliere e, per gli sviluppatori, la decisione non è semplice. La tassonomia più popolare degli ultimi dieci anni, sottolinea Ibm, suddivide il panorama dei database in due classi: SQL (database relazionali) e NoSQL (tutto il resto).

Innanzitutto, gli esperti di Ibm danno uno sguardo più approfondito a ciò che si intende generalmente con questi due moniker e poi analizzano cosa significano realmente per gli sviluppatori di applicazioni.

Che cos’è un database SQL

In breve, i database SQL supportano SQL, un linguaggio specifico del dominio per l’interrogazione e la manipolazione dei dati in un database relazionale. Il termine ”relazionale” in database relazionale si riferisce al “modello relazionale” di gestione dei dati ideato dal ricercatore di Ibm E.F. Codd nei primi anni 70 e reso popolare in un numero di sistemi di database successivi, a partire dal System R.

Sono classici database SQL Db2, PostgreSQL, MySQL, Oracle, SQL Server.

La chiave del loro modello relazionale è l’astrazione dei dati come un insieme di tuple organizzate in relazioni, che consente l’astrazione sulla rappresentazione fisica dei dati e dei percorsi di accesso.

Sebbene SQL non sia l’unico linguaggio possibile per implementare query sul modello relazionale, è di gran lunga il più popolare.

I database SQL e relazionali sono lo standard del settore dalla fine degli anni 70.

All’inizio degli anni 2010, diverse organizzazioni hanno iniziato a costruire sistemi relazionali o basati su SQL che hanno fatto diversi compromessi, in particolare per quanto riguarda la scalabilità orizzontale. Ciò ha portato ai seguenti due percorsi ampiamente distinti.

NewSQL: sistemi che in genere prendono i database relazionali esistenti e vi sovrappongono la logica distribuita con vari gradi di trasparenza per l’utente. Citus e Vitess sono due esempi degni di nota di motori distribuiti in stile “NewSQL”.

SQL distribuito: questi sistemi adottano un approccio “ground-up” nella costruzione di motori relazionali scalabili orizzontalmente. CockroachDB e Google Spanner sono dei buoni esempi di questo. Questi motori di solito puntano più in alto rispetto alle loro controparti NewSQL.

È importante notare, sottolinea tuttavia Ibm, che una delle motivazioni sia per NoSQL che per NewSQL è il fatto che è molto costoso costruire un database relazionale completo, e la maturità dei sistemi SQL distribuiti disponibili in commercio spesso riflette questo.

I pro e i contro dei database SQL

I vantaggi dei database SQL, secondo gli esperti di Ibm, partoo dal Data storage footprint ridotto a causa della normalizzazione e di altre opportunità di ottimizzazione.

Spesso ciò si traduce in migliori prestazioni e un uso più efficiente delle risorse.

Bene anche la semantica di integrità dei dati forte e ben compresa attraverso ACID (Atomicity, Consistency, Isolation, Durability) e l’accesso standard ai dati.

Il supporto di query è generalmente più flessibile, in grado di gestire una gamma più ampia di carichi di lavoro. SQL astrae rispetto all’implementazione sottostante e consente al motore di ottimizzare le query per adattarsi alla loro rappresentazione su disco.

Se non proprio gli svantaggi, i limiti riguardano modelli di dati rigidi che richiedono un’attenta progettazione iniziale per garantire prestazioni adeguate e resistere all’evoluzione; la modifica di uno schema spesso comporta tempi di inattività.

Ibm cita anche il problema del ridimensionamento orizzontale, che è completamente non supportato, supportato in modo ad hoc o supportato solo su tecnologie relativamente immature.

I motori non distribuiti sono poi generalmente un “single point of failure” che deve essere mitigato dalle tecniche di replica e failover; nessuna illusione di infinita scalabilità.

Che cos’è un database NoSQL

Sono tipici database NoSQL Cassandra, CouchDB , Elasticsearch, MongoDB, Redis.

Qui gli esperti di Ibm avvisano innanzitutto di una cosa: nonostante ne esistano di diversi tipi, non è molto chiaro cosa sia un database NoSQL.

A un certo punto “NoSQL” implicava che un database non supportasse SQL, ma, a peggiorare le cose, alla fine la definizione si è evoluta per significare “non solo SQL”.

Se da un lato questo movimento ha radici risalenti ai primi anni ’90, NoSQL è iniziato davvero a decollare a metà degli anni 2000.

Ispirato dalla pubblicazione di articoli di ricerca di settore su sistemi non relazionali come BigTable di Google e Dynamo di Amazon, è nata un’industria di startup e progetti open source che hanno sviluppato sistemi di database che esplorassero lo spazio di progettazione al di fuori del modello relazionale.

Questo sviluppo era principalmente finalizzato a risolvere due problemi percepiti con i sistemi esistenti, come la mancanza di scalabilità orizzontale e la rigidità del design delle tabelle nei sistemi relazionali.

Ibm fa notare che nessuno di questi problemi ha molto a che fare con SQL, ma riflette invece le decisioni di progettazione e i vincoli dei database relazionali più diffusi.

Mentre la comunità di database relazionali ha in parte risposto a questa sfida (vedi sopra per “NewSQL”), una volta aperte le porte, per così dire, i nuovi database hanno iniziato ad apparire rapidamente.

Il risultato è una proliferazione di sistemi che affrontano ciascuno il problema fondamentale, ovvero memorizzare alcuni bit e renderli disponibili in un secondo momento, in un modo leggermente diverso.

Per molti versi, questo è un vantaggio per gli sviluppatori. È certamente vero che non tutte le applicazioni hanno problemi che assumono la forma di database relazionali o devono fare i compromessi che i database relazionali impongono ai dati e ai modelli di disponibilità.

Questa libertà, tuttavia, non è esente da costi: al fine di prendere una buona decisione tecnologica tra i database NoSQL, uno sviluppatore deve essere dotato di una conoscenza approfondita dell’intero spazio di progettazione, in modo che i compromessi realizzati da un determinato sistema siano chiari.

In altre parole, non si desidera rinunciare accidentalmente a consistency e isolation se la propria applicazione effettivamente le richiede, ad esempio.

Riassumere i pro e i contro dei database NoSQL è impegnativo proprio per questo motivo, sottolineano gli esperti di Ibm. Lo spazio è stato ben esplorato e la gamma di opzioni disponibili è enorme.

Alcuni vantaggi e svantaggi generali indicati da Ibm, che potrebbero non essere tutti applicabili a tutti i NoSQL

I database NoSQL sono generalmente scalabili e altamente disponibili: molti sono generalmente progettati per supportare una scalabilità orizzontale senza soluzione di continuità online e senza significativi single point of failure.

Hanno modelli di dati flessibili: la maggior parte dei sistemi non relazionali non richiede agli sviluppatori di assumere impegni iniziali nei confronti dei modelli di dati; quali schemi esistono, può spesso essere cambiato al volo.

Le prestazioni sono alte: limitando la gamma di operazioni del database (ad esempio, allentando le garanzie di durabilità), molti sistemi NoSQL sono in grado di raggiungere livelli estremamente elevati di prestazioni.

Le astrazioni di dati sono di alto livello: superando il modello di dati “value in a cell”, i sistemi NoSQL possono fornire API di alto livello per potenti strutture di dati.

Per contro, si hanno interpretazioni vaghe dei vincoli ACID: nonostante le affermazioni diffuse del supporto ACID per i sistemi NoSQL, l’interpretazione di ACID è spesso resa così ampia che non si può ricavare molto sulla semantica del database in questione.

Si rileva anche una mancanza di flessibilità nei modelli di accesso: l’astrazione relazionale o SQL offre al motore di database ampi poteri per ottimizzare le query per i dati sottostanti; senza tale astrazione, la rappresentazione dei dati su disco emerge nelle query dell’applicazione e non lascia spazio all’ottimizzazione del motore.

SQL vs NoSQL: quando utilizzarli

Per quanto riguarda SQL, innanzitutto, quando si hanno dati relazionali, questa è la soluzione naturale, ovviamente. Ma, evidenziano gli esperti di Ibm, ci si potrebbe chiedere come identificare tale abbinamento naturale. Quando si guarda i propri dati, risponde Ibm, si vedono entità distinte con relazioni ben definite tra loro che devono essere rigorosamente applicate e/o navigabili? Se è così, c’è la corrispondenza richiesta.

Quando il focus è sull’integrità dei dati, fare affidamento su database relazionali collaudati è una buona scelta, sottolinea ancora Ibm. Quando si desidera un accesso flessibile ai dati, il modello relazionale e SQL consentono un supporto molto maggiore delle query ad hoc.

Inoltre, database come PostgreSQL hanno aggiunto un eccellente supporto per carichi di lavoro in stile NoSQL, con funzionalità come i tipi di dati JSON nativi. Se non sono necessarie le funzionalità di ridimensionamento degli archivi dati NoSQL, possono adattarsi anche ad alcuni carichi di lavoro non relazionali. Ciò li rende un ottimo coltellino svizzero quando si dispone di alcuni dati relazionali e di alcuni dati non strutturati, ma non si desidera acquisire la complessità di lavorare con diversi tipi di archivi di dati.

Benché molte persone guardino a NoSQL per la semplicità, secondo Ibm è importante comprendere le implicazioni di tali archivi di dati durante la creazione dell’applicazione. Se è vero che sono facili da iniziare, è fondamentale comprendere le implicazioni della coerenza della scrittura (o della sua mancanza), l’eventuale consistenza e gli impatti dello sharding su come si prevede di accedere ai dati in futuro.

I database relazionali possono essere sistemi più semplici su cui creare un’applicazione affidabile, in quanto liberano da tali preoccupazioni.

NoSQL è interessante quando si hanno modelli di dati altamente flessibili o esigenze molto specifiche che non si adattano al modello relazionale. Se si acquisiscono molti dati non strutturati, un document database come MongoDB o CouchDB può essere una buona soluzione. Se si ha bisogno di un accesso molto rapido ai dati chiave-valore ma si può vivere senza forti garanzie di integrità, Redis è un’ottima scelta. Se è richiesta una ricerca complessa o flessibile su molti dati, Elasticsearch è un’ottima soluzione.

Gli archivi di dati NoSQL tendono a essere altamente scalabili e il ridimensionamento è un principio fondamentale di molti di questi sistemi. Lo sharding integrato rende il ridimensionamento di read e write molto più semplice rispetto a un database relazionale. A

llo stesso modo, i sistemi NoSQL possono spesso soddisfare requisiti di disponibilità molto elevata. Database come Cassandra non hanno singoli punti di errore e le applicazioni possono reagire ai failure sottostanti dei singoli membri in modo semplice.

Scegliere o raccomandare un database è un esercizio non banale, anche per gli esperti di database, conclude Ibm.

La suddivisione SQL vs NoSQL può essere utile per una decisione informata, ma, alla fine, non c’è nulla che può sostituirsi al pensare seriamente e approfonditamente alle esigenze di dati della propria applicazione e ai compromessi che si è disposti ad accettare per raggiungere gli obiettivi di performance o uptime.

Ibm Cloud stessa supporta versioni cloud-hosted di numerosi database sia SQL sia NoSQL, attraverso le offerte dei database Ibm Cloud.