Um guia para propriedades ACID em sistemas de gerenciamento de banco de dados
O uso de aplicações em tempo real e dispositivos de Internet das Coisas (IoT), além do crescimento exponencial de ativos de dados não estruturados, está fazendo com que cada vez mais organizações façam a transição para bancos de dados NoSQL. De fato, espera-se que o mercado NoSQL alcance US$ 74,5 bilhões até 2032, exibindo uma taxa de crescimento (CAGR) de 24,9% de 2024 a 2032 (IMARC Group, 2024).
Esse crescimento não é surpreendente, dada a capacidade dos sistemas de gerenciamento de bancos de dados NoSQL (DBMS) de gerenciar com eficiência grandes e diversos conjuntos de dados e a análise de big data associada necessária.
No entanto, muitos ainda acreditam que os DBMS NoSQL não são capazes de atender a um requisito fundamental de muitas organizações — gerenciamento e compliance de transações ACID. A boa notícia é que alguns DBMS NoSQL definitivamente podem!
Neste artigo, discutiremos o que são transações ACID, propriedades da transação ACID, por que essas transações são importantes e um exemplo de transação ACID em um DBMS NoSQL.
Índice
- Uma breve história das transações ACID
- O que são transações ACID?
- Por que as transações ACID são importantes?
- Exemplo de transações ACID no DBMS
- Como as transações ACID funcionam no MongoDB?
- Quando posso usar transações multidocumento do MongoDB?
- Quais são as melhores práticas para transações no MongoDB?
- Perguntas frequentes
Uma breve história das transações ACID
O conceito de transações ACID tem sido fundamental para a evolução de sistemas de bancos de dados modernos desde o final da década de 1970.
À medida que empresas e instituições de pesquisa começaram a depender mais fortemente de dados digitais, a necessidade de maneiras confiáveis de processar operações complexas em múltiplos registros tornou-se clara. Os primeiros bancos de dados relacionais, como o System R da IBM e o Oracle, estiveram entre os primeiros a experimentar forçar garantias mais rigorosas em relação à integridade dos dados e à confiabilidade das transações.
Em 1983, o cientista da computação Andreas Reuter e Theo Härder definiram formalmente as quatro propriedades ACID — atomicidade, consistência, isolamento e durabilidade — em um artigo de referência. O trabalho deles deu à comunidade de banco de dados uma linguagem comum para descrever os requisitos para transações de banco de dados confiáveis. Cada propriedade foi criada para resolver um desafio específico na garantia de que os dados permanecessem válidos e processados de forma confiável, mesmo quando ocorressem falhas:
- A atomicidade garante que várias operações em uma transação ajam como uma unidade única — todas têm sucesso ou todas falham.
- A consistência garante que o banco de dados permaneça em um estado válido que siga regras e restrições definidas.
- O isolamento impede que transações simultâneas interfiram entre si.
- A durabilidade garante que, uma vez que uma transação é confirmada, os resultados sejam permanentes, mesmo após falhas no sistema.
Este framework tornou-se o padrão ouro para sistemas de gerenciamento de banco de dados relacional (RDBMS), especialmente à medida que as empresas os adotavam para serviços bancários, varejo e telecomunicações — setores onde as transações financeiras e a compliance regulatória exigem precisão absoluta.
Ao longo dos anos 1990 e início dos anos 2000, bancos de dados relacionais como Oracle, IBM DB2 e Microsoft SQL Server continuaram a refinar a forma como as garantias ACID eram implementadas, frequentemente usando técnicas como registro de gravação antecipada, bloqueios e controle de concorrência multiversão.
Esses métodos permitiram que as organizações processassem milhões de operações de banco de dados enquanto mantinham a consistência estrita.
Com o surgimento dos bancos de dados NoSQL na década de 2010, alguns questionaram se as garantias ACID poderiam ser preservadas em sistemas projetados para escala horizontal e alta disponibilidade. As primeiras plataformas NoSQL frequentemente relaxavam a consistência em favor do desempenho e da disponibilidade, levando à suposição de que a conformidade com ACID e a escalabilidade NoSQL eram mutuamente exclusivas.
No entanto, à medida que a demanda por integridade de dados em sistemas distribuídos cresceu, fornecedores como o MongoDB provaram que era possível oferecer suporte a transações com vários documentos e, ao mesmo tempo, manter o dimensionamento em vários nós.
Atualmente, as transações ACID continuam tão relevantes quanto sempre foram. Elas fornecem a base para manter a integridade dos dados em setores onde erros são inaceitáveis, desde transferências de contas bancárias até registros de saúde.
Ao mesmo tempo, plataformas modernas como o MongoDB estenderam as garantias do ACID a dados flexíveis e não estruturados e a operações complexas em clusters distribuídos. Essa combinação de confiabilidade e escalabilidade garante que os princípios ACID, definidos há mais de 40 anos, continuem a impulsionar o futuro do gerenciamento de bancos de dados.
O que são transações ACID?
Transações explicadas
Em seu nível mais básico, as transações de banco de dados são um grupo de operações de leitura e gravação de banco de dados que foram concluídas com sucesso de acordo com as definições do DBMS (por exemplo, critérios de transação definidos). Existem dois tipos principais de transações:
- Transações únicas: uma única transação se refere a uma série de uma ou mais operações de banco de dados resultando em uma ação, concluída com sucesso. Depois de concluída, a transação é aceita e pode ser encontrada em um log de transações. Um exemplo comum de uma única transação é a saída de dinheiro de um caixa eletrônico.
- Multintransações: uma multitransação, às vezes chamada de transação distribuída, consiste em várias transações interdependentes espalhadas por diferentes bancos de dados e sistemas (por exemplo, sistemas distribuídos). Os registros dessas transações também são encontrados em um log de transações. Um exemplo dessas transações inclui a transferência de dinheiro de uma conta para outra ou a emissão, por um empregador, de um crachá de segurança com foto para um novo funcionário.
É importante observar que algumas transações são necessárias para cumprir padrões rigorosos de integridade dos dados (por exemplo, os dados estão completos e corretos) e consistência dos dados (por exemplo, o valor é o mesmo em todas as tabelas/bancos de dados). Esse é geralmente o caso quando a responsabilidade fiduciária ou a conformidade regulatória está envolvida.
Os exemplos incluem bancos comerciais, corretagem de investimentos e acordos legais.
Nestas situações, a adesão padrão às definições do DBMS não é suficiente, e são necessárias transações ACID .
Transações ACID
ACID é um acrônimo que significa atomicidade, consistência, isolamento e durabilidade. As propriedades ACID, juntas, garantem que um conjunto de operações de banco de dados (agrupadas em uma transação) deixe o banco de dados em um estado válido, mesmo diante de erros inesperados.
Além disso, as transações ACID fornecem o nível de garantias transacionais exigidos por muitas agências regulatórias.
Abaixo está uma visão geral de cada elemento de transação ACID, bem como uma descrição de como um banco de dados de documentos NoSQL é capaz de lidar com esse elemento ACID. Para os fins deste artigo, o MongoDB Atlas será usado.
Atomicidade
A atomicidade garante que todos os comandos que compõem uma transação sejam tratados como uma unidade única e tenham sucesso ou falhem juntos. Isso é importante no caso de uma falha do sistema ou interrupção de energia, pois, se uma transação não foi totalmente processada, ela será descartada e o banco de dados manterá a integridade dos dados.
Como o MongoDB lida com a atomicidade
No MongoDB, uma operação de escrita é atômica no nível de um único documento, mesmo que a operação modifique vários documentos incorporados em um único documento.
Para situações que exigem automicidade de leituras e gravações em vários documentos (em uma única coleção ou várias coleções), o MongoDB oferece suporte a transações distribuídas, incluindo transações em conjuntos de réplicas e clusters fragmentados.
Consistência
A consistência garante que as alterações feitas em uma transação sejam propagadas por todo o sistema de banco de dados (por exemplo, nós) e estejam em conformidade com as restrições do DBMS. Se a consistência dos dados for afetada negativamente por uma transação que os deixe em um estado inconsistente, a transação inteira falhará.
Como o MongoDB lida com a consistência
O MongoDB oferece a flexibilidade de normalizar ou duplicar dados para otimizar os aplicativos. Se os dados forem duplicados no esquema, o desenvolvedor deverá decidir como manter os dados duplicados consistentes em várias coleções. Alguns aplicativos exigem que os dados duplicados se tornem consistentes imediatamente, enquanto outros aplicativos podem tolerar a leitura de dados obsoletos. Os exemplos estão ilustrados abaixo:
Nota: saiba mais sobre coerência de dados.
Isolamento
Cada transação é isolada das outras transações para evitar conflitos de dados. Isso também ajuda as operações de banco de dados em relação ao gerenciamento de várias entradas e transações de vários níveis.
Por exemplo, se dois usuários estiverem tentando modificar os mesmos dados (ou até mesmo a mesma transação), o DBMS usará um mecanismo chamado gerenciador de bloqueio para suspender os outros usuários até que as alterações feitas pelo primeiro usuário sejam concluídas.
Como o MongoDB lida com o isolamento
O MongoDB emprega uma técnica chamada isolamento de snapshot (por exemplo, cada transação parece operar em seu próprio snapshot do banco de dados obtido no início da transação). As transações podem ler dados do "snapshot" de dados confirmados no momento em que a transação começa, e quaisquer atualizações conflitantes farão a transação ser abortada.
Além disso, as transações MongoDB oferecem suporte a write concern no nível da transação. Os clientes podem definir um nível apropriado de read e write concerns, sendo o mais rigoroso o snapshot read concern combinado com o majority write concern. Majority write concern significa que as operações de gravação foram confirmadas de forma durável em uma maioria calculada dos nós que contêm dados (configurável pelo desenvolvedor).
Durabilidade
A durabilidade garante que, uma vez que a transação seja concluída e as alterações sejam gravadas no banco de dados, elas serão persistidas. Isso garante que os dados no sistema persistam mesmo em caso de falhas do sistema, como travamentos ou interrupções de energia. O conceito de durabilidade é um elemento-chave na confiabilidade dos dados.
Como o MongoDB lida com a durabilidade
O MongoDB cria um OpLog contendo a localização do disco e os bytes alterados para cada "gravação". Se houver um evento imprevisto (por exemplo, uma queda de energia) durante a gravação da transação, o OpLog poderá ser usado quando o sistema iniciar novamente para reproduzir quaisquer gravações que não tenham sido gravadas no disco antes do desligamento.
Além disso, as operações são alteradas antes de gravadas no OpLog para que sejam idempotentes e possam ser repetidas várias vezes. As transações, ou "gravações", são liberadas em disco aproximadamente a cada 60 segundos por padrão.
Por que as transações ACID são importantes?
As transações ACID ajudam a manter a integridade e a confiabilidade dos dados, ao mesmo tempo em que garantem que os dados vitais que estejam sujeitos à regulamentação governamental ou do setor (por exemplo, conta bancária, portfólio de ações) atendam aos padrões exigidos. Além disso, ACID compliance geralmente é um pré-requisito para implementar a replicação de dados e alcançar alta disponibilidade em sistemas de banco de dados de dados distribuídos.
Exemplo de transação ACID no DBMS
Usando o banco de dados de documentos NoSQL MongoDB Atlas, aqui está um exemplo de como as transações multidocumento ACID são tratadas e como as transações ACID garantem a conformidade com os padrões mínimos das propriedades ACID.
Transações ACID multidocumento
Imagine que você está criando uma função para transferir dinheiro de uma conta bancária para outra, em que cada conta é seu próprio registro. Se o dinheiro for retirado com sucesso da conta de origem, mas nunca creditado na conta de destino, um grave problema de contabilidade foi criado. Por outro lado, se a conta de destino for creditada, mas a conta de origem nunca for debitada, outro grave problema de contabilidade ocorrerá.
Essas duas operações de gravação precisam acontecer ou não acontecer para manter o sistema e seus dados consistentes. Além disso, isso significa que se qualquer comando na transação falhar, o banco de dados de dados deve voltar atrás (por exemplo, desfazer) todas as mudanças que tinha gravado no decurso da transação.
Nota: para saber mais, acesse o repositório do GitHub de início rápido do Node.js para obter uma cópia da amostra de código completa e executá-la por conta própria.
Impactos a lembrar
Ao lidar com transações multidocumento em um sistema distribuído, lembre-se de que há uma sobrecarga de desempenho que pode afetar restrições de recursos e metas de desempenho. Além disso, como o banco de dados precisa “bloquear” os recursos envolvidos para evitar que gravações simultâneas interfiram umas nas outras (por exemplo, se uma transação falhar), outros clientes que estejam tentando gravar dados podem ficar esperando a conclusão da transação, o que pode afetar a latência da aplicação e a experiência do usuário.
Como as transações ACID funcionam no MongoDB?
O modelo de documento do MongoDB permite que dados relacionados sejam armazenados juntos em um único documento. O modelo de documento, combinado com atualizações de documento atômicas, elimina a necessidade de transações na maioria dos casos de uso. No entanto, há casos em que verdadeiras transações do MongoDB com vários documentos e multicoleções são a melhor escolha.
As transações do MongoDB funcionam de forma semelhante às transações em outros bancos de dados. Para usar uma transação, inicie uma sessão do MongoDB por meio de um driver. Em seguida, use essa sessão para executar seu grupo de operações de banco de dados. Você pode executar qualquer uma das operações CRUD (criar, ler, atualizar e excluir) em vários documentos, coleções e fragmentos.
Para obter amostras de código específicas sobre como implementar transações, consulte os seguintes Inícios Rápidos:
- Transações ACID multidocumento no MongoDB com Golang
- Transações ACID multidocumento no MongoDB com Java
- Transações ACID de vários documentos no MongoDB com Node.js
- Transações ACID multidocumento no MongoDB com Python
Visite a documentação dos drivers do MongoDB para guias específicos de linguagem para cada uma das linguagens oficialmente suportadas pelo MongoDB. Você também pode visualizar uma lista de melhores práticas de transações e considerações de produção.
Quando posso usar transações multidocumento do MongoDB?
Os aplicativos que exigem transações normalmente têm casos de uso em que valores são trocados entre diferentes partes. Esses são normalmente aplicativos do "Sistema de Registro" ou da "Linha de negócios".
Exemplos de aplicações que podem se beneficiar de transações com vários documentos incluem:
- Sistemas que movimentam fundos de uma conta para outra (por exemplo, aplicativos bancários, sistemas de processamento de pagamentos, plataformas de trading).
- Cadeia de suprimentos e sistemas de reservas onde a propriedade de bens e serviços é transferida de uma parte para outra.
- Sistemas de faturamento que armazenam informações em registros detalhados, bem como registros resumidos.
Quais são as melhores práticas para transações no MongoDB?
Em geral, é recomendado modelar os dados de modo que os dados acessados juntos sejam armazenados juntos. Quando os dados são modelados dessa maneira, não apenas um melhor desempenho será alcançado, mas também não serão necessárias transações.
Para aplicativos que exigem transações, siga estas melhores práticas:
- Divida as transações de longa duração em partes menores para que não excedam o tempo limite padrão de 60 segundos. (Observe que esse tempo limite pode ser estendido.) Garanta que as operações nas transações usem índices para que sejam executadas rapidamente.
- Limita cada transação a 1.000 modificações de documentos.
- Garanta que as read e write concerns adequadas sejam configuradas (observe que, a partir da versão 5.0, o MongoDB adota como padrão a majority write concern necessária).
- Adicione tratamento de erro apropriado e repita as transações que falham devido a erros transitórios.
- Lembre-se do custo de desempenho das transações que afetam vários fragmentos. Para obter mais informações sobre essas práticas recomendadas, consulte o white paper Multi-Document ACID Transactions on MongoDB, bem como a documentação do MongoDB sobre transações.