O que é o teorema CAP?

O teorema CAP diz que um sistema distribuído pode fornecer apenas duas de três características desejadas:
consistência,disponibilidade e tolerância a partições (o "C", "A" e "P" no CAP).

Você já viu um anúncio de um paisagista, pintor de casas ou outro profissional que começa com o título, "Bom, rápido e barato: escolha dois"? O teorema CAP aplica uma lógica semelhante aos sistemas distribuídos.

Um sistema distribuído é uma rede que armazena dados em mais de um nó (máquinas físicas ou virtuais) ao mesmo tempo. Como todas as aplicações em nuvem são sistemas distribuídos, é essencial entender o teorema CAP ao projetar um aplicativo em nuvem para que você possa escolher um sistema de gerenciamento de dados que forneça as características das quais sua aplicação mais precisa.

O teorema CAP também é chamado de Teorema de Brewer, porque foi primeiramente avançado pelo Professor Eric A. Brewer durante uma palestra que ele deu sobre computação distribuída em 2000. Dois anos depois, os professores de MIT Seth Gilbert e Nancy Lynch publicaram uma prova de "Conjectura Brewer".

Vamos dar uma olhada detalhada nas três características do sistema distribuído às quais o teorema CAP se refere.

Consistência

Consistência significa que todos os clientes veem os mesmos dados ao mesmo tempo, independentemente do nó ao qual se conectam. Para que isso aconteça, sempre que os dados forem gravados em um nó, eles deverão ser imediatamente encaminhados ou replicados para todos os outros nós no sistema antes que a gravação seja considerada "sucesso".

Disponibilidade

Disponibilidade significa que qualquer cliente que faça uma solicitação de dados recebe uma resposta, mesmo que um ou mais nós estejam inativos. Outra forma de afirmar isso: todos os nós em funcionamento no sistema distribuído retornam uma resposta válida para qualquer solicitação, sem exceção.

Tolerância à partição

Uma partição é uma quebra de comunicação dentro de um sistema distribuído — uma conexão perdida ou temporariamente atrasada entre dois nós. Tolerância de partição significa que o cluster deve continuar funcionando apesar de qualquer número de quebras de comunicação entre nós no sistema.

Bancos de dados NoSQL são ideais para aplicações em redes distribuídas. Diferente de seus equivalentes SQL (relacionais) escaláveis verticalmente, os bancos de dados NoSQL são escaláveis horizontalmente e distribuídos por design. Eles podem escalar rapidamente em uma rede crescente composta por vários nós interconectados (Consulte "SQL versus bancos de dados NoSQL: qual é a diferença?" para obter mais informações).

Atualmente, os bancos de dados NoSQL são classificados com base nas duas características CAP compatíveis:

• Banco de dados CP: um banco de dados CP oferece consistência e tolerância à partição em detrimento da disponibilidade. Quando uma partição ocorre entre quaisquer dois nós, o sistema tem que desligar o nó não consistente (ou seja, torná-lo indisponível) até que a partição seja resolvida.
  
  
• Banco de dados AP: um banco de dados AP oferece disponibilidade e tolerância de partição em detrimento da consistência. Quando ocorre uma partição, todos os nós permanecem disponíveis, mas aqueles na extremidade errada de uma partição podem retornar uma versão mais antiga dos dados do que os outros. (Quando a partição é resolvida, os bancos de dados AP normalmente sincronizam novamente os nós para corrigir todas as inconsistências no sistema.)
  
  
• Banco de dados CA: um banco de dados CA oferece consistência e disponibilidade em todos os nós. Não é possível fazer isso se houver uma partição entre quaisquer dois nós no sistema, no entanto, e, portanto, não pode fornecer tolerância a falhas.

Nós listamos o tipo de banco de dados CA por um motivo — em um sistema distribuído, as partições não podem ser evitadas. Portanto, embora possamos discutir um banco de dados distribuído por CA em teoria, para todos os efeitos práticos, um banco de dados distribuído por CA não pode existir. Isto não significa que não pode ter uma base de dados CA para a sua aplicação distribuída se precisar de uma. Muitos bancos de dados relacionais, como o PostgreSQL, oferecem consistência e disponibilidade e podem ser implementados em vários nós usando replicação.

O MongoDB é um sistema de gerenciamento de banco de dados NoSQL popular que armazena dados como documentos BSON (JSON binário). É frequentemente utilizado para big data e aplicações em tempo real que rodam em diferentes locais. Em relação ao teorema CAP, o MongoDB é um armazenamento de dados CP. Ele resolve partições de rede mantendo a consistência, enquanto compromete a disponibilidade.

O MongoDB é um sistema single-master, ou seja, cada conjunto de réplicas pode ter apenas um nó primário que recebe todas as operações de gravação. Todos os outros nós no mesmo conjunto de réplicas são nós secundários que replicam o log de operações do nó primário e o aplicam ao seu próprio conjunto de dados. Por padrão, os clientes também leem do nó primário, mas podem especificar uma preferência de leitura que permite ler dos nós secundários.

Quando o nó primário ficar indisponível, o nó secundário com o registo de operação mais recente será eleito como o novo nó primário. Quando todos os outros nós secundários alcançam o novo mestre, o cluster fica disponível novamente. Como os clientes não podem fazer solicitações de gravação durante esse intervalo, os dados permanecem consistentes em toda a rede.

O Apache Cassandra é um banco de dados NoSQL de código aberto mantido pela Apache Software Foundation. É um banco de dados de colunas amplas que permite armazenar dados em uma rede distribuída. No entanto, ao contrário do MongoDB, Cassandra tem uma arquitetura sem mestre e, como resultado, tem vários pontos de falha, em vez de um único.

Em relação ao teorema CAP, o Cassandra é um banco de dados AP — ele oferece disponibilidade e tolerância à partição, mas não consegue fornecer consistência o tempo todo. Como o Cassandra não tem um nó mestre, todos os nós devem estar disponíveis continuamente. No entanto, o Cassandra fornece consistência eventual, permitindo que os clientes gravem em qualquer nó a qualquer momento e reconciliem as inconsistências o mais rápido possível.

Como os dados só se tornam inconsistentes no caso de uma partição de rede e as inconsistências são resolvidas rapidamente, o Cassandra oferece a funcionalidade de "reparo" para ajudar os nós a se aproximarem de seus pares. No entanto, a disponibilidade constante resulta em um sistema de alto desempenho que pode valer o trade-off em muitos casos.

Os microsserviços são componentes de aplicações fracamente acoplados e implantáveis de forma independente que incorporam sua própria stack (incluindo seu próprio banco de dados e modelo de banco de dados) e se comunicam entre si por meio de uma rede. Como você pode executar microsserviços em servidores de nuvem e data centers locais, eles se tornaram altamente populares para aplicações híbridas e multinuvem.

Compreender o teorema CAP pode ajudá-lo a escolher o melhor banco de dados ao projetar uma aplicação baseada em microsserviços executada em vários locais. Por exemplo, se a capacidade de iterar rapidamente o modelo de dados e escalonar horizontalmente for essencial para sua aplicação, mas você puder tolerar a consistência eventual (em vez da estrita), um banco de dados AP como o Cassandra ou o Apache CouchDB poderá atender aos seus requisitos e simplificar a implementação. Por outro lado, se sua aplicação depende muito da consistência dos dados, como em uma aplicação de comércio eletrônico ou em um serviço de pagamento, você pode optar por um banco de dados relacional como o PostgreSQL.