Carichi transazionali (OLTP) e analitici (OLAP)

Ogni sistema dati serve uno di due scopi fondamentali: far funzionare l’azienda giorno per giorno oppure capire come sta andando l’azienda. Questa distinzione separa i carichi di lavoro transazionali (OLTP, Online Transaction Processing) da quelli analitici (OLAP, Online Analytical Processing). Riconoscere quale dei due si nasconde dietro uno scenario è una delle competenze più verificate nell’esame DP-900.

OLTP: i carichi transazionali

Un sistema OLTP gestisce le transazioni operative: molte operazioni piccole e frequenti, spesso in scrittura, ciascuna eseguita in millisecondi. Pensa al sistema di cassa di un supermercato: ogni scontrino inserisce righe di vendita, decrementa lo stock e aggiorna il totale, mentre centinaia di casse lavorano in parallelo.

Le caratteristiche tipiche di un workload OLTP sono:

• Molte scritture piccole (INSERT, UPDATE, DELETE) e letture puntuali su pochi record.
• Alta concorrenza: tanti utenti che operano contemporaneamente.
• Bassa latenza: la risposta deve essere quasi istantanea.
• Dati altamente normalizzati, organizzati in tabelle relazionali per evitare duplicazioni.

Le proprietà ACID

Perché una transazione sia affidabile deve rispettare le proprietà ACID:

• Atomicity (Atomicità): la transazione è “tutto o niente”. Se il pagamento fallisce a metà, l’intera operazione viene annullata (rollback), non resta uno stato parziale.
• Consistency (Consistenza): ogni transazione porta il database da uno stato valido a un altro stato valido, rispettando i vincoli.
• Isolation (Isolamento): transazioni concorrenti non si “disturbano”; il risultato è come se fossero eseguite in sequenza.
• Durability (Durabilità): una volta confermata (commit), la transazione sopravvive anche a un crash o a un’interruzione di corrente.

Servizi Azure orientati all’OLTP: Azure SQL Database, Azure Database for PostgreSQL/MySQL e, per scenari NoSQL a bassa latenza globale, Azure Cosmos DB.

OLAP: i carichi analitici

Un sistema OLAP serve l’analisi: interroga grandi volumi di dati storici per produrre aggregazioni, tendenze e report. Pensa al report vendite trimestrale che somma i ricavi per regione, categoria e periodo, incrociando milioni di righe accumulate nel tempo.

Le caratteristiche tipiche di un workload OLAP sono:

• Query aggregate complesse (SUM, AVG, COUNT, GROUP BY) su enormi quantità di dati.
• Prevalentemente in sola lettura: i dati vengono caricati periodicamente, non modificati in continuo.
• Ottimizzato per la lettura analitica, spesso con archiviazione colonnare che accelera le aggregazioni.
• Dati denormalizzati, tipicamente in schemi a stella (fact e dimension table) all’interno di un data warehouse.

I dati arrivano nell’ambiente OLAP tramite processi ETL/ELT che estraggono dalle sorgenti OLTP, trasformano e caricano. Servizi Azure orientati all’OLAP: Azure Synapse Analytics e la piattaforma unificata Microsoft Fabric (con il suo data warehouse e i lakehouse), mentre Power BI costruisce sopra questi dati i modelli e le dashboard.

OLTP vs OLAP a colpo d’occhio

Trappole tipiche d’esame

• Scenario: “Il sistema deve registrare migliaia di ordini al secondo con risposta immediata.” → È un carico OLTP, non OLAP.
• Scenario: “Un analista deve aggregare tre anni di vendite per prodotto e regione.” → È un carico OLAP (data warehouse / Microsoft Fabric o Azure Synapse Analytics).
• Scenario: “Se il pagamento fallisce, l’intera transazione deve essere annullata.” → Descrive l’Atomicity delle proprietà ACID (attenzione: non confonderla con Consistency).
• Scenario: “Una transazione confermata deve sopravvivere a un’interruzione di corrente.” → È la Durability, non l’Isolation.
• Scenario: “Prevalentemente in sola lettura, query complesse su grandi volumi storici.” → Parole chiave che identificano l’OLAP; “molte scritture concorrenti a bassa latenza” identificano invece l’OLTP.