OLTP (Online Transaction Processing)

La gestione di dati transazionali tramite sistemi informatici prende il nome di elaborazione delle transazioni online (Online Transaction Processing, OLTP). I sistemi OLTP registrano le interazioni aziendali man mano che si verificano nell'ambito delle operazioni giornaliere eseguite all'interno dell'organizzazione e supportano la creazione di query su questi dati per l'inserimento di inferenze.

Dati transazionali

I dati transazionali sono informazioni che tengono traccia delle interazioni correlate alle attività di un'organizzazione. Tali interazioni sono in genere transazioni aziendali, ad esempio pagamenti ricevuti dai clienti, pagamenti effettuati ai fornitori, movimentazione di prodotti dell'inventario, elaborazione di ordini o fornitura di servizi. Gli eventi transazionali, che rappresentano le transazioni stesse, in genere contengono una dimensione temporale, alcuni valori numerici e riferimenti ad altri dati.

Le transazioni devono in genere essere atomiche e coerenti. L'atomicità indica che un'intera transazione ha sempre esito positivo o negativo come unità di lavoro e non viene mai lasciata in uno stato parziale. Se una transazione non può essere completata, il sistema di database deve eseguire il rollback di eventuali passaggi già eseguiti come parte di tale transazione. In un sistema di gestione di database relazionale tradizionale (RDBMS), questo rollback viene eseguito automaticamente se non è possibile completare una transazione. La coerenza indica che le transazioni lasciano sempre i dati in uno stato valido. Queste sono descrizioni molto informali dell'atomicità e della coerenza. Esistono definizioni più formali di queste proprietà, ad esempio ACID.

I database transazionali possono supportare la coerenza assoluta per le transazioni che usano diverse strategie di blocco, ad esempio il blocco pessimistico, per garantire che tutti i dati siano fortemente coerenti nel contesto aziendale per tutti gli utenti e i processi.

L'architettura di distribuzione più comune che usa i dati transazionali è il livello di archivio dati in un'architettura a 3 livelli. Un'architettura a 3 livelli in genere è costituita da livello di presentazione, livello di logica di business e livello di archivio dati. Un'architettura di distribuzione correlata è l'architettura N-tier, che può avere più livelli intermedi che gestiscono la logica aziendale.

Caratteristiche tipiche dei dati transazionali

I dati transazionali hanno, in genere, le caratteristiche seguenti:

Quando usare questa soluzione

Scegliere OLTP nei casi in cui è necessario elaborare e archiviare in modo efficiente transazioni aziendali, nonché renderle immediatamente disponibili alle applicazioni client in modo coerente. Usare questa architettura anche quando eventuali ritardi tangibili nell'elaborazione avrebbero un impatto negativo sulle operazioni quotidiane dell'azienda.

I sistemi OLTP sono progettati per elaborare e archiviare in modo efficiente le transazioni, nonché per eseguire query sui dati transazionali. L'obiettivo dei sistemi OLTP di elaborare e archiviare in modo efficiente singole transazioni viene parzialmente soddisfatto dalla normalizzazione dei dati, ovvero dalla suddivisione dei dati in blocchi più piccoli meno ridondanti. Questo meccanismo favorisce l'efficienza perché consente al sistema OLTP di elaborare grandi quantità di transazioni in modo indipendente ed evita le attività di elaborazione altrimenti necessarie per mantenere l'integrità dei dati in presenza di dati ridondanti.

Problematiche

L'implementazione e l'utilizzo di un sistema OLTP può creare alcune problematiche:

• I sistemi OLTP non sono sempre validi per la gestione delle aggregazioni su grandi quantità di dati, anche se esistono eccezioni, ad esempio una soluzione basata su SQL Server ben pianificata. L'analisi dei dati, che si basa su calcoli aggregati di milioni di singole transazioni, richiede l'utilizzo di moltissime risorse per un sistema OLTP. L'esecuzione dei calcoli, infatti, può essere molto lunga e causare rallentamenti bloccando le altre transazioni nel database.

• Quando vengono eseguite operazioni di analisi e report su dati altamente normalizzati, le query tendono a essere complesse, poiché la maggior parte delle query deve denormalizzare i dati per mezzo di join. Nei sistemi OLTP, inoltre, le convenzioni di denominazione per oggetti di database tendono a essere concise e sintetiche. Questa elevata normalizzazione, associata alle concisione delle convenzioni di denominazione, rende più difficile per gli utenti aziendali eseguire query sui sistemi OLTP senza l'aiuto di un amministratore di database o di uno sviluppatore di dati.

• L'archiviazione della cronologia delle transazioni per un periodo illimitato e l'archiviazione di una quantità eccessiva di dati in una tabella può generare inoltre un rallentamento delle prestazioni delle query, in funzione del numero di transazioni archiviate. La soluzione comune consiste nel mantenere un intervallo di tempo pertinente (ad esempio l'anno fiscale corrente) nel sistema OLTP e trasferire dati cronologici in altri sistemi, ad esempio un data mart o un data warehouse.

OLTP in Azure

Applicazioni come siti Web ospitati in App Service Web Apps, API REST in esecuzione in App Service o applicazioni mobili o desktop comunicano con il sistema OLTP, generalmente tramite un intermediario API REST.

In pratica, la maggior parte dei carichi di lavoro non è puramente OLTP. Tende a esserci anche un componente analitico. Si assiste anche a una domanda crescente di strumenti per la creazione di report in tempo reale, ad esempio per l'esecuzione di report inerenti al sistema operativo. Questa operazione è nota anche come elaborazione transazionale/analitica ibrida (HTAP) (elaborazione transazionale ibrida e analitica). Per altre informazioni, vedere Online Analytical Processing (OLAP).

In Azure tutti gli archivi dati elencati di seguito soddisfano i requisiti di base per OLTP e la gestione dei dati transazionali:

• Azure SQL Database
• SQL Server in una macchina virtuale di Azure
• Database di Azure per MySQL
• Database di Azure per PostgreSQL

Criteri di scelta principali

Per limitare le possibilità di scelta, rispondere prima di tutto a queste domande:

• Si vuole usare un servizio gestito anziché gestire direttamente i propri server?

• Si ha una soluzione con specifiche dipendenze per la compatibilità con Microsoft SQL Server, MySQL o PostgreSQL? L'applicazione può limitare gli archivi dati che è possibile scegliere in base ai driver supportati per la comunicazione con l'archivio dati o può essere in grado di formulare solo alcune ipotesi riguardo al database usato.

• Si hanno requisiti particolarmente elevati per la velocità effettiva di scrittura? In caso affermativo, scegliere un'opzione in grado di fornire tabelle in memoria.

• La tua soluzione è multi-tenant? In caso affermativo, prendere in considerazione le opzioni che supportano pool di capacità, in cui più istanze di database estraggono le risorse da un pool elastico, anziché risorse fisse per singolo database. In questo modo verrà ottimizzata la distribuzione della capacità in tutte le istanze di database e la soluzione risulterà economicamente più vantaggiosa.

• I dati devono essere leggibili con bassa latenza in più aree? In caso affermativo, scegliere un'opzione che supporta repliche leggibili secondarie.

• Il database deve garantire disponibilità elevata nelle diverse aree geografiche? In caso affermativo, scegliere un'opzione con il supporto per la replica geografica. Prendere in considerazione anche le opzioni che supportano il failover automatico dalla replica primaria a una replica secondaria.

• Il database ha specifici requisiti di sicurezza? In caso affermativo, esaminare le opzioni che forniscono funzionalità quali la sicurezza a livello di riga, la maschera dati e la crittografia TDE (Transparent Data Encryption).

Matrice delle funzionalità

Le tabelle seguenti contengono un riepilogo delle differenze principali in termini di funzionalità.

Funzionalità generali

[1] Non è incluso il supporto per i driver client, che consente a molti linguaggi di programmazione di connettersi all'archivio dati OLTP e usarne le risorse.

Funzionalità di scalabilità

Funzionalità per carichi di lavoro di analisi

Funzionalità di disponibilità

Funzionalità di sicurezza

Passaggi successivi

• Introduzione alle tabelle Memory-Optimized
• In-Memory Panoramica OLTP e scenari di utilizzo
• Ottimizzare le prestazioni usando tecnologie in memoria nel database SQL di Azure e in Istanza gestita di SQL di Azure
• Transazioni distribuite tra database cloud

Risorse correlate

• Guida all'architettura dei dati di Azure
• Elaborazione delle transazioni online IBM z/OS in Azure