L'etichetta «NoSQL» raccoglie database molto diversi tra loro, accomunati soprattutto da ciò che non sono: non organizzano i dati in tabelle relazionali con uno schema rigido. Parlarne come di un'unica tecnologia porta a confronti sbagliati del tipo «meglio SQL o NoSQL?». La domanda utile è un'altra: quale modello di dati rappresenta meglio il problema da risolvere e le domande che gli si faranno?
Database a documenti
Un database a documenti conserva record autonomi, di solito in un formato simile al JSON. Ogni documento può contenere campi annidati ed elenchi:
{
"_id": "ordine-1042",
"data": "2025-03-10",
"cliente": { "nome": "Anna Verdi", "citta": "Padova" },
"righe": [
{ "prodotto": "Lampada", "quantita": 1, "prezzo": 49.0 },
{ "prodotto": "Lampadina", "quantita": 3, "prezzo": 4.5 }
]
}
L'ordine con tutte le sue righe si legge e si scrive con un'unica operazione, senza JOIN. Lo schema è flessibile: due documenti della stessa raccolta possono avere campi diversi. MongoDB è l'esempio più noto, e anche database relazionali come PostgreSQL offrono tipi di colonna JSON indicizzabili.
Adatto a: cataloghi di prodotti con attributi molto variabili, contenuti di un CMS, profili utente, dati che si leggono sempre come un blocco unico.
Attenzione a: dati duplicati tra documenti. Se il nome del cliente è copiato in ogni ordine, cambiarlo richiede di aggiornare molti documenti. La flessibilità dello schema sposta inoltre i controlli nel codice applicativo: se nessuno li scrive, i dati diventano incoerenti.
Database chiave-valore
È il modello più semplice: a ogni chiave corrisponde un valore, e il database non si interessa di che cosa contenga il valore. Le operazioni sono essenzialmente «scrivi questa chiave», «leggi questa chiave», «cancella questa chiave». Redis è un esempio molto diffuso, che lavora principalmente in memoria e offre anche strutture come liste, insiemi e contatori.
Adatto a: cache dei risultati di query costose, sessioni utente, contatori, code di lavoro, limiti al numero di richieste.
Attenzione a: non si possono fare ricerche sul contenuto dei valori. Se serve «tutti gli utenti di Padova», un archivio chiave-valore puro non aiuta. Se i dati stanno solo in memoria, va capito come e quanto spesso vengono salvati su disco.
Database a colonne larghe
I database a colonne larghe, come Apache Cassandra, organizzano i dati in righe identificate da una chiave di partizione, distribuite su molti server. Sono progettati per volumi di scrittura molto elevati e per restare disponibili anche quando alcuni nodi non rispondono.
La modellazione segue una logica opposta a quella relazionale: si parte dalle query che si eseguiranno e si costruisce una tabella per ciascuna, accettando di duplicare i dati. La chiave di partizione decide su quale server vanno i dati, quindi va scelta in modo che il carico si distribuisca in modo uniforme.
Adatto a: dati di sensori, registri di eventi, serie temporali su grande scala, cronologie di attività.
Attenzione a: query non previste in fase di progettazione sono difficili o impossibili da eseguire in modo efficiente. Non si fanno JOIN.
Da non confondere con i database colonnari usati per l'analisi, che memorizzano i dati colonna per colonna per velocizzare aggregazioni su grandi tabelle: è un concetto diverso, nonostante il nome simile.
Database a grafo
Un database a grafo memorizza nodi (persone, prodotti, luoghi) e relazioni tra nodi (conosce, ha comprato, si trova in), entrambi con proprietà. Neo4j è uno dei più noti. Il punto di forza è attraversare le relazioni: «gli amici degli amici di Anna che hanno comprato lo stesso prodotto» è una query naturale, mentre in un database relazionale richiederebbe molte JOIN annidate e diventerebbe lenta a ogni livello aggiuntivo.
Adatto a: reti sociali, sistemi di raccomandazione, dipendenze tra componenti, analisi di reti e percorsi, individuazione di schemi sospetti nelle transazioni.
Attenzione a: per dati che non sono davvero una rete, il modello non porta vantaggi e gli strumenti di analisi tradizionali sono meno maturi.
Un confronto rapido
| Famiglia | Unità di dati | Punto di forza | Limite tipico |
|---|---|---|---|
| Documenti | Documento JSON | Schema flessibile, lettura in blocco | Duplicazioni, coerenza a carico del codice |
| Chiave-valore | Coppia chiave/valore | Velocità e semplicità | Nessuna ricerca sul contenuto |
| Colonne larghe | Riga in una partizione | Scritture su grande scala | Query da prevedere in anticipo |
| Grafo | Nodi e relazioni | Attraversare collegamenti | Poco utile per dati non a rete |
Quando il relazionale resta la scelta migliore
Per la gestione di ordini, fatture, anagrafiche e magazzino, cioè dati molto collegati tra loro, con regole di coerenza e domande che cambiano nel tempo, un database relazionale resta di solito la scelta più solida. Offre vincoli, transazioni su più tabelle e la possibilità di fare domande che nessuno aveva previsto. Molti sistemi reali combinano più modelli: un database relazionale come archivio principale, un archivio chiave-valore come cache, un motore di ricerca per la ricerca testuale.
In sintesi
- «NoSQL» indica famiglie diverse, non una singola tecnologia.
- I database a documenti sono flessibili ma spostano la coerenza nel codice.
- I chiave-valore sono velocissimi ma non permettono ricerche sul contenuto.
- Le colonne larghe reggono enormi volumi di scrittura se le query sono note in anticipo.
- I grafi eccellono nelle relazioni; per dati gestionali il relazionale resta spesso la scelta migliore.
