Processamento de transações online (OLTP)

A gestão de dados transacionais utilizando sistemas informáticos é designada por processamento de transações em linha (OLTP). Os sistemas OLTP registram as interações comerciais à medida que ocorrem na operação diária da organização e suportam a consulta desses dados para fazer inferências.

Dados transacionais

Dados transacionais são informações que rastreiam as interações relacionadas às atividades de uma organização. Essas interações geralmente são transações comerciais, como pagamentos recebidos de clientes, pagamentos feitos a fornecedores, produtos que passam pelo estoque, pedidos feitos ou serviços entregues. Os eventos transacionais, que representam as próprias transações, normalmente contêm uma dimensão de tempo, alguns valores numéricos e referências a outros dados.

As transações normalmente precisam ser atômicas e consistentes. Atomicidade significa que uma transação inteira sempre é bem-sucedida ou falha como uma unidade de trabalho, e nunca é deixada em um estado semi-concluído. Se uma transação não puder ser concluída, o sistema de banco de dados deverá reverter todas as etapas que já foram feitas como parte dessa transação. Em um sistema de gerenciamento de banco de dados relacional tradicional (RDBMS), essa reversão acontece automaticamente se uma transação não puder ser concluída. Consistência significa que as transações sempre deixam os dados em um estado válido. (Estas são descrições muito informais de atomicidade e consistência. Existem definições mais formais dessas propriedades, como ACID.)

Os bancos de dados transacionais podem oferecer suporte a uma forte consistência para transações usando várias estratégias de bloqueio, como o bloqueio pessimista, para garantir que todos os dados sejam fortemente consistentes dentro do contexto da empresa, para todos os usuários e processos.

A arquitetura de implantação mais comum que usa dados transacionais é a camada de armazenamento de dados em uma arquitetura de 3 camadas. Uma arquitetura de 3 camadas geralmente consiste em uma camada de apresentação, uma camada de lógica de negócios e uma camada de armazenamento de dados. Uma arquitetura de implantação relacionada é a arquitetura de N camadas , que pode ter várias camadas intermediárias lidando com a lógica de negócios.

Características típicas de dados transacionais

Os dados transacionais tendem a ter as seguintes características:

Quando utilizar esta solução

Escolha OLTP quando precisar processar e armazenar transações comerciais de forma eficiente e disponibilizá-las imediatamente para aplicativos clientes de forma consistente. Use essa arquitetura quando qualquer atraso tangível no processamento tiver um impacto negativo nas operações diárias do negócio.

Os sistemas OLTP são projetados para processar e armazenar transações de forma eficiente, bem como consultar dados transacionais. O objetivo de processar e armazenar eficientemente transações individuais por um sistema OLTP é parcialmente alcançado pela normalização de dados — ou seja, dividir os dados em partes menores que são menos redundantes. Isso suporta a eficiência porque permite que o sistema OLTP processe um grande número de transações de forma independente e evita o processamento extra necessário para manter a integridade dos dados na presença de dados redundantes.

Desafios

Implementar e usar um sistema OLTP pode criar alguns desafios:

• Os sistemas OLTP nem sempre são bons para lidar com agregações em grandes quantidades de dados, embora haja exceções, como uma solução bem planejada baseada no SQL Server. A análise em relação aos dados, que dependem de cálculos agregados em milhões de transações individuais, consome muitos recursos para um sistema OLTP. Eles podem ser lentos para executar e podem causar uma lentidão, bloqueando outras transações no banco de dados.
• Ao realizar análises e relatórios sobre dados altamente normalizados, as consultas tendem a ser complexas, porque a maioria precisa desnormalizar os dados usando junções. Além disso, as convenções de nomenclatura para objetos de banco de dados em sistemas OLTP tendem a ser concisas e sucintas. O aumento da normalização, juntamente com convenções de nomenclatura concisas, torna os sistemas OLTP difíceis de consultar pelos usuários de negócios, sem a ajuda de um DBA ou desenvolvedor de dados.
• Armazenar o histórico de transações indefinidamente e armazenar muitos dados em qualquer tabela pode levar a um desempenho lento da consulta, dependendo do número de transações armazenadas. A solução comum é manter uma janela de tempo relevante (como o ano fiscal atual) no sistema OLTP e descarregar dados históricos para outros sistemas, como um data mart ou data warehouse.

OLTP no Azure

Aplicativos como sites hospedados em Aplicativos Web do Serviço de Aplicativo, APIs REST em execução no Serviço de Aplicativo ou aplicativos móveis ou de desktop se comunicam com o sistema OLTP, normalmente por meio de um intermediário de API REST.

Na prática, a maioria das cargas de trabalho não são puramente OLTP. Tende a haver também uma componente analítica. Além disso, há uma demanda crescente por relatórios em tempo real, como a execução de relatórios no sistema operacional. Isso também é conhecido como processamento transacional/analítico híbrido (HTAP) (Processamento Transacional e Analítico Híbrido). Para obter mais informações, consulte OLAP (Online Analytical Processing).

No Azure, todos os armazenamentos de dados a seguir atenderão aos requisitos principais para OLTP e o gerenciamento de dados de transação:

• Base de Dados SQL do Azure
• SQL Server em uma máquina virtual do Azure
• Base de Dados do Azure para MySQL
• Base de Dados do Azure para PostgreSQL

Principais critérios de seleção

Para restringir as escolhas, comece por responder a estas perguntas:

• Você quer um serviço gerenciado em vez de gerenciar seus próprios servidores?

• Sua solução tem dependências específicas para compatibilidade com Microsoft SQL Server, MySQL ou PostgreSQL? Seu aplicativo pode limitar os armazenamentos de dados que você pode escolher com base nos drivers que ele suporta para se comunicar com o armazenamento de dados ou nas suposições que ele faz sobre qual banco de dados é usado.

• Seus requisitos de taxa de transferência de gravação são particularmente altos? Se sim, escolha uma opção que forneça tabelas na memória.

• A sua solução é multilocatário? Em caso afirmativo, considere opções que ofereçam suporte a pools de capacidade, em que várias instâncias de banco de dados se baseiam em um pool elástico de recursos, em vez de recursos fixos por banco de dados. Isso pode ajudá-lo a distribuir melhor a capacidade em todas as instâncias de banco de dados e tornar sua solução mais econômica.

• Seus dados precisam ser legíveis com baixa latência em várias regiões? Em caso afirmativo, escolha uma opção que ofereça suporte a réplicas secundárias legíveis.

• Seu banco de dados precisa estar altamente disponível em todas as regiões geográficas? Em caso afirmativo, escolha uma opção que ofereça suporte à replicação geográfica. Considere também as opções que oferecem suporte a failover automático da réplica primária para uma réplica secundária.

• A sua base de dados tem necessidades de segurança específicas? Em caso afirmativo, examine as opções que fornecem recursos como segurança em nível de linha, mascaramento de dados e criptografia de dados transparente.

Matriz de capacidades

As tabelas a seguir resumem as principais diferenças nos recursos.

Capacidades gerais

[1] Não incluindo o suporte ao driver do cliente, que permite que muitas linguagens de programação se conectem e usem o armazenamento de dados OLTP.

Recursos de escalabilidade

Recursos de carga de trabalho analítica

Capacidades de disponibilidade

Funcionalidades de segurança

Contribuidores

Este artigo é mantido pela Microsoft. Foi originalmente escrito pelos seguintes contribuidores.

Autor principal:

• Zoiner Tejada - Brasil | CEO e Arquiteto

Próximos passos

• Introdução às tabelas com otimização de memória
• Visão geral do OLTP na memória e cenários de uso
• Otimizar o desempenho usando tecnologias na memória no Banco de Dados SQL do Azure e na Instância Gerenciada SQL do Azure
• Transações distribuídas entre bases de dados de cloud

Recursos relacionados

• Guia de Arquitetura de Dados do Azure
• Processamento de transações online do IBM z/OS no Azure