[Portuguese Only] Princípios de funcionamento ACID vs BASE nos bancos de dados

Quando os bancos de dados relacionais foram idealizados, um dos conceitos adotados foi o conceito “ACID”, que é um acrônimo de 4 características, que acredita-se que os bancos de dados precisem possuir: 

• Atomicity
• Consistency
• Isolation
• Durability 

Estas propriedades, juntas, fazem com que um banco de dados relacional seja seguro e confiável para a maioria dos sistemas:

Atomicity

O princípio da atomicidade garante que uma transação seja tratada como algo indivisível (A “não” e TOMO “divisão”).

O termo átomo surgiu cerca de 500 anos antes de cristo, quando o filósofo grego Demócrito conjecturava sobre a divisão da matéria em porções cada vez menores, até que não pudesse mais ser dividida.

Quando aplicado a transações em bancos de dados, esse conceito foi incorporado de forma que uma transação composta de múltiplas instruções não possa ser dividida. Imagine transferir R$ 20 da conta do João para a conta da Maria. Se esta transação fosse executada parcialmente perderíamos o dinheiro do João ou criaríamos dinheiro na conta da Maria, gerando um problema. Então, o banco precisa garantir que as duas operações ocorram com sucesso, ou que nenhuma delas ocorra. 

Consistency

Pelo princípio da consistência, se um banco de dados é considerado consistente antes de uma transação, ele deverá continuar consistente após a transação. Se imaginarmos o exemplo anterior, onde João paga R$ 20 para a Maria, a soma do saldo do João com a Maria, juntos, não podem se alterar após uma transação, já que tiramos de um e damos ao outro. 

Isolation

O princípio do isolamento deve garantir que, em uma situação com múltiplas transações ocorrendo simultaneamente, uma não interfira na outra, de forma que o resultado de todas as transações, independentemente de serem executadas em paralelo ou sequencialmente, seja o mesmo. 

Durability 

O princípio da durabilidade indica que, assim que uma transação é encerrada (commit), o seu efeito não seja perdido, mesmo em casos de falha de software ou de hardware.

Estes princípios são a alma do banco de dados e, graças a eles, os databases são tão confiáveis para a manipulação de informações.

Porém, para que eles funcionem adequadamente, precisamos impor regras e limites, como os conceitos de lock e constraints de PK e FK.

Por conta destes limites, dependendo da modelagem utilizada, algumas aplicações podem apresentar problemas de desempenho que inviabilizam determinados sistemas.

Pensando nisso e tentando resolver estes problemas de performance, criou-se um relaxamento destas regras que foram “criativamente” chamadas de BASE, fazendo uma analogia ao princípio do PH (ácido vs base), na química: 

• Basically Available
• Soft state
• Eventual consistency

Neste modelo, criado com o objetivo primário de aumentar o desempenho e disponibilidade, utiliza-se como artifício a distribuição de dados e múltiplos servidores, permitindo a escalabilidade horizontal. 

Porém isso acarreta problemas.

Eventual consistency 

O primeiro conceito que precisa ser entendido no modelo BASE é o conceito de “Consistência Eventual”. Para entender como isso funciona, vamos imaginar que um database possui 2 nós e que todo dado gravado em um dos nós é replicado para o outro.

Com esta configuração, passamos a ter duas opções de leitura da informação, dobrando o desempenho da leitura.

Porém, para não prejudicar o desempenho da escrita, a aplicação faz alterações em apenas um dos nós e, através de um processo independente, estas alterações são replicadas para o outro nó.

Como esta replicação não ocorre instantaneamente (não atômica), existe a possibilidade de que uma aplicação lendo a mesma informação a partir dos dois nós obtenha valores distintos, sendo considerados inconsistentes.

Entretanto, se uma informação não sofre alterações por algum tempo, podemos esperar que ao término da replicação, os dados fiquem iguais, voltando a ser consistentes.

Soft state 

O segundo conceito envolvido no modelo BASE é o conceito de “Soft State”.

Se imaginarmos os estados pelos quais uma transação passa, podemos ter períodos em que está ativa, em processo de finalização, sendo abortada ou concluída.

Seguindo o mesmo princípio, uma transação distribuída só pode ser considerada “concluída” quando de fato a alteração foi replicada para todos os nós.

Antes que isso ocorra, a leitura da informação a partir de todos os nós pode retornar dados inconsistentes e não temos como saber se: 1 – a alteração falhou no segundo nó ou 2 – devido à alta latência, o dado ainda não tenha sido replicado. 

Ao não podermos afirmar em que estado a transação se encontra, temos o “Soft State”

Basically Available 

O conceito de “Basicamente Disponível” tem a ver com a durabilidade e disponibilidade de uma alteração.

Em um banco de dados com dados distribuídos, todos os nós são considerados disponíveis e é possível que duas aplicações alterem uma determinada informação, simultaneamente, cada uma em um nó diferente.

Ao executar a replicação, o banco percebe uma inconsistência e precisa resolver o problema.

Imaginemos uma informação com conteúdo ‘A’, sendo alterada de ‘A’ para ‘B’, no nó 1, pela aplicação 1 e, simultaneamente, sendo alterada de ‘A’ para ‘C’, no nó 2, pela aplicação 2.

Qual deveria ser o resultado final, após a “convergência” dos dados? ‘B’ ou ‘C’?

Uma das informações deverá ser descartada, fazendo com que o dado não permaneça disponível.

Além disso, um dado recém inserido em um dos nós e ainda não replicado, também não pode ser lido através do outro nó, tornando-o temporariamente indisponível.

Dados estes problemas do modelo BASE, em que circunstâncias esse modelo poderia ser utilizado de forma segura? 

Um exemplo disso são os sistemas de pesquisa de conteúdo, como o Google e o Youtube. 

Ao pesquisar por uma informação, eventualmente podemos receber uma resposta incompleta. Porém, isso não afeta o funcionamento geral do sistema e não afeta de forma generalizada todas as informações na base. Podemos criar um número ilimitado de réplicas, aumentando em muito a capacidade de processamento e, uma eventual inconsistência ou perda de dados não impacta sensivelmente o resultado.

Embora os conceitos ACID e BASE não sejam indicadores de bancos de dados RELACIONAIS ou NoSQL, respectivamente, é comum encontrarmos bancos relacionais que implementam os princípios ACID e bancos NoSQL que implementam os princípios BASE.

Um exemplo de exceção a isso é o banco Oracle NoSQL que pode trabalhar com os dois modelos. Ele funciona com os princípios BASE na maior parte do tempo, devido a transações distribuídas, mas consegue efetuar transações com múltiplas operações em um mesmo nó, com o modelo ACID.