Partilhar via

Processamento de transações online (OLTP)

A gestão de dados transacionais através da utilização de 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 quando uma transação não pode 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 atômicas, consistentes, isoladas e duráveis (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. Essas estratégias ajudam a garantir que todos os dados permaneçam 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 três camadas. Uma arquitetura de três 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 através da normalização de dados, que divide os dados em partes menores e menos redundantes. Esta etapa permite que o sistema OLTP processe um grande número de transações de forma independente. Também evita processos adicionais necessários para manter a integridade dos dados na presença de dados redundantes.

Desafios

Um sistema OLTP pode criar alguns desafios:

  • Quando você executa análises em relação aos dados que dependem de cálculos agregados em milhões de transações individuais, isso consome muitos recursos para um sistema OLTP. Eles podem ser lentos para executar e causar uma lentidão, bloqueando outras transações no banco de dados. Como resultado, os sistemas OLTP nem sempre são ideais para lidar com agregados em grandes quantidades de dados distribuídos. Mas há exceções, como um esquema bem planejado.

  • Quando você realiza 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 administrador de banco de dados (DBA) ou desenvolvedor de dados.

  • Quando você armazena o histórico de transações indefinidamente ou armazena muitos dados em qualquer tabela, isso 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 e 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 totalmente OLTP. Muitas vezes, também incluem um componente analítico e exigem relatórios em tempo real, como a execução de relatórios no sistema operacional. Essa carga de trabalho é conhecida como processamento analítico e transacional híbrido (HTAP). Para obter mais informações, consulte Processamento analítico on-line (OLAP).

No Azure, os seguintes armazenamentos de dados atendem aos requisitos principais para OLTP e o gerenciamento de dados de transação:

Principais critérios de seleção

Para restringir as opções, comece por responder às seguintes 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. 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 você trabalha 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

  • Last updated on