Processamento de transações online (OLTP)

  • Artigo

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 RDBMS tradicional, 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:

Requisito Description
Normalização Altamente normalizado
Esquema Esquema na gravação, fortemente 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
Modelo Relacional
Forma de dados Tabular
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 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 HTAP (Hybrid Transactional and Analytical Processing). 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:

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

Funcionalidade Base de Dados SQL do Azure SQL Server numa máquina virtual do Azure Base de Dados do Azure para MySQL Base de Dados do Azure para PostgreSQL
É Serviço Gerenciado Sim No Sim Sim
Funciona na plataforma N/A Windows, Linux, Docker N/A N/A
Programação 1 T-SQL, .NET, R T-SQL, .NET, R, Python SQL SQL, PL/pgSQL, PL/JavaScript (v8)

[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

Funcionalidade Base de Dados SQL do Azure SQL Server numa máquina virtual do Azure Base de Dados do Azure para MySQL Base de Dados do Azure para PostgreSQL
Tamanho máximo da instância do banco de dados 4 TB 256 TB 16 TB 16 TB
Suporta pools de capacidade Sim Sim No Não
Suporta expansão de clusters Não Sim No Não
Escalabilidade dinâmica (scale-up) Sim No Sim Sim

Recursos de carga de trabalho analítica

Funcionalidade Base de Dados SQL do Azure SQL Server numa máquina virtual do Azure Base de Dados do Azure para MySQL Base de Dados do Azure para PostgreSQL
Tabelas temporais Sim Sim No Não
Tabelas na memória (otimizadas para memória) Sim Sim No Não
Suporte Columnstore Sim Sim No Não
Processamento de consultas adaptável Sim Sim No Não

Capacidades de disponibilidade

Funcionalidade Base de Dados SQL do Azure SQL Server numa máquina virtual do Azure Base de Dados do Azure para MySQL Base de Dados do Azure para PostgreSQL
Secundários legíveis Sim Sim Sim Sim
Replicação geográfica Sim Sim Sim Sim
Failover automático para secundário Sim No No Não
Restauro para um ponto anterior no tempo Sim Sim Sim Sim

Funcionalidades de segurança

Funcionalidade Base de Dados SQL do Azure SQL Server numa máquina virtual do Azure Base de Dados do Azure para MySQL Base de Dados do Azure para PostgreSQL
Segurança ao nível da linha Sim Sim Sim Sim
Máscara de dados Sim Sim No Não
Encriptação de dados transparente Sim Sim Sim Sim
Restringir o acesso a endereços IP específicos Sim Sim Sim Sim
Restringir o acesso para permitir apenas o acesso à rede virtual Sim Sim Sim Sim
Autenticação do Microsoft Entra Sim No Sim Sim
Autenticação do Active Directory Não Sim No Não
Autenticação multifator Sim No Sim Sim
Suporta Sempre Encriptado Sim Sim No Não
IP privado Não Sim No Não

Contribuidores

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

Autor principal:

Próximos passos