Un database, due carichi di lavoro, molti problemi: OLTP vs OLAP P. 1

Per le transazioni in tempo reale, serve sistema di tipo OLTP (Online Transaction Processing). Per l’analisi, invece, serve un sistema diverso: OLAP (Online Analytical Processing). L’OLTP è come Sonic the Hedgehog: sempre in movimento, corre a tutta velocità, reagisce istantaneamente agli ostacoli e raccoglie anelli lungo il percorso. L’OLTP elabora ogni transazione rapidamente e in modo prevedibile. L’OLAP, invece, è più come Kirby: inghiotte tutto ciò che incontra sul suo cammino: oggetti, nemici, interi mondi. I sistemi OLAP assorbono volumi massicci di dati – milioni e miliardi di righe – per poi “digerirli” e trasformarli in informazioni utili, come un report.

E dato che i casi d’uso sono così diversi, è logico che anche l’architettura dei server, i sistemi di storage e persino i motori di database siano differenti.

Ed è proprio qui che arriviamo al punto centrale. In questo approfondimento parleremo di OLAP, OLTP e dell’hardware che li supporta.

OLAP e OLTP: cosa sono e perché esistono

Scaviamo un po’ più a fondo nella tecnologia.

OLAP e OLTP hanno obiettivi e architetture completamente diversi. Ecco perché, per la maggior parte delle aziende, la vera domanda non è scegliere tra l’uno o l’altro, ma capire come combinarli correttamente all’interno di un’unica infrastruttura.

L’OLAP è uno strumento per l’analisi complessa di grandi volumi di dati. È così che le aziende ottengono insight analitici significativi. Prendiamo ad esempio il commercio al dettaglio alimentare: il team di analytics raccoglie tutti i dati di vendita di un periodo specifico da più fonti, come database operativi, servizi esterni e altri sistemi. Tutti questi dati vengono poi caricati in un sistema di storage specializzato – un data warehouse – ottimizzato per l’analisi multidimensionale.

Dopodiché, gli analisti eseguono una query:
“Quanta burro e pane sono stati venduti a giugno 2024 in tutti i negozi di una determinata regione, come sono cambiati quei numeri a giugno 2025 e qual è la relazione tra questi prodotti?”.

Rispondere a una domanda simile richiede di aggregare milioni di righe, filtrare i dati per regioni, categorie e date, e poi calcolare correlazioni, cambiamenti e previsioni. Tali query possono richiedere molto tempo – entro limiti ragionevoli – ed è perfettamente normale, perché i risultati vengono utilizzati per prendere decisioni aziendali e definire strategie a lungo termine.

Nell’OLAP, completezza e accuratezza contano più del tempo di risposta immediato. Ecco perché analisi strategiche – report annuali o previsioni a lungo termine – possono durare una o due ore. Diverso è il caso delle analisi operative che supportano decisioni quotidiane, come le modifiche ai prezzi: se queste operazioni impiegano ore per essere completate, di solito è un segnale di infrastruttura inadeguata.

Al centro dell’OLAP ci sono strutture dati multidimensionali (cubature), che permettono di visualizzare i dati da diverse angolazioni: per tempo, regione, prodotto, cliente e dozzine di altre dimensioni. Questo rende il sistema OLAP uno strumento ideale per l’analisi strategica. Diversamente, ad esempio, dai sistemi CRM, dove l’obiettivo principale è la gestione operativa di clienti e transazioni, non query complesse su terabyte di dati storici di vendita.

Gli strumenti OLAP classici includono ClickHouse, Greenplum, Hadoop/Spark e Amazon Redshift. Sono progettati per il processing su larga scala e il parallelismo.

L’OLTP, al contrario, è progettato per la massima velocità nell’elaborazione di operazioni individuali. Alla cassa di un supermercato, ogni transazione – scansione di un articolo, pagamento, registrazione – deve avvenire in tempo reale. Qualsiasi ritardo significa code più lunghe e clienti che se ne vanno. Nessuno aspetterebbe tre minuti per articolo solo per comprare burro e pane.

I sistemi OLTP sono ottimizzati specificamente per queste operazioni rapide, frequenti e in tempo reale. Ma usarli per analisi strategiche è quasi inutile: query complesse su dataset massivi non sono ciò per cui sono progettati.

I database OLTP tipici includono PostgreSQL, MySQL/InnoDB, Oracle Database e Microsoft SQL Server.

Esistono anche soluzioni ibride – HTAP (Hybrid Transactional/Analytical Processing) – che cercano di combinare transazioni e analisi all’interno di un unico sistema, come TiDB, SAP HANA o YugabyteDB. In pratica, tuttavia, la maggior parte delle aziende separa ancora i carichi di lavoro: un database gestisce le operazioni rapide, un altro gestisce l’analisi. La comodità dei sistemi ibridi ha un costo: maggiore complessità infrastrutturale e requisiti hardware più elevati.

Ed è qui che architetti IT, amministratori o chiunque sia responsabile iniziano a porsi domande. Quale server usare per OLAP e quale per OLTP? Devono essere server separati? Macchine virtuali? Un cluster? Forse nodi di calcolo combinati con storage separato? Quanti sistemi di storage servono? Se ce ne sono diversi, devono essere attivi-attivi o attivi-passivi? E questo è solo l’inizio; ci sono dozzine, se non centinaia, di dettagli simili.

E questi dettagli influenzano direttamente il business.

Non potrò rispondere a ogni possibile domanda – i carichi di lavoro di ciascuno sono diversi – ma cercherò di fornire punti di riferimento utili. E, come sempre, i commenti sono aperti.

Come scegliere server e storage per OLTP e OLAP

Selezionare server per OLTP e OLAP è un compito profondamente diverso, e gli errori si pagano caro. Metti uno storage lento sotto OLTP e otterrai code di richieste e clienti insoddisfatti. Prova a eseguire carichi OLAP su server inadatti e vedrai le query eseguire per settimane. Cercare di risparmiare sulla ridondanza di dati e componenti… beh, già sai come va a finire.

Nei sistemi database ad alto carico, le prestazioni e l’affidabilità dipendono direttamente dall’architettura e dall’hardware. Ma prima di acquistare attrezzature, le decisioni architetturali vengono prima. Iniziamo con OLTP.

Architettura OLTP: velocità e predicibilità

I sistemi OLTP sono la prima linea del business. Banca online, gateway di pagamento e piattaforme e-commerce funzionano su di essi. Questi sistemi hanno requisiti chiari: decine o centinaia di migliaia di transazioni al secondo, SLA di latenza rigorosi misurati in millisecondi e integrità dei dati; perdere un singolo record di transazione equivale a perdere denaro.

Ogni sistema transazionale è costruito intorno ai requisiti ACID (Atomicità, Consistenza, Isolamento, Durabilità). In termini semplici:

• Una transazione viene eseguita completamente o non viene eseguita affatto (Atomicità)

• I dati rimangono in uno stato coerente (Consistenza)

• Le operazioni parallele non interferiscono tra loro (Isolamento)

• I dati non si perdono nemmeno in caso di guasto (Durabilità)

Osservando un sistema del genere, un architetto IT non parte dall’hardware. Le preoccupazioni principali sono come normalizzare i dati affinché le transazioni restino rapide e coerenti; come distribuire il carico sui cluster usando sharding e replicazione; e come progettare la tolleranza ai guasti affinché il malfunzionamento di uno o più nodi non blocchi l’intero sistema.

Conclusione:
Se la semplicità conta e il carico previsto è moderato, la scelta ottimale è una combinazione di replicazione e caching, ad esempio PostgreSQL o MySQL con Redis. Quando il volume di dati cresce e il carico aumenta linearmente, e la consistenza globale rigorosa non è critica, le architetture shared-nothing con sharding hanno più senso. Se la consistenza rigorosa è la massima priorità – e il budget lo consente – le soluzioni shared-disk come Oracle RAC sono la scelta migliore. Per sistemi che richiedono velocità di elaborazione estrema o analytics in tempo reale, vale la pena considerare database in-memory.

Nella tabella sottostante ho riassunto i principali approcci architetturali utilizzati nella progettazione dei sistemi OLTP.

La conclusione è semplice. Se ottimizzi un sistema OLTP come fosse un OLAP, distruggerai la latenza. Se fai girare carichi OLAP su infrastruttura di livello OLTP, i tuoi analisti passeranno il tempo a guardare barre di progresso invece di dashboard. Gli errori di architettura qui non si vedono nei benchmark, ma in ricavi persi, SLA non rispettati e riunioni molto scomode.