Propriedades dos Bancos de dados: BASE x ACID

Durante uma entrevista técnica, após o ‘live-code’ (teste de código), o entrevistador perguntou se poderia fazer uma última pergunta à candidata. ‘It’s just a fundamental question’, ele disse. Para os falantes da Língua Portuguesa ‘Fundamental’ pode soar como fundamental, essencial, crucial ou básico e até simples. Eram os momentos finais da entrevista, então parecia que era realmente aquela última e simples pergunta…mas poderia ser uma maneira de suavizar a percepção da candidata sobre a questão, para parecer menos intimidante, e avaliar se ela tinha conhecimento dos conceitos essenciais à posição. 

A pergunta: “How does the CAP theorem apply to SQL and NoSQL databases?”. 

A resposta da candidata foi algo como “I’m familiar with the CAP theorem, but we don’t work with NoSQL databases, so I don’t know much about them."

Existe um teorema de ciência da computação que quantifica as trocas inevitáveis (trade-offs). O teorema CAP de Eric Brewer diz que se você deseja consistência, disponibilidade e tolerância a partições, você tem que se contentar com apenas dois de três. 

1.Banco de dados relacionais: ACID

Atômicas: Tudo em uma transação deve ser bem-sucedido ou toda a transação é revertida.

Consistentes: Uma transação não pode deixar o banco de dados em um estado inconsistente.

Isoladas: As transações não podem interferir uma na outra.

Duráveis: Transações concluídas persistem, mesmo quando servidores reiniciam, etc.

Imagine que você está realizando uma transação bancária:

Transação: Você quer transferir R$ 100 da Conta A para a Conta B.

Passo 1: O banco reduz o saldo da Conta A em R$100.

Passo 2: O banco aumenta o saldo da Conta B em R$100.

Se o sistema falhar após o Passo 1, mas antes do Passo 2, você terá a situação em que o valor foi removido da Conta A, mas não adicionado à Conta B. Isso resulta em uma INCONSISTÊNCIA, onde o dinheiro "desapareceu".

É preciso existir propriedades que assegurem que  ou ambos os passos (débito e crédito) são realizados com sucesso, ou nenhum deles é realizado. Se algo der errado em qualquer uma das etapas (por exemplo, falha de sistema), a transação será revertida como se nada tivesse acontecido. Assim, o saldo da Conta A e da Conta B retornará ao estado original antes da transação.

Diante de uma interrupção, o sistema pode se tornar parcialmente ou totalmente indisponível para garantir que as transações financeiras sejam processadas de forma correta e consistente.

Isso significa que, em vez de arriscar uma operação inconsistente, o sistema bancário pode optar por negar temporariamente novos pedidos de transação ou operações, mantendo a integridade dos dados. Sacrificando a DISPONIBILIDADE. Isso reflete a escolha dos sistemas bancários de priorizar a consistência e a integridade dos dados, mesmo que isso implique em temporárias indisponibilidades, de acordo com o Teorema CAP. Nesse contexto, a Atomicidade assegura que uma transação deve ser bem-sucedida ou toda a transação é revertida.

2.Bancos de dados Não relacionais: BASE

Basic Availability /  Disponibilidade Básica

Soft-state / Estado Suave

Eventual consistency / Eventualmente consistente

Por outro lado, em sistemas como o de uma grande livraria online (como a Amazon), a Disponibilidade e a Tolerância a Partições podem ser priorizadas em detrimento da Consistência imediata. 

Por exemplo, em vez de mostrar o estoque em tempo real, o sistema pode usar dados em cache, exibindo o estoque disponível da última hora, em vez do número exato de livros no momento. Isso pode levar a uma situação onde dois clientes compram o último exemplar de um livro ao mesmo tempo. Nesse caso, o sistema pode preferir arriscar uma pequena inconsistência (como ter que notificar um dos clientes de que o item não está mais disponível) para garantir que o site permaneça disponível e rápido para todos os usuários ao redor do mundo. 

Esse tipo de sistema é conhecido por adotar o conceito de consistência eventual, onde os dados eventualmente se tornam consistentes, mas podem estar temporariamente fora de sincronia. Essa abordagem é comum em muitos sistemas NoSQL, que priorizam a escalabilidade e alta disponibilidade.

Em resumo,  bancos de dados SQL geralmente focam em consistência e disponibilidade, e frequentemente sacrificam a tolerância a partições, enquanto os bancos de dados NoSQL podem priorizar disponibilidade e tolerância a partições, muitas vezes aceitando consistência eventual.

REFERÊNCIAS:

Delta lake definitive guide - Dawn H. Liu, Mike Kleber, Danieli L. Guglielmo, Denny Lee

Designing Data-Intensive Applications -Martin Kleppmann

John D. Cook: “ACID Versus BASE for Database Transactions,” johndcook.com, July 6, 2009.

Bons estudos a todos.