Condividi tramite

OLTP (Online Transaction Processing)

La gestione dei dati transazionali tramite sistemi informatici viene definita elaborazione delle transazioni online (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 non è possibile completare una transazione, il sistema di database deve eseguire il rollback di tutti i passaggi già eseguiti come parte di tale transazione. In un sistema di gestione di database relazionale tradizionale (RDBMS), questo rollback viene eseguito automaticamente quando una transazione non può essere completata. La coerenza indica che le transazioni lasciano sempre i dati in uno stato valido. Queste transazioni sono descrizioni informali dell'atomicità e della coerenza. Esistono definizioni più formali di queste proprietà, ad esempio atomiche, coerenti, isolate e durevoli (ACID).

I database transazionali possono supportare una coerenza assoluta per le transazioni usando diverse strategie di blocco, ad esempio il blocco pessimistico. Queste strategie consentono di garantire che tutti i dati rimangano coerenti nel contesto del carico di lavoro, per tutti gli utenti e i processi.

L'architettura di distribuzione più comune che usa dati transazionali è il livello di archivio dati in un'architettura a tre livelli. Un'architettura a tre livelli è in genere costituita da un livello presentazione, un livello di logica di business e un 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 tendono ad avere i tratti seguenti.

Requisito Descrizione
Normalizzazione Normalizzazione elevata
Diagramma Schema in scrittura, 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
Flessibilità delle query Flessibilità elevata
Scala Piccole (MB) a grandi (pochi TB)

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 quando qualsiasi ritardo tangibile nell'elaborazione ha un effetto negativo sulle operazioni quotidiane dell'azienda.

I sistemi OLTP sono progettati per elaborare ed archiviare in modo efficiente le transazioni ed eseguire query sui dati transazionali. L'obiettivo dell'elaborazione e dell'archiviazione efficiente di singole transazioni da parte di un sistema OLTP avviene in parte tramite la normalizzazione dei dati, che suddivide i dati in blocchi più piccoli e meno ridondanti. Questo passaggio consente al sistema OLTP di elaborare in modo indipendente un numero elevato di transazioni. Evita inoltre processi aggiuntivi necessari per mantenere l'integrità dei dati in presenza di dati ridondanti.

Problematiche

Un sistema OLTP può creare alcune sfide:

  • Quando vengono eseguite analisi sui dati che si basano su calcoli aggregati su milioni di singole transazioni, è molto dispendioso in termini di risorse per un sistema OLTP. Possono essere lente da eseguire e causare un rallentamento bloccando altre transazioni nel database. Di conseguenza, i sistemi OLTP non sono sempre ideali per la gestione di aggregazioni su grandi quantità di dati distribuiti. Esistono tuttavia eccezioni, ad esempio uno schema ben pianificato.

  • Quando si eseguono analisi e report sui dati altamente normalizzati, le query tendono ad essere complesse, perché la maggior parte delle query deve denormalizzare i dati usando join. L'aumento della normalizzazione può rendere difficile per gli utenti aziendali eseguire query senza l'aiuto di un amministratore di database o di uno sviluppatore di dati.

  • Quando si archivia la cronologia delle transazioni per un periodo illimitato o si archivia una quantità eccessiva di dati in una tabella, può causare un rallentamento delle prestazioni delle query, a seconda 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 e applicazioni per dispositivi mobili o desktop in genere comunicano con il sistema OLTP tramite un API REST come intermediario.

In pratica, la maggior parte dei carichi di lavoro non è interamente OLTP. Spesso includono un componente analitico e richiedono report in tempo reale, ad esempio l'esecuzione di report sul sistema operativo. Questo carico di lavoro viene definito elaborazione transazionale ibrida e analitica (HTAP). Per altre informazioni, vedere Elaborazione analitica online (OLAP).

In Azure, gli archivi dati seguenti soddisfano i requisiti di base per OLTP e la gestione dei dati delle transazioni:

Criteri di scelta principali

Per restringere le scelte, iniziare rispondendo alle domande seguenti:

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

  • La soluzione ha dipendenze specifiche per la compatibilità di Microsoft SQL Server, MySQL o PostgreSQL? L'applicazione potrebbe limitare gli archivi dati che è possibile scegliere in base ai driver supportati per la comunicazione con l'archivio dati o i presupposti su quale database viene usato.

  • I requisiti di velocità effettiva di scrittura sono elevati? In caso affermativo, scegliere un'opzione che fornisce tabelle in memoria o funzionalità di distribuzione globali come Azure Cosmos DB.

  • La tua soluzione è multi-tenant? In tal caso, prendere in considerazione le opzioni che supportano i pool di capacità. Più istanze di database provengono da un pool elastico di risorse, anziché da risorse fisse per ogni database. I pool elastici consentono di distribuire meglio la capacità in tutte le istanze del database e rendere la soluzione più conveniente. Azure Cosmos DB offre più modelli di isolamento per scenari multi-tenant.

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

  • 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 carico di lavoro richiede transazioni ACID garantite? Se si lavora con dati non relazionali, prendere in considerazione Azure Cosmos DB, che fornisce garanzie ACID tramite operazioni batch transazionali all'interno di una partizione logica.

  • Il database ha specifici requisiti di sicurezza? In caso affermativo, esaminare le opzioni che offrono funzionalità come sicurezza a livello di riga, maschera dati e Transparent Data Encryption.

  • La soluzione richiede transazioni distribuite? In caso affermativo, prendere in considerazione le transazioni elastiche all'interno del database SQL di Azure e dell'istanza gestita di SQL. Istanza gestita di SQL supporta anche le chiamate tradizionali tramite Microsoft Distributed Transaction Coordinator (MSDTC).

Passaggi successivi

  • Last updated on