Início > Uncategorized > O teorema CAP

O teorema CAP

Quando se está a falar ou a pensar em sistema de dados distribuídos, acaba-se sempre por abordar os tópicos relacionados com o teorema CAP. Estamos perante uma das mais brilhantes ideias para ajudar a explicar de forma simples algo muito complexo.

Mas o que é o teorema CAP?

O teorema CAP apresenta três requisitos que influenciam mutuamente o desenho e instalação de sistemas de dados distribuídos: consistência, disponibilidade e tolerância a falhas (Consistency, Availability, and Partition tolerance), sendo que, este foi descoberto por Eric Brewer e foi apresentado pela primeira vez em 19 de Julho de 2000 no simpósio da ACM intitulado “Principles of Distributed Computing”.

A grande revelação de Brewer é que não é possível que um sistema de dados distribuído preencha estes 3 requisitos em simultâneo.

Deste teorema resultou um extenso trabalho de observação do comportamento dos sistema da Inktomi e veio revolucionar a arquitectura dos sistemas distribuídos de dados em grande escala, nomeadamente a arquitectura dos sistemas da Amazon, eBay e Twitter entre muitas outras.

 

Ilustração 1 – Teorema CAP

Consistência

Consistência é a característica que descreve como e se o estado de um sistema fica consistente após uma operação. Num sistema distribuído de dados, isto, normalmente significa que uma vez escrito um registo, este fica disponível para ser utilizado imediatamente.

Um sistema de dados distribuído consistente é classificado como fortemente consistente ou como tendo alguma forma fraca de consistência. O exemplo mais conhecido de um sistema fortemente consistente são os sistemas que implementam as características ACID (Atomicidade, Consistência, Isolamento e Durabilidade), implementado pela maioria das bases relacionais. Na outra extremidade temos as bases de dados BASE (Basic Availability, Soft-state, Eventual consistency).

Na maioria das vezes, a consistência fraca é fornecida sob a forma de consistência eventual, o que significa que a base de dados pode atingir um estado consistente. Nestas incluem-se normalmente as bases de dados em que os dados são replicados. Apenas existe a garantia que a versão mais recente de um registo está consistente num nó, sendo que versões antigas deste registo podem ainda existir em outros nós, eventualmente todos os nós têm a última versão.

Disponibilidade

Refere-se à concepção e implementação de um sistema de modo que seja assegurado que este permanece activo durante um determinado período de tempo. Neste contexto, significa que um sistema é tolerante a falhas de software/hardware e normalmente também permanece disponível durante a actualização de sofware e hardware.

Um das formas mais comuns de implementar esta característica nas bases de dados tradicionais, é recorrendo à replicação master-master. Assim a falha/actualização de um nó não implica a indisponibilidade do sistema.

Note-se que disponibilidade não é só uma protecção contra falhas de hardware/software, mas também uma forma de obter balanceamento de carga e operações concorrentes, especialmente para operações de leitura.

Um sistema pode ser mais ou menos disponível num período de tempo. No entanto num determinado momento T está ou não está disponível.

Tolerância a falhas

Tolerância a falhas refere-se à capacidade de um sistema continuar a operar na presença de uma falha de rede. Por exemplo, se tivermos uma base de dados a funcionar em 80 nós em cima de 2 racks e ligação entre os dois racks falhar, a base de dados fica particionada. Se o sistema é tolerante a falhas, então a base de dados é capaz ainda de fornecer operações de leitura/escrita enquanto particionada. Em caso negativo, normalmente. Implica que cluster fica completamento inutilizável ou então apenas fornece operações de leitura.

Teorema CAP aplicado no mundo real

Mas que base de dados tem estas características? Seguidamente segue uma lista exemplo de algumas bases de dados que implementam alguns dos requisitos do teorema CAP.

CAp – Normalmente as bases de dados tradicionais relacionais, ou seja: MS SQL, DB2, Oracle 11G, Postgresql. Em caso de falha da rede ou de grande latência, elas não consegue responder a todos os pedidos. (Existem formas de resolver este problema, mas nenhum é perfeito).

cAP –  As bases de dados NOSQL, por exemplo: Cassandra, MongoB, Voldemort). Estes são sistemas altamente tolerantes a falhas (assumindo que existem um grande numero de servidores a suportar o sistema) e elas fornecem disponibilidade também, sendo que normalmente seguem o modelo de consistência eventual.

CaP – Esta não é uma opção atractiva. O sistema não vai dar garantias de estar sempre disponível. Um exemplo é um sistema em que um nodo falha e os outros não podem responder aos pedidos.

Conclusão

O teorema CAP não se aplica apenas a bases de dados. Mesmo uma simples aplicação que guarda o estado de uma sessão em objectos tem o mesmo problema. Existem muitas “soluções” para replicar os objectos de sessão e fazer com que os dados de sessão tenham alta disponibilidade, mas estas sofrem basicamente dos mesmos problemas.

Reconhecer quais dos requisitos do teorema CAP são importante para o nosso sistema é o primeiro passo para construir com sucesso um sistema distribuído, escalável e com alta disponibilidade.

Categorias:Uncategorized
  1. 2013/10/27 às 02:11

    Paulo, parabéns pelo seu texto! Ficou simples, objetivo e de facil entendimento, inclusive, trouxe as exatas informações que preciso para concluir meu trabalho!

    Sera que voce poderia me pasar o Ano de publicação do seu texto?

    Muito Obrigado e, novamente, Parabéns!!!

  1. No trackbacks yet.

Deixe uma Resposta

Preencha os seus detalhes abaixo ou clique num ícone para iniciar sessão:

Logótipo da WordPress.com

Está a comentar usando a sua conta WordPress.com Terminar Sessão /  Alterar )

Google photo

Está a comentar usando a sua conta Google Terminar Sessão /  Alterar )

Imagem do Twitter

Está a comentar usando a sua conta Twitter Terminar Sessão /  Alterar )

Facebook photo

Está a comentar usando a sua conta Facebook Terminar Sessão /  Alterar )

Connecting to %s

%d bloggers like this: