Database relazionali e non relazionali: differenze ed esempi pratici

Due modi di organizzare i dati

Un database relazionale parte da uno schema deciso in anticipo: tabelle con colonne fisse, uguali per ogni riga, collegate da chiavi primarie ed esterne. Un database non relazionale, o NoSQL, parte invece dal problema da risolvere: sceglie un modello di dati specifico, documenti, coppie chiave-valore, colonne partizionate o grafi, e adatta lo schema a quel modello. Secondo AWS, i database NoSQL sono spesso descritti come database “purpose-built”, pensati cioè per uno scopo preciso, con schemi flessibili che si adattano più facilmente delle tabelle relazionali alle applicazioni moderne.

Non è un confronto tra un modello superato e uno nuovo: nessuno dei due sostituisce l’altro in ogni caso. È piuttosto una scelta che dipende dalla forma dei dati, da quanto serve scalare e da quanta rigidità di struttura conviene avere fin dall’inizio.

I quattro modelli principali del mondo NoSQL

AWS descrive tre di questi modelli con un prodotto reale a testa. Il database documentale archivia i dati come documenti simili a oggetti JSON, flessibili e semi-strutturati; MongoDB è un esempio noto di questo modello. Il database chiave-valore associa ogni valore a una chiave ed è, secondo AWS, altamente partizionabile, capace di scalare orizzontalmente a un livello che altri tipi di NoSQL non raggiungono facilmente: Amazon DynamoDB, per esempio, punta a offrire prestazioni costanti con latenze di pochi millisecondi a qualunque scala di traffico. Il database a grafo, come Neo4j, è pensato per applicazioni che lavorano con dati fortemente connessi tra loro. Un quarto modello molto diffuso è quello a colonne larghe, che partiziona le tabelle secondo una chiave di partizione: ne è un esempio Apache Cassandra.

Esempio pratico: in un database a grafo, una domanda come “che musica ascoltano i miei amici che io non ho ancora?” si risolve con una traversal, la query che attraversa nodi e relazioni per trovare la risposta. In una tabella relazionale la stessa domanda richiederebbe più join tra tabelle diverse; nel grafo, amici, ascolti e brani sono già nodi collegati da relazioni dirette.

Uno schema flessibile, non un’assenza di schema

Nel modello documentale, ogni documento contiene coppie di campo e valore, e i valori possono essere stringhe, numeri, valori booleani, array o anche altri documenti annidati. Documenti diversi nella stessa raccolta possono avere campi diversi tra loro: è più facile cambiare lo schema, se serve, proprio per questa flessibilità. Nel modello relazionale, al contrario, lo schema è fisso: ogni riga di una tabella deve contenere gli stessi tipi di colonna predefiniti, e cambiare lo schema dopo che i dati sono già stati inseriti è più complicato.

Redis, un database chiave-valore, mostra bene che “chiave-valore” non vuol dire solo stringhe semplici: oltre alle stringhe, implementa hash, che funzionano come dizionari a coppie campo-valore, insiemi non ordinati di stringhe uniche, e liste ordinate per inserimento. Un insieme in Redis permette di aggiungere, rimuovere e verificare l’esistenza di un elemento in tempo costante, indipendentemente da quanti elementi contiene.

Scalabilità, verticale e orizzontale

La scalabilità verticale cresce aumentando le risorse di una singola macchina, più memoria, più processore. La scalabilità orizzontale cresce aggiungendo altre macchine, spesso raggruppate in cluster distribuiti su più server, che possono anche trovarsi in luoghi diversi e comunicare attraverso Internet. Secondo MongoDB, i database relazionali sono progettati soprattutto per la scalabilità verticale, con una capacità limitata di estendersi anche in orizzontale; i database NoSQL, invece, sono pensati per scalare sia verticalmente sia orizzontalmente, spesso tramite sharding, replica e clustering.

Apache Cassandra, un database a colonne larghe, è un esempio concreto di questa filosofia: i suoi obiettivi di progettazione includono lo scaling su hardware comune, con un throughput che cresce in modo lineare a ogni processore aggiunto, e il bilanciamento del carico durante la crescita del cluster.

Il teorema CAP, un compromesso non un’etichetta fissa

Il teorema CAP descrive i compromessi che un database distribuito affronta tra consistenza, disponibilità e tolleranza di partizione, quando i dati sono replicati su più nodi. Poiché la tolleranza di partizione è un requisito in un ambiente distribuito, secondo MongoDB la vera scelta ricade tra mantenere la consistenza o la disponibilità nel momento in cui la comunicazione tra i nodi si interrompe.

Non è una scelta permanente stampata addosso a un sistema, ma un compromesso che si attiva quando serve. MongoDB, per esempio, offre impostazioni regolabili, come writeConcern e readPreference, che permettono di bilanciare accuratezza, velocità e resilienza: può comportarsi come sistema più orientato alla consistenza o come sistema più orientato alla disponibilità, a seconda della configurazione. Apache Cassandra, dal canto suo, implementa quella che la sua documentazione chiama “consistenza eventuale”: i nodi del cluster si allineano sugli stessi dati nel tempo, non necessariamente subito dopo ogni scrittura.

Quando conviene un modello o l’altro

Secondo MongoDB, chi deve scegliere tra un database relazionale e uno NoSQL guarda in genere a fattori come lo sviluppo Agile a ritmo veloce, la necessità di archiviare dati strutturati insieme a dati semi-strutturati, grandi volumi di dati, requisiti di architettura scale-out, o paradigmi applicativi moderni come i microservizi e lo streaming in tempo reale. Un catalogo prodotti con relazioni ben definite tra clienti, ordini e fatture resta un caso naturale per un database relazionale. Un sistema di raccomandazioni che lavora su reti di connessioni, o un servizio che deve incassare picchi di traffico imprevedibili con un algoritmo di lettura rapidissimo, si sposta più facilmente verso un modello NoSQL, documentale, a grafo o chiave-valore a seconda del problema.

La scelta resta legata al problema da risolvere: come sono fatti i dati, quanto la loro struttura può cambiare nel tempo, e come deve crescere il sistema che li ospita.