Database NoSQL

Cosa sono i database NoSQL

NoSQL (Not Only SQL) è la famiglia di sistemi che non segue il modello relazionale. Sono nati per applicazioni web con numeri enormi (social network, grandi negozi online, sensori) e la logica è uno scambio: si rinuncia a qualche garanzia dei database relazionali, per esempio alle transazioni ACID complete, e si guadagna la possibilità di crescere aggiungendo macchine, uno schema che si può cambiare senza migrazioni e prestazioni molto alte su operazioni semplici.

«NoSQL sta per "not only SQL", e la sigla dice tutto: nella maggior parte delle applicazioni che ho visto reggere, i due mondi convivono.»

Document Database

I document database memorizzano i dati come documenti (tipicamente JSON o BSON), ciascuno con una struttura potenzialmente diversa. Il più diffuso è MongoDB.

// Documento MongoDB - collezione "studenti"
{
    "_id": ObjectId("64a7b2c3d4e5f6a7b8c9d0e1"),
    "nome": "Marco",
    "cognome": "Rossi",
    "email": "marco.rossi@uni.it",
    "esami": [
        { "materia": "Analisi I", "voto": 28, "data": "2025-06-15" },
        { "materia": "Programmazione", "voto": 30, "data": "2025-07-10" }
    ],
    "indirizzo": {
        "via": "Via Roma 1",
        "citta": "Milano",
        "cap": "20100"
    }
}

Vantaggi: struttura annidata naturale, nessuna JOIN necessaria (i dati correlati sono incorporati nel documento), schema flessibile. Ideale per: CMS, cataloghi prodotti, profili utente, applicazioni con strutture dati eterogenee.

Key-Value Store

I key-value store sono i database NoSQL più semplici: ogni dato è associato a una chiave univoca. Redis è il più popolare, offrendo strutture dati in memoria (stringhe, liste, set, hash) con latenza sub-millisecondo.

# Redis - operazioni base
SET sessione:user123 '{"nome":"Marco","ruolo":"admin"}' EX 3600
GET sessione:user123

# Contatore visite
INCR pagina:/home/visite

# Lista ultimi articoli
LPUSH articoli:recenti "articolo:456"
LTRIM articoli:recenti 0 9

Ideale per: caching, sessioni utente, code di messaggi, classifiche in tempo reale, rate limiting. Redis è spesso usato come complemento a un database primario (SQL o document).

Column-Family

I database column-family (o wide-column) organizzano i dati in famiglie di colonne, ottimizzando le letture su grandi dataset distribuiti. Apache Cassandra è il riferimento principale, progettato per gestire petabyte di dati su cluster di centinaia di nodi.

-- Cassandra CQL (Cassandra Query Language)
CREATE TABLE metriche_sensori (
    sensore_id UUID,
    timestamp TIMESTAMP,
    temperatura FLOAT,
    umidita FLOAT,
    PRIMARY KEY (sensore_id, timestamp)
) WITH CLUSTERING ORDER BY (timestamp DESC);

INSERT INTO metriche_sensori (sensore_id, timestamp, temperatura, umidita)
VALUES (uuid(), toTimestamp(now()), 22.5, 65.3);

Ideale per: dati time-series (IoT, log, metriche), sistemi con scritture massicce e distribuzione geografica.

Graph Database

I database a grafo tengono i dati come nodi (le cose) e archi (i legami fra le cose), e diventano imbattibili quando le domande attraversano molte relazioni: «gli amici degli amici che hanno comprato questo». Neo4j si interroga con il linguaggio Cypher:

// Neo4j Cypher - creare nodi e relazioni
CREATE (m:Studente {nome: "Marco", corso: "Informatica"})
CREATE (a:Studente {nome: "Anna", corso: "Informatica"})
CREATE (p:Professore {nome: "Prof. Bianchi"})
CREATE (e:Esame {materia: "Database", crediti: 9})

CREATE (m)-[:STUDIA]->(e)
CREATE (a)-[:STUDIA]->(e)
CREATE (p)-[:INSEGNA]->(e)

// Query: chi studia con Marco?
MATCH (m:Studente {nome: "Marco"})-[:STUDIA]->(e)<-[:STUDIA]-(colleghi)
RETURN colleghi.nome

Ideale per: social network, motori di raccomandazione, analisi delle frodi, knowledge graph, gestione delle dipendenze.

Il CAP Theorem

Il teorema CAP (Brewer, 2000) dice che un sistema distribuito può garantire al massimo due proprietà su tre:

In pratica, poiché le partizioni di rete sono inevitabili nei sistemi distribuiti, la scelta reale è tra CP (consistenza + tolleranza, es. MongoDB con write concern majority) e AP (disponibilità + tolleranza, es. Cassandra con eventual consistency). La domanda concreta da porsi è: per la tua applicazione è più grave mostrare un dato leggermente disallineato oppure rifiutare temporaneamente la richiesta? Un sistema bancario sceglierà la consistenza (meglio bloccare un'operazione che mostrare un saldo errato), mentre un feed social o un carrello e-commerce privilegiano la disponibilità (meglio rispondere subito, allineando i dati poco dopo). Capire questo compromesso evita di scegliere il database "di moda" e impone invece una scelta guidata dai requisiti reali del progetto.

Schema-less e flessibilità

A differenza dei database relazionali che richiedono uno schema rigido definito con DDL, i database NoSQL sono generalmente schema-less (o schema-on-read): la struttura dei dati non è imposta al momento della scrittura.

La flessibilità dello schema è un grande vantaggio in fase di sviluppo: puoi aggiungere un nuovo campo a un documento senza migrare l'intera tabella, accelerando la prototipazione e l'evoluzione del prodotto. Il rovescio della medaglia è che il "debito di struttura" si sposta nel codice: senza una validazione disciplinata, dopo qualche mese ti ritrovi documenti con campi scritti in modi diversi (email, Email, e_mail) o tipi incoerenti, rendendo le query fragili. La buona pratica è definire comunque uno schema esplicito a livello applicativo e versionare i documenti con un campo come schema_version, così da poter gestire in modo ordinato le evoluzioni nel tempo.

Scalabilità

La differenza che conta è nel modo di crescere:

• Scalabilità verticale (scale-up): aggiungere CPU, RAM, storage al singolo server. Tipica dei database SQL.
• Scalabilità orizzontale (scale-out): aggiungere nuovi nodi al cluster, distribuendo i dati tramite sharding. Tipica dei database NoSQL.

Lo sharding suddivide i dati tra più server in base a una chiave di partizione (shard key). La scelta della shard key è critica: una distribuzione non uniforme genera hotspot che annullano i vantaggi della distribuzione.

Quando SQL vs NoSQL

Nelle architetture di oggi si usa spesso la polyglot persistence: database diversi per esigenze diverse nella stessa applicazione, per esempio il relazionale per gli ordini e un archivio chiave-valore per le sessioni. Su come i dati arrivano dal database all'applicazione c'è la guida su API e web service.