Partilhar via

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 transações são descrições 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 consistentes dentro do contexto da carga de trabalho, 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:

Requisito Descrição
Normalização Altamente normalizado
Esquema Esquema na gravação, imposto
Consistência Forte consistência, garantias ACID
Integridade Alta integridade
Usa transações Sim
Estratégia de bloqueio Pessimista ou otimista
Atualizável Sim
Anexável Sim
Carga de trabalho Gravações pesadas, leituras moderadas
Indexação Índices primários e secundários
Tamanho do datum Pequenas e médias empresas
Flexibilidade de consulta Altamente flexível
Escala Pequeno (MBs) a Grande (alguns TBs)

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 efeito negativo nas operações diárias do negócio.

Os sistemas OLTP são projetados para processar e armazenar transações de forma eficiente e consultar dados transacionais. O objetivo de processar e armazenar eficientemente transações individuais por um sistema OLTP é parcialmente alcançado por meio da normalização de dados, ou seja, dividindo os dados em partes menores que são menos redundantes. Esta etapa permite que o sistema OLTP processe um grande número de transações de forma independente e evita o processo 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 distribuídos, embora haja exceções, como um esquema bem planejado. 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 das consultas precisa desnormalizar os dados usando junções. O aumento da normalização pode dificultar a consulta de usuários corporativos 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, aplicativos móveis ou de desktop normalmente se comunicam com o sistema OLTP 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, as cargas de trabalho geralmente precisam de relatórios em tempo real, como a execução de relatórios no sistema operacional. Essa carga de trabalho também é conhecida 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 atendem aos requisitos principais para OLTP e o gerenciamento de dados de transação:

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 altos? Se sim, escolha uma opção que forneça tabelas na memória ou recursos de distribuição global, como o Azure Cosmos DB.

  • 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. Os pools elásticos podem ajudá-lo a distribuir melhor a capacidade em todas as instâncias de banco de dados e tornar sua solução mais econômica. O Azure Cosmos DB oferece vários modelos de isolamento para cenários multilocatário.

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

  • 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.

  • Sua carga de trabalho requer transações ACID garantidas? Se estiver trabalhando com dados não relacionais, considere o Azure Cosmos DB, que fornece garantias ACID por meio de operações em lote transacionais em uma partição lógica.

  • 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.

  • A sua solução requer transações distribuídas? Se sim, considere transações elásticas no Banco de Dados SQL do Azure e na Instância Gerenciada do SQL. A Instância Gerenciada SQL também oferece suporte a chamadas tradicionais por meio do Microsoft Distributed Transaction Coordinator (MSDTC).

Próximos passos