Il mondo della gestione dei dati è in continua evoluzione. Se per decenni i database relazionali hanno dominato la scena, l'avvento di nuove esigenze, dettate soprattutto dall'esplosione di Internet, dei social network e dell'e-commerce, ha portato alla nascita e alla diffusione di soluzioni alternative: i database NOSql. Ma cosa sono esattamente e perché sono diventati così importanti?

Per comprendere l'impatto dei database NOSql, facciamo un passo indietro. In origine, tra la fine degli anni '50 e gli anni '60, i database si basavano su modelli di tipo fisico, come i database gerarchici (caratterizzati da strutture ad albero) e reticolari (caratterizzati da strutture a grafo).

Il problema principale era la necessità di accedere e manipolare direttamente le strutture fisiche di memorizzazione, con conseguente complessità e forte dipendenza dalla specifica soluzione adottata. Era un po' come programmare in linguaggio macchina.

La vera svolta arrivò negli anni '70 con l'introduzione del modello relazionale che introdusse due novità fondamentali: un modello basato sui valori, che permetteva di interagire con i dati senza doversi preoccupare dell'organizzazione fisica sottostante e l'introduzione del concetto di relazione, ripreso dalla matematica.

I dati venivano strutturati in tabelle, un concetto intuitivo basato su righe (set di dati) e colonne (attributi).

Per interagire con questi database nacque il linguaggio SQL che consentiva non solo il recupero, l'inserimento e la modifica dei dati, ma anche la manipolazione della struttura delle tabelle, garantendo indipendenza dalla conoscenza dell'organizzazione fisica dei dati.

Per molto tempo il modello relazionale e SQL hanno rappresentato la soluzione ottimale di riferimento per la gestione dei dati, anche in contesti critici come quello finanziario/assicurativo.

Agli inizi degli anni 2000 l'enorme crescita di piattaforme come social network (Facebook, LinkedIn, Twitter, Instagram) ed e-commerce ha evidenziato alcuni limiti del modello relazionale che hanno hanno spinto lo sviluppo dei database NOSql.

È importante chiarire subito che il termine NOSql non significa "senza SQL" o una contrapposizione esclusiva al modello relazionale, ma piuttosto "Not Only SQL".

Ovvero si tratta di soluzioni che si affiancano al modello relazionale e infatti ancora oggi i due modelli coesistono e collaborano in contesti complessi.

Quali sono eattamente i limiti del relazionale che il NOSql cerca di superare?

1. Schema rigido: nel modello relazionale lo schema della tabella è statico e deve essere definito in fase di progettazione. Questo può creare problemi con dati variabili (compresa la gestione dei valori nulli) e rende difficile l'adattamento a frequenti cambiamenti nella struttura degli stessi

2. Gestione di vari formati: inizialmente i database relazionali supportavano principalmente tipi di dato semplici come stringhe e valori numerici. Le applicazioni moderne richiedono la gestione di documenti JSON o dati binari (anche se per questi ultimi è spesso consigliato uno storage esterno con riferimenti nel DB)

3. Scalabilità: l'esplosione di Internet ha generato una enorme quantità di dati, un volume impensabile fino a qualche decennio prima. La scalabilità dei database relazionali è tradizionalmente di tipo verticale, cosa che implica il potenziamento di un singolo server per migliorare le prestazioni. Questo può diventare costoso o limitato.

I database NOSql nascono per affrontare queste sfide:

1. Schema flessibile: consentono appunto schemi flessibili o addirittura la possibilità di salvare dati con strutture diverse per ogni singolo inserimento. I dati possono essere strutturati, semi-strutturati o non strutturati

2. Supporto per dati diversi: sono progettati per gestire facilmente diverse tipologie di dati (inclusi documenti, audio, immagini e persino video)

3. Scalabilità orizzontale nativa: a differenza dei db relazionali, i NOSql supportano nativamente la scalabilità orizzontale. Questo significa poter distribuire il carico su più server che lavorano in parallelo, adattandosi meglio a situazioni con un'enorme quantità di richieste.

Un altro aspetto fondamentale dei NOSql è che non esiste un unico modello di riferimento come avviene con le tabelle nel relazionale. Nel mondo NOSql esistono diverse tipologie con caratteristiche specifiche, ciascuna adatta a determinati contesti d'uso (use case).

Una possibile classificazione include:

1. Database orientati ai documenti: salvano i dati sotto forma di documenti, spesso in formato JSON e rappresentano una sorta di "lingua franca" nell'ambito delle API. Esempi noti sono CouchDB e MongoDB

2. Database a grafo: progettati per rappresentare e gestire relazioni complesse tra oggetti. Sono estremamente utili in contesti come i social network, dove è necessario modellare le connessioni tra utenti e amici. Un esempio è Neo4j

3. Database chiave-valore (key-value): archiviano i dati come coppie "chiave-valore", dove la chiave identifica in modo univoco il dato. Sono spesso usati per la gestione del caching, permettendo un recupero molto rapido dei dati. Redis è un esempio molto diffuso, noto anche per essere un database in-memory (salva i dati nella RAM)

4. Database orientati alle colonne: archiviano i dati per colonne anziché per righe e questo li rende molto efficienti per la lettura e l'analisi di grosse quantità di dati (es. data mining), piuttosto che per l'estrazione di singoli record. Cassandra è un prodotto appartenente a questa categoria.

Una differenza cruciale tra database relazionali e NOSql riguarda le proprietà garantite. I database relazionali garantiscono le proprietà ACID (Atomicità, Consistenza, Isolamento, Durabilità). Nei NOSql, per mantenere la flessibilità e la scalabilità, non tutte queste proprietà possono essere garantite.

Essenzialmente molti database NOSql si basano sull'idea di garantire la disponibilità ovvero il server deve essere sempre in grado di rispondere alle richieste.

In sistemi distribuiti, come spesso sono i database NOSql, questo può significare che la disponibilità ha una priorità rispetto alla coerenza (come accennato dal teorema CAP). Due server potrebbero momentaneamente avere dati non allineati, ma la priorità è rispondere. Se invece la coerenza dei dati è fondamentale e non si possono avere dati disallineati, allora una soluzione relazionale potrebbe essere necessaria.

Nella pratica, come già detto, le due soluzioni spesso coesistono all'interno della stessa applicazione, con database diversi utilizzati per compiti specifici.

Dal punto di vista delle prestazioni i database relazionali beneficiano di strumenti come gli indici per velocizzare il recupero dei dati e tecniche di ottimizzazione delle query. Tuttavia, operazioni come i Join (necessari per riaggregare i dati spezzettati dalla normalizzazione) possono essere molto pesanti. Talvolta si ricorre alla denormalizzazione per migliorare le performance, accettando però problemi di ridondanza e sincronizzazione.

I NoSQL, nascendo per funzionare in ambienti distribuiti (cluster), possono offrire prestazioni migliori in situazioni di carico molto elevato, distribuendo il lavoro su più server.

Per concludere possiamo dire che il modello relazionale, con la sua solidità e garanzie ACID, rimane una scelta valida e necessaria per molte applicazioni, specialmente quelle che richiedono elevata coerenza e integrità dei dati.

Al contrario per gestire l'enorme volume, la varietà e la velocità dei dati generati dalle applicazioni moderne, i database NOSql offrono soluzioni flessibili e scalabili orizzontalmente, con modelli specifici ottimizzati per diverse esigenze.

Comprendere le differenze e i punti di forza di ciascun approccio è fondamentale per scegliere lo strumento giusto per il lavoro, spesso combinando soluzioni relazionali e NOSql in architetture ibride per sfruttare il meglio di entrambi i mondi.

[VIDEO YOUTUBE]

[PODCAST]