Che tipi di database esistono

Lungo il percorso verso l'inventario, QUERY rallenta davanti a una sezione buia del deposito. Dietro il vetro c'è il registro degli archivi della vecchia Terra che non hanno superato la Grande Frattura: i nodi di cache si sono spenti per primi, gli archivi documentali sono arrivati in frammenti lacerati, i cluster analitici tacciono per interi settori. Lo snapshot relazionale di Kotomarket, invece, è sopravvissuto intatto, con tutti i suoi collegamenti.

Non solo relazionali

Per Kotomarket i database relazionali sono particolarmente adatti: clienti, ordini e prodotti si dispongono in modo naturale in tabelle collegate tra loro. È a loro che è dedicato il corso. Ma nell'industria, sia nel 2024 sia oggi, si incontrano anche altri approcci:

• chiave-valore (Redis) — un formato «chiave → valore» velocissimo, utile quando bisogna recuperare all'istante un record semplice;
• documentali (MongoDB) — conservano documenti JSON flessibili, in cui la struttura può cambiare da un record all'altro;
• colonnari (ClickHouse) — forti nell'analytics, quando serve calcolare rapidamente indicatori su enormi volumi di dati.

La maggior parte dei DBMS più diffusi nello sviluppo di prodotto resta relazionale: PostgreSQL, MySQL, Oracle, MS SQL. Se padroneggi SQL qui, potrai leggere i dati con sicurezza in aziende molto diverse tra loro.

QUERY: A ogni archivio il suo compito: uno punta sulla velocità, un altro sulla flessibilità, un terzo sull'analytics. Tu e io siamo stati fortunati: ci è capitato quello in cui tutto è collegato a tutto.

Not only relational

For Kotomarket, relational databases suit us especially well: buyers, orders, and products fall naturally into tables with links between them. That’s what this course is about. But across the industry — in 2024 just as today — you’ll meet other approaches too:

• key-value (Redis) — a blazingly fast "key → value" format for when you need to grab a simple record instantly;
• document-oriented (MongoDB) — stores flexible JSON documents whose structure can differ from record to record;
• columnar (ClickHouse) — strong at analytics, when you need to crunch metrics over enormous volumes of data fast.

Most of the popular DBMSs for product development stay relational: PostgreSQL, MySQL, Oracle, MS SQL. Master SQL here and you’ll be able to read data confidently at very different companies.

QUERY: Each archive has its own job: one prizes speed, another flexibility, a third analytics. You and I got lucky: we inherited the one where everything is connected to everything.

Il registro delle famiglie, messo in ordine

Il registro dietro il vetro è l'occasione giusta per esaminare davvero le famiglie di database: «che tipi di database esistono e quando sceglierli» è una delle domande da colloquio più frequenti. Passeremo in rassegna cinque famiglie, una dopo l'altra, sempre con lo stesso schema: modalità di archiviazione, punti di forza e di debolezza, prodotti e casi d'uso.

Database relazionali: schema rigido e collegamenti

Modo di archiviazione: righe in tabelle con uno schema dichiarato in anticipo. Ogni colonna ha un tipo, tra le tabelle esistono collegamenti tramite chiavi e il DBMS protegge l'integrità da sé: non si riesce a registrare un ordine per un cliente inesistente. Le modifiche vengono eseguite come transazioni con garanzie ACID: «ordine + decremento della giacenza» vengono scritti insieme, oppure non vengono scritti affatto.

• Punti di forza: SQL espressivo (filtri, join tra tabelle, aggregati), integrità a livello di database, transazioni.
• Punti deboli: lo schema va progettato in anticipo e migrato a ogni cambiamento; la scalabilità orizzontale su molti server è più complessa che per le famiglie NoSQL.
• Prodotti: PostgreSQL, MySQL/MariaDB, Microsoft SQL Server, Oracle, SQLite.
• Quando sceglierlo: utenti, ordini, denaro, magazzino: ovunque i dati siano collegati e un errore di scrittura sia inaccettabile. Per un nuovo prodotto è la scelta predefinita.

Database chiave-valore: un dizionario alla massima velocità

Modo di archiviazione: un unico, gigantesco dizionario «chiave → valore», quasi sempre tenuto in memoria. Niente tabelle, niente collegamenti: inserisci un valore con una chiave, lo recuperi con quella chiave in una frazione di millisecondo.

-- Questo non è SQL, sono comandi Redis
SET session:8f3a '{"user_id": 42}'
GET session:8f3a

• Punti di forza: velocità, semplicità, scalabilità facile.
• Punti deboli: si interroga solo tramite chiave esatta: la domanda «trova tutte le sessioni dei clienti di Mosca» non si può porre in questo formato; per il database il contenuto interno del valore è opaco.
• Prodotti: Redis, Memcached, Amazon DynamoDB.
• Quando sceglierlo: cache, sessioni, contatori, code, classifiche: dati usati di continuo accanto al database principale, non al suo posto.

Database documentali: JSON flessibile

Modo di archiviazione: i record sono documenti JSON raggruppati in collezioni. Lo schema non viene dichiarato in anticipo: uno smartwatch ha un campo «durata della batteria», una felpa ha una «tabella delle taglie», e i due documenti convivono senza problemi nella stessa collezione. Le strutture annidate vengono conservate direttamente dentro il documento, senza tabelle separate.

• Punti di forza: struttura flessibile, lettura dell'intero documento con un solo accesso, pratico per cataloghi con attributi eterogenei e prototipi rapidi.
• Punti deboli: i collegamenti tra documenti sono responsabilità dell'applicazione, e i JOIN veri e propri quasi non esistono; senza disciplina, una collezione diventa un miscuglio di formati incompatibili.
• Prodotti: MongoDB, Couchbase, Firestore.
• Quando sceglierlo: contenuti, cataloghi con campi molto diversi tra loro, profili e impostazioni.

Il confine tra le famiglie, tra l'altro, è sfumato: PostgreSQL sa conservare documenti in una colonna di tipo jsonb e costruirci sopra degli indici. Spesso basta questo per coprire un'esigenza «documentale» senza introdurre un secondo database:

-- Un esempio fuori dal nostro snapshot: attrs è una colonna di tipo jsonb
SELECT name, attrs->>'color' AS color
FROM catalog
WHERE attrs @> '{"brand": "Kotomarket"}';

Database colonnari: analytics su miliardi di righe

Modo di archiviazione: i valori non vengono conservati per riga, ma per colonna: tutti i prezzi vicini, tutte le date vicine. La query «scontrino medio per mese» legge dal disco solo due colonne invece dell'intera tabella, e valori dello stesso tipo si comprimono benissimo. Da qui arriva la velocità sugli aggregati.

-- Il genere preferito di un database colonnare (dialetto ClickHouse: toYYYYMM è una sua funzione)
SELECT toYYYYMM(created_at) AS month, avg(total_amount) AS avg_check
FROM orders
GROUP BY month;

• Punti di forza: aggregati e scansioni su miliardi di righe, compressione molto efficace.
• Punti deboli: aggiornamenti e cancellazioni puntuali sono costosi; leggere una singola riga per intero è più lento che in un database orientato alle righe; non sono pensati per carichi transazionali.
• Prodotti: ClickHouse, BigQuery, Snowflake, Amazon Redshift.
• Quando sceglierlo: analytics, report, eventi, log, metriche: di solito accanto al database relazionale «di produzione».

A questo punto compaiono due termini che piacciono molto ai colloqui: OLTP (online transaction processing — molte operazioni brevi di scrittura e lettura, il mondo di PostgreSQL) e OLAP (online analytical processing — letture analitiche pesanti su tutta la storia, il mondo di ClickHouse). Il prodotto scrive nel database OLTP, l'analytics legge dalla copia OLAP.

E l'ultima famiglia: i database a grafo

Quando i collegamenti contano più dei record stessi — «amici degli amici», percorsi di consegna, catene di raccomandazioni — si scelgono i database a grafo (Neo4j, Memgraph). Al loro interno i dati sono nodi (i record) e archi (i collegamenti tra i record); attraversare collegamenti a qualunque profondità è un'operazione nativa. In un database relazionale, lo stesso attraversamento diventa una scala di join tra tabelle, sempre più pesante man mano che aumenta la profondità.

Mini-guida: come scegliere il database per un progetto

1. Parti dalle domande, non dai dati. Quali query farà il prodotto: puntuali «per chiave», relazionali «chi ha comprato cosa», analitiche «quanto in un mese»?
2. Come scelta predefinita, relazionale. Quando i dati sono collegati e l'errore costa caro (ordini, pagamenti, giacenze), la risposta è PostgreSQL. È il punto di partenza più sicuro per quasi qualsiasi prodotto.
3. I database specializzati servono a un compito specifico, non come soluzione predefinita. Le letture più frequenti rallentano il sistema? Aggiungi una cache su Redis. L'analytics è cresciuta? Replica gli eventi in ClickHouse. I campi variano in modo estremo? Prima prova jsonb in PostgreSQL, e solo quando non basta più passa a un database documentale.
4. Considera il costo di un secondo database. Ogni nuovo DBMS significa sincronizzazione dei dati, backup, monitoraggio e una tecnologia in più da mantenere per il team.