Quando un’applicazione deve gestire cataloghi che cambiano spesso, milioni di eventi o relazioni molto fitte tra utenti e contenuti, il modello relazionale non è sempre la scelta più pratica. Un database NoSQL può offrire maggiore flessibilità e scalabilità, ma solo se il formato dei dati e il carico di lavoro sono compatibili con il motore scelto. Qui chiarisco come funzionano queste basi di dati, quali modelli esistono, come confrontarle con SQL e quali errori evitare.
La scelta dipende dal modo in cui utilizzi i dati
- Documenti JSON per contenuti flessibili e applicazioni con schema variabile.
- Chiave-valore per accessi rapidissimi, cache e sessioni.
- Wide-column per grandi volumi distribuiti e serie temporali.
- Grafi per analizzare relazioni complesse tra persone, prodotti o eventi.
- Scalabilità e velocità possono richiedere compromessi sulla consistenza immediata.
Cosa indica davvero una base di dati NoSQL
Con l’espressione database NoSQL si indicano sistemi che non dipendono necessariamente da tabelle rigide, righe e relazioni definite in anticipo. Il termine non significa “senza SQL” in senso assoluto. Molti prodotti moderni supportano linguaggi simili a SQL o consentono interrogazioni strutturate, pur utilizzando un modello di archiviazione diverso.
La differenza principale riguarda il modo in cui i dati vengono organizzati. Invece di progettare prima uno schema immutabile, si parte spesso dalle letture e scritture più frequenti dell’applicazione. Questo approccio è utile quando i dati cambiano rapidamente, arrivano da fonti diverse o devono essere distribuiti su più server.
La flessibilità, però, non è gratuita. Un modello meno rigido può rendere più semplice lo sviluppo iniziale, ma aumenta il rischio di dati incoerenti, duplicati o difficili da analizzare. La mia regola pratica è semplice: scegliere NoSQL per un’esigenza precisa, non soltanto perché l’applicazione gestisce molti dati.
Quattro modelli per quattro problemi diversi
NoSQL non è un singolo tipo di tecnologia. Comprende famiglie molto diverse, ottimizzate per operazioni specifiche. Confonderle è uno degli errori più comuni, perché una soluzione eccellente per una cache può essere inadatta per la reportistica o per le relazioni tra clienti.
| Modello | Come salva i dati | Uso tipico | Esempi |
|---|---|---|---|
| Documentale | Documenti JSON o BSON, spesso annidati | Cataloghi, profili, contenuti, applicazioni web | MongoDB, Couchbase |
| Chiave-valore | Una chiave associata a un valore | Cache, sessioni, carrelli, configurazioni | Redis, Amazon DynamoDB |
| Wide-column | Colonne organizzate per famiglie e partizioni | Eventi, log, dati distribuiti e serie temporali | Apache Cassandra, ScyllaDB |
| A grafo | Nodi collegati da relazioni con proprietà | Raccomandazioni, frodi, reti, dipendenze | Neo4j, Amazon Neptune |
Database documentali
Un documento può contenere campi semplici, array e strutture annidate. Un prodotto, per esempio, può includere prezzo, varianti, immagini e caratteristiche tecniche nello stesso oggetto. Questo riduce la necessità di molti join e si adatta bene a un catalogo in cui ogni articolo ha attributi differenti.
Il formato JSON è leggibile anche dagli sviluppatori e si integra facilmente con API web. Il limite emerge quando bisogna eseguire molte analisi trasversali o mantenere coerenza rigorosa tra numerosi documenti. In quei casi occorre progettare con attenzione gli indici e valutare se il modello relazionale sia più adatto.
Database chiave-valore
Qui l’accesso parte da una chiave univoca, come sessione_7842, e recupera il valore associato. Il modello è volutamente essenziale e offre tempi di risposta molto bassi, soprattutto per dati temporanei o consultati di frequente.
Non lo userei come archivio principale per report complessi. È invece una scelta efficace per cache, token, preferenze utente e carrelli online, a condizione di definire una politica di scadenza e di gestire correttamente la perdita dei dati temporanei.
Database wide-column
I sistemi a colonne larghe sono pensati per distribuire grandi quantità di dati su più nodi. Funzionano bene quando le query sono conosciute in anticipo, per esempio “mostra tutti gli eventi del dispositivo X nell’intervallo di tempo Y”.
Il vantaggio è la capacità di sostenere scritture elevate e crescita orizzontale. Il rovescio della medaglia è una progettazione meno intuitiva: spesso si creano tabelle o viste diverse per soddisfare query diverse, invece di costruire un unico schema universale.
Database a grafo
Un grafo rappresenta entità e collegamenti in modo diretto. È particolarmente utile quando il valore dell’informazione sta nella relazione, come accade per reti sociali, motori di raccomandazione, indagini antifrode e dipendenze tra componenti software.
Per una semplice anagrafica clienti sarebbe probabilmente una scelta eccessiva. Quando invece bisogna attraversare molti livelli di connessioni, il modello a grafo può rendere la query più naturale e più leggibile rispetto a una lunga sequenza di join.
Formati dei dati e progettazione delle query
Il formato più comune nei sistemi documentali è JSON, mentre alcuni motori utilizzano rappresentazioni binarie come BSON per migliorare la gestione interna. Nei sistemi chiave-valore, il valore può essere una stringa, un numero, un JSON, una lista o anche un oggetto serializzato.
La scelta del formato deve seguire il modo in cui il dato verrà letto. Se una schermata mostra sempre prodotto, prezzo e disponibilità insieme, può avere senso conservarli nello stesso documento. Se invece lo stesso prezzo viene aggiornato e consultato da decine di processi indipendenti, separarlo può evitare duplicazioni difficili da sincronizzare.
Denormalizzare con criterio
Nei database NoSQL è frequente la denormalizzazione, cioè la duplicazione controllata di alcune informazioni per ridurre i join. È una tecnica utile, ma ogni copia introduce un obbligo di aggiornamento.
Immaginiamo un ordine che conserva anche il nome e l’indirizzo del cliente al momento dell’acquisto. Se il cliente modifica oggi il proprio indirizzo, l’ordine storico non deve cambiare. In questo caso la duplicazione non è un difetto, ma una scelta corretta per preservare il significato del dato.
Leggi anche: Pivot SQL - trasformare righe in colonne nei report
Gli indici non risolvono tutto
Un indice accelera le ricerche su determinati campi, ma occupa spazio e rallenta le scritture. Crearne molti “per sicurezza” porta spesso a costi più alti e prestazioni peggiori.
Prima di aggiungere un indice, elenco le query realmente usate dall’applicazione e controllo frequenza, cardinalità e dimensione dei risultati. Una query che restituisce migliaia di documenti resterà lenta anche con un indice ben costruito.
NoSQL o relazionale, quale scelta ha senso
Il confronto non dovrebbe essere una gara tra tecnologie. Un database relazionale rimane spesso preferibile quando servono transazioni articolate, vincoli rigorosi, report multidimensionali e relazioni stabili tra molte entità.
Una soluzione NoSQL è più interessante quando il carico richiede distribuzione orizzontale, schema flessibile o letture estremamente rapide su strutture già aggregate. In molti progetti la soluzione migliore è poliglotta, cioè utilizza più motori, ognuno per il problema che sa risolvere meglio.
| Criterio | Relazionale | NoSQL |
|---|---|---|
| Schema | Definito e controllato in anticipo | Flessibile o dipendente dal modello |
| Relazioni | Gestite con chiavi e join | Gestite con annidamento, duplicazione o collegamenti |
| Transazioni | Molto mature per operazioni complesse | Disponibili, ma con capacità diverse tra i prodotti |
| Scalabilità | Tradizionalmente verticale, oggi anche distribuita | Spesso progettata per la distribuzione orizzontale |
| Analisi | Forte su join, aggregazioni e BI | Dipende dal motore e dal modello adottato |
Dire che NoSQL è sempre più veloce è una semplificazione. Può esserlo per il suo caso d’uso, ma una query non prevista dal modello può diventare costosa o impraticabile. Ho visto più di un progetto scegliere una base documentale per poi ricostruire al suo interno, con grande fatica, comportamenti tipici di un database relazionale.
Prestazioni, consistenza e costi da valutare
Nei sistemi distribuiti bisogna decidere come bilanciare disponibilità, tolleranza ai guasti e consistenza. La consistenza eventuale permette a nodi diversi di allinearsi dopo un breve intervallo, mentre la consistenza forte punta a restituire subito il dato più aggiornato.
Per un contatore di visualizzazioni può essere accettabile un piccolo ritardo. Per il saldo di un conto, la disponibilità di un farmaco o la conferma di un pagamento, la priorità è diversa. La scelta deve nascere dal rischio concreto di leggere un dato temporaneamente non aggiornato, non da una preferenza astratta del team tecnico.
Anche i costi richiedono attenzione. Nei servizi gestiti, la fattura può dipendere da storage, letture, scritture, traffico e capacità riservata. Una base apparentemente economica può diventare costosa se il modello obbliga a leggere grandi documenti o a duplicare eccessivamente i dati.
Per stimare il budget, misurerei almeno quattro elementi: volume iniziale, crescita mensile, numero medio e massimo di operazioni al secondo, dimensione delle risposte. Senza queste misure, confrontare i prezzi dei prodotti ha poco valore.
Un percorso pratico per scegliere senza sbagliare
La scelta può diventare molto più semplice seguendo una sequenza concreta. Non serve partire dal marchio del prodotto, ma dalle operazioni che il sistema dovrà sostenere ogni giorno.
- Descrivi le query principali. Scrivi le 5-10 operazioni più frequenti e indica quali dati devono restituire.
- Misura il carico. Stima letture, scritture, picchi, dimensione dei record e crescita prevista.
- Scegli il modello. Documenti, chiave-valore, colonne larghe o grafi devono riflettere il tipo di accesso.
- Definisci la consistenza. Separa i dati critici da quelli in cui un ritardo di pochi secondi è accettabile.
- Prova con dati realistici. Un test con pochi record nasconde problemi di partizionamento, indici e memoria.
- Prepara migrazione e backup. Verifica esportazione, ripristino, monitoraggio e possibilità di cambiare versione o fornitore.
Il partizionamento merita un test specifico. Una chiave mal scelta può concentrare tutto il traffico su un solo nodo, creando un hot spot, cioè una porzione sovraccarica dell’archivio. In questi casi la distribuzione teorica del sistema non corrisponde alle prestazioni reali.
Prima del rilascio controllerei anche la qualità dello schema, la gestione degli errori, la durata delle cache e il comportamento durante il riavvio di un nodo. La velocità misurata in condizioni ideali conta meno della stabilità osservata nei momenti di picco.
La decisione migliore parte dal dato, non dal nome della tecnologia
Le basi NoSQL sono preziose quando il modello dei dati è flessibile, il carico è distribuito o l’applicazione richiede accessi molto rapidi. Non sostituiscono automaticamente SQL e non eliminano la necessità di progettare schema, indici, transazioni e procedure di recupero.
Per orientarmi, parto sempre da una domanda concreta: quale operazione deve funzionare meglio delle altre? Se la risposta riguarda documenti dinamici, relazioni profonde, accessi per chiave o grandi flussi di eventi, il modello giusto diventa più evidente e la scelta del prodotto può essere verificata con un test realistico.
La tecnologia più adatta non è quella con la reputazione migliore, ma quella che mantiene prestazioni, consistenza e costi sotto controllo nel caso d’uso reale. È questo equilibrio, più dell’etichetta NoSQL, a determinare la qualità dell’architettura dati.
