Condividi tramite

OLTP (Online Transaction Processing)

  • Articolo

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.

In genere, le transazioni devono 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 a più livelli, che può avere più livelli intermedi che gestiscono la logica di business.

Caratteristiche tipiche dei dati transazionali

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

Requisito Descrizione
Normalizzazione Normalizzazione elevata
Schema Schema durante la scrittura, fortemente applicato
Coerenza Coerenza assoluta, garanzia ACID
Integrità Integrità elevata
Uso delle transazioni Sì
Strategia di blocco Ottimistica o pessimistica
Aggiornabile Sì
Accodamento Sì
Carico di lavoro Operazioni di scrittura intense e lettura moderate
Indicizzazione Indici primari e secondari
Dimensioni dati Da piccole a medie
Modello Relazionale
Forma dei dati tabulare
Flessibilità query Flessibilità elevata
Ridimensiona Da piccole (MB) a grandi (alcuni TB) dimensioni

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. Una possibile soluzione consiste nel mantenere una finestra temporale rilevante (ad esempio l'anno fiscale corrente) nel sistema OLTP e scaricare i dati storici su altri sistemi, ad esempio un data mart o un data warehouse.

OLTP in Azure

Le applicazioni come i siti Web ospitati nell'app Web del servizio app, le API REST in esecuzione nel servizio app o applicazioni desktop o per dispositivi mobili comunicano in genere con il sistema OLTP tramite un intermediario dell'API REST.

In pratica, la maggior parte dei carichi di lavoro non è puramente OLTP. ma tende a essere 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 OLAP (Online Analytical Processing).

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

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.

  • Si ha una 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 con il supporto per repliche secondarie leggibili.

  • 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

Funzionalità Database SQL di Azure SQL Server in una macchina virtuale di Azure Database di Azure per MySQL Database di Azure per PostgreSQL
Servizio gestito Sì No Sì Sì
Piattaforma N/D Windows, Linux, Docker N/D N/D
Programmabilità 1 T-SQL, .NET, R T-SQL, .NET, R, Python SQL SQL, PL/pgSQL, PL/JavaScript (v8)

[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à Database SQL di Azure SQL Server in una macchina virtuale di Azure Database di Azure per MySQL Database di Azure per PostgreSQL
Dimensione massima delle istanze di database 4 TB 256 TB 16 TB 16 TB
Supporto per pool di capacità Sì Sì No No
Supporto per la scalabilità orizzontale di cluster No Sì No No
Scalabilità dinamica (aumento delle prestazioni) Sì No Sì Sì

Funzionalità per carichi di lavoro di analisi

Funzionalità Database SQL di Azure SQL Server in una macchina virtuale di Azure Database di Azure per MySQL Database di Azure per PostgreSQL
Tabelle temporali Sì Sì No No
Tabelle in memoria (ottimizzate per la memoria) Sì Sì No No
Supporto per columnstore Sì Sì No No
Elaborazione di query adattive Sì Sì No No

Funzionalità per la disponibilità

Funzionalità Database SQL di Azure SQL Server in una macchina virtuale di Azure Database di Azure per MySQL Database di Azure per PostgreSQL
Repliche secondarie leggibili Sì Sì Sì Sì
Replica geografica Sì Sì Sì Sì
Failover automatico in replica secondaria Sì No No No
Ripristino temporizzato Sì Sì Sì Sì

Funzionalità di sicurezza

Funzionalità Database SQL di Azure SQL Server in una macchina virtuale di Azure Database di Azure per MySQL Database di Azure per PostgreSQL
Protezione a livello di riga Sì Sì Sì Sì
Maschera dati Sì Sì No No
Transparent Data Encryption Sì Sì Sì Sì
Limitazione dell'accesso a specifici indirizzi IP Sì Sì Sì Sì
Limitazione dell'accesso alla rete virtuale Sì Sì Sì Sì
Autenticazione Microsoft Entra Sì No Sì Sì
Autenticazione di Azure Active Directory No Sì No No
Autenticazione a più fattori Sì No Sì Sì
Supporto per Always Encrypted Sì Sì No No
IP privato No Sì No No

Passaggi successivi