O Teorema CAP é um teorema elaborado pelo cientista da computação Eric Brewer em 1998. Segundo esse teorema, nenhum banco de dados distribuído consegue garantir as seguintes três propriedades simultaneamente: Consistência, Disponibilidade e Tolerância a Particionamento.
A consistência é a propriedade em que toda operação de leitura de um dado entrega a atualização MAIS RECENTE dele OU UM ERRO. Não importa se ocorreu uma atualização desse dado há 1 milissegundo atrás.
A disponibilidade é a propriedade em que todas as operações (leitura ou escrita) são bem sucedidas, sem que o sistema retorne erro algum.
A tolerância ao particionamento é a propriedade em que o sistema deve continuar funcionando mesmo que a comunicação entre as partições de um cluster apresente falha.
Segundo Brewer, a maneira mais fácil de entender o CAP é pensar em dois nós (ou instâncias) em lados opostos de uma partição (ou cluster). Permitir que ao menos uma instância realize atualizações vai resultar na inconsistência nos nós da partição, prejudicando "C". Se a consistência for importante em um sistema distribuído, um lado da partição deve se apresentar como "indisponível", prejudicando a disponibilidade (A). Dessa forma, só é possível garantir consistência e disponibilidade simultaneamente se ambos os lados da partição se comunicarem sem falha, 24/7, prejudicando a tolerância a particionamento (P). Em conclusão, só é possível priorizar 2 dessas 3 propriedades ao escolher um sistema de banco de dados.
Porém, como eu disse anteriormente, esse teorema foi elaborado em 1998. Desde então, muita coisa mudou, muitas tecnologias novas surgiram, e em 2012 Brewer enumerou uma série de motivos pelos quais o teorema CAP pode ser errôeno:
As propriedades do CAP não são binárias, mas contínuas. Um sistema distribuído pode garantir 100% disponibilidade e tolerância a particionamento enquanto provê uma consistência de 90%, ou garantir consistência e tolerância a particionamento de 100% com disponibilidade de 90%.
Outro ponto é que com a evolução dos serviços cloud, os sistemas de gerenciamento de partições tornaram-se muito melhores, minimizando a ocorrência de erros de comunicação entre partições. Então, teoricamente, os arquitetos precisariam priorizar "C" ou "A".
Outra coisa óbvia é que, em um mundo de microserviços, cada sistema-produto pode escolher um banco de dados diferente. Não existe sistema 100% CA, CP ou AP. A priorização dessas diferentes propriedades pode variar de acordo com a granularidade dos serviços de negócio.
Dito isto, não existe bala de prata para desenvolver sistemas em termos de tecnologia de banco de dados; é necessário analisar os requisitos de negoćio para entender o que é mais importante e, com base nesses requisitos, escolher a tecnologia que atende melhor.
É claro, também, que existem sistemas na vida real que priorizam algumas propriedades, mais do que as outras. Gostaria de passar uma a uma e citar exemplos a seguir.
Exemplos de sistemas que priorizam consistência (C):
- Saldo e extrato bancário;
- Gerenciamento de estoque;
- Reserva de viagens;
- Prontuários médicos.
Exemplos de sistemas que priorizam disponibilidade (A):
- Redes sociais;
- Mensageiros em tempo real;
- Monitoramento;
- Streaming de mídia;
- Comércio eletrônico.
Exemplos de sistemas que priorizam tolerância a particionamento (P):
- IoT;
- Monitoramento;
- Armazenamento em nuvem;
- Colaboração em tempo real.
Existem também os sistemas de gerenciamento de banco de dados (SGBDs) que priorizam duas das três propriedades do teorema CAP, podendo se enquadrar em CA, CP ou AP. Para finalizar, gostaria de citar exemplos de cada categoria.
Categoria CA:
- Oracle;
- SQL Server;
- PostgreSQL.
Categoria CP:
- MongoDB;
- CockroachDB;
- FaunaDB.
Categoria AP:
- Apache Cassandra;
- DynamoDB;
- Apache HBase.
É importante salientar que, embora alguns SGBDs priorizem determinados pares de propriedades, eles podem variar em como eles implementam essas propriedades e como equilibram os trade-offs com a propriedade prejudicada.
Top comments (0)