Teorema de CAP: como escolher melhor o seu banco de dados NoSQL

Aprenda sobre o Teorema de CAP e o que deve ser considerado na escolha de um banco de dados NoSQL.


Existem diversas opções de bancos NoSQL hoje em dia, o que torna mais difícil a nossa escolha e nos faz pensar quais são as principais considerações e trade-offs envolvidos para a decisão. Nosso objetivo com este artigo é apresentar uma forma mais acurada de fazer a sua escolha, para isso, iremos nos basear em um famoso teorema, chamado de teorema de Brewer ou simplesmente teorema de CAP.

Você já deve ter ouvido falar naquele ditado onde se diz que um serviço nunca pode ser bom, barato e rápido ao mesmo tempo, ou seja, se ele for bom e rápido certamente não será barato, se ele for barato e rápido, certamente não será bom, e por aí vai. O teorema de CAP segue exatamente a mesma ideia, porém analisando três propriedades diferentes, onde se abre mão de uma delas para ter as outras duas.

Segundo o teorema as três propriedades desejáveis em um sistema de armazenamento de dados distribuído são: consistência, disponibilidade e tolerância ao particionamento. Vamos analisar cada uma delas mais de perto, vejamos:

 

  • Consistência:significa que todos os clientes têm acesso ao mesmo dado no mesmo instante, não importa em qual nó da rede distribuída eles estejam conectados.

  • Disponibilidade:significa que qualquer cliente que faça uma requisição (escrita/leitura dos dados) recebe uma resposta, mesmo que seja uma resposta que não represente o estado mais recente dos dados.

  • Tolerância a particionamentos:uma partição é uma quebra de comunicação no sistema distribuído, uma perda de conexão ou delay temporário entre dois ou mais nós. O que a tolerância ao particionamento significa é que, mesmo que haja uma perda ou atraso de comunicação entre nós, o sistema continuará ativo e em funcionamento.

 

Para ficar claro a relação entre as propriedades é comum utilizarmos o esquema na imagem abaixo, também adicionamos alguns dos bancos mais populares como exemplo:

 

Um dos objetivos primários do NoSQL é de suportar escalabilidade horizontal, e para isso, você precisa de uma forte tolerância a particionamentos, o que acarreta em abrir mão de consistência ou disponibilidade, tipicamente os bancos NoSQL fazem isso afrouxando as habilidades relacionais e/ou a semântica transacional.

Embora possamos discutir um banco de dados distribuído que seja CD em teoria ele não poderia existir, no entanto, alguns bancos de dados relacionais, como PostgreSQL, oferecem consistência e disponibilidade e podem ser implantados em vários nós usando replicação, note que partição e replicação são coisas diferentes, não iremos aprofundar essa discussão aqui.

Além dessas três propriedades, no caso de bancos NoSQL ainda existe a diferença entre o modelo de dados utilizado, que pode ser tipicamente orientado a documentos, relacional, chave e valor, orientado a grafos ou orientado a colunas, porém o detalhamento disso é assunto para outro artigo, se você ainda não tem conhecimento ou não ouviu falar indico esta fonte aqui.

No que tange a escolha do nosso banco de dados NoSQL, o que o teorema nos fornece é um guia, onde em posse do conhecimento da regra de negócio, e dado um modelo de dados que atenda a ela, optamos por afrouxar a nossa propriedade de consistência ou disponibilidade para fazer a nossa escolha. Por exemplo, considerando dois exemplos de bancos que são orientados a documento: MongoDB e CouchDB, se a sua aplicação tolera um grau de inconsistência temporária então o CouchDB pode ser uma escolha mais adequada, e assim por diante. O importante aqui é chamar a sua atenção para a sensibilidade e usabilidade da aplicação acerca destes pontos que podem ser muito relevantes futuramente.

Por fim, devemos ressaltar que esse teorema não se aplica apenas a gerenciadores de banco de dados e sim a maior parte dos sistemas, em especial sistemas distribuídos. Outro ponto importante é que não quer dizer que você irá perder totalmente uma das propriedades escolhendo as outras duas, é mais como um cabo de guerra, onde um dos lados é mais forte e o outro mais fraco, dessa forma você têm serviços onde duas das propriedades são irrefutáveis mas a outra pode ser mais flexível, se tornando indisponível temporariamente ou sendo contornada de outras maneiras.

Tenho certeza que este é um assunto que renderá ainda mais postagens aqui no blog. Se você gostou deste artigo compartilhe com os amigos e se inscreva em nossa newsletter para acompanhar semanalmente os conteúdos, até a próxima pessoal!

 

Se Inscreva Na Nossa Newsletter Tenha Acesso Aos Melhores Artigos