Teorema CAP

menu icon

Teorema CAP

Neste guia, analisaremos o teorema CAP e a sua relevância no desenvolvimento de aplicativos distribuídos e na escolha de um armazenamento de dados NoSQL ou relacional.

O que é o teorema CAP?

Você já viu um anúncio de um paisagista, pintor de casa, ou algum outro comerciante que começa com a oferta "Barato, rápido e bom: escolha apenas duas dessas três opções"?

O teorema CAP aplica um tipo semelhante de lógica aos sistemas distribuídos, como um sistema distribuído que pode entregar apenas duas de três características desejadas: consistência, ,disponibilidade e tolerância de partição (o "C", ''A" e o "P" em CAP).

Um sistema distribuído é uma redeque armazena dados em mais de um nó (físico ou máquinas virtuais) ao mesmo tempo. Como todos os aplicativos em cloud são sistemas distribuídos, é essencial entender o teorema CAP ao projetar um aplicativo na cloud para que você possa escolher um sistema de gerenciamento de dados que entrega as características que seu aplicativo mais precisa.

O teorema CAP também é chamado de Teorema de Brewer, porque foi criado pela primeira vez pelo professor Eric A. Brewer durante uma palestra que deu sobre computação distribuída no ano 2.000. Dois anos depois, os professores do MIT Seth Gilbert e Nancy Lynch publicaram uma evidência da "Conjectura de Brewer".

Detalhes sobre o "CAP" do teorema CAP

Vamos fazer uma análise mais profunda sobre as três características do sistema distribuído ao qual o teorema CAP se refere.

Consistência

Consistência significa que todos os clientes veem os mesmos dados ao mesmo tempo, não importa em qual nó eles se conectem. Para que isso aconteça, sempre que os dados forem gravados em um nó, ele deve ser instantaneamente encaminhado ou replicado para todos os outros nós do sistema antes que a gravação seja considerada "bem-sucedida".

Disponibilidade

Disponibilidade significa que qualquer cliente que fizer uma solicitação de dados obterá uma resposta, mesmo que um ou mais nós estejam desativados. Ou seja, todos os nós em funcionamento no sistema distribuído retornam uma resposta válida para qualquer solicitação, sem exceção.

Tolerância de partição

A partição é uma quebra de comunicações dentro de um sistema distribuído, uma conexão perdida ou temporariamente lenta entre dois nós. Tolerância de partição significa que o cluster deve continuar a funcionar mesmo de ocorrer uma ou mais falhas de comunicação entre os nós no sistema.

Tipos de banco de dados NoSQL do teorema CAP

Bancos de dados NoSQL (não relacionais) são ideais para aplicativos de rede distribuída. Ao contrário de suas contrapartes SQL (relacionais) verticalmente escaláveis, os bancos de dados NoSQL são horizontalmente escaláveis e foram criados para serem distribuídos. É possível ajustar sua escala rapidamente em uma rede crescente consistindo em múltiplos nós interconectados. (Consulte "SQL vs. NoSQL Databases: What's the Difference?" para obter informações adicionais).

Atualmente, bancos de dados NoSQL são classificados com base nas duas características do CAP que oferecem:

  • Banco de dados CP: um banco de dados CP entrega consistência e tolerância de partição em detrimento da disponibilidade. Quando uma partição ocorre entre dois nós quaisquer, o sistema deverá desativar 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 entrega disponibilidade e tolerância de partição em detrimento da consistência. Quando ocorre uma partição, todos os nós permanecem disponíveis, exceto aqueles na extremidade errada de uma partição podem retornar uma versão mais antiga de dados do que outros. Quando a partição é resolvida, os bancos de dados AP geralmente ressincronizam os nós para corrigir todas as inconsistências no sistema.
  • Banco de dados CA: um banco de dados CA entrega consistência e disponibilidade em todos os nós. Porém, isso não é possível se houver uma partição entre dois nós quaisquer no sistema, no entanto, e, portanto, não poderá entregar tolerância a falhas.

Listamos este tipo por último pelo seguinte motivo: em um sistema distribuído, partições não podem ser evitadas. Por isso, enquanto podemos discutir um banco de dados distribuído CA em teoria, para todos os efeitos práticos, um banco de dados distribuído CA não pode existir. No entanto, isso não significa que você não pode ter um banco de dados CA para o seu aplicativo distribuído se você precisar de um. Muitos bancos de dados relacionais, como o PostgreSQL, entregam consistência e disponibilidade e podem ser implementados em múltiplos nós usando replicação.

O MongoDB e o Teorema CAP (CP)

O MongoDB é um sistema de gerenciamento de banco de dados NoSQL bastante conhecido que armazena dados como documentos BSON (JSON binário). É usado frequentemente para big data e aplicativos em tempo real em execução em vários locais diferentes. Relativo ao teorema CAP, o MongoDB é um armazenamento de dados CP, ou seja, resolve partições de rede mantendo a consistência, porém, não oferece disponibilidade.

O MongoDB é um sistema de mestre único, cada conjunto de réplica (link externo à IBM) 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ção do nó primário e aplicam ao seu próprio conjunto de dados. Por padrão, os clientes leem a partir do nó primário, mas também podem especificar uma preferência de leitura (link externo à IBM) que permite ler a partir de nós secundários.

Quando o nó primário ficar indisponível, o nó secundário com o log de operação mais recente será eleito como o novo nó primário. Uma vez que todos os outros nós secundários passam a acompanhar o novo mestre, o cluster torna-se disponível novamente. Como os clientes não podem fazer nenhuma solicitação de gravação durante este intervalo, os dados permanecem consistentes em toda a rede.

Cassandra e o Teorema PAC (AP)

O Apache Cassandra é um banco de dados NoSQL de código aberto mantido pela Apache Software Foundation. É um banco de dados de coluna ampla que permite armazenar dados em uma rede distribuída. No entanto, ao contrário do MongoDB, o Cassandra tem uma arquitetura sem mestre e, portanto, ela tem diversos pontos de falha, em vez de um único.

Em relação ao teorema CAP, o Cassandra é um banco de dados AP, ou seja, ele entrega disponibilidade e tolerância de partição, mas não consegue entregar consistência o tempo todo. Como o Cassandra não tem um nó principal, todos os nós devem estar disponíveis de maneira contínua. No entanto, o Cassandra fornece consistência eventual permitindo que os clientes escrevam para qualquer nós a qualquer momento e resolvam 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 rapidamente resolvidas, o Cassandra oferece Funcionalidade de "reparação" (link externo à IBM) para ajudar os nós a recuperar o atraso com relação aos seus pares. No entanto, a disponibilidade constante resulta em um sistema de alto desempenho, o que pode compensar em muitos casos.

Trabalhando com microsserviços

Os microsserviços são componentes de aplicativos implementáveis de forma independente e fracamente acoplados que possuem seus próprios recursos, incluindo seu próprio banco de dados e modelo de banco de dados, e se comunicam entre si por meio de uma rede. Como é possível executar microserviços em servidores de cloud e data centers locais, eles se tornaram altamente populares para os aplicativos híbridos e em multilcloud.

Entender o teorema CAP pode ajudá-lo a escolher o melhor banco de dados ao desenvolver um aplicativo com base em microsserviços que são executados a partir de vários locais. Por exemplo, se a capacidade de iterar rapidamente o modelo de dados e ajustar a escala horizontalmente é essencial para o seu aplicativo, mas você pode tolerar uma consistência eventual (em oposição a estrita), um banco de dados AP como o Cassandra ou Apache CouchDB pode atender aos seus requisitos e simplificar sua implementação. Por outro lado, se o seu aplicativo depender fortemente da consistência de dados, como em um aplicativo de eCommerce ou um serviço de pagamento, você pode optar por um banco de dados relacional como o PostgreSQL.

Teorema CAP e IBM Cloud

A IBM oferece uma grande variedade de serviços de banco de dados gerenciados. Além de sistemas de gerenciamento de banco de dados relacional, você também pode executar o MongoDB, Cloudant (outro armazenamento de dados AP distribuído), Elasticsearch, etcd e outras soluções de banco de dados na IBM Cloud.

Para conhecer toda a nossa seleção de banco de dados (sem compromisso), faça um IBMid e crie sua conta IBM Cloud.