Arquitetura de Software: O Teorema CAP
Tags: ptbr, webdev, architecture, codequality
Published: 2019-10-06 02:06:45

## Sistemas de gerenciamento de dados distribuídos

No passado, quando queríamos armazenar mais dados ou aumentar nosso poder de processamento, a opção comum era [escalar verticalmente](https://en.wikipedia.org/wiki/Scalability#Vertical) (obter máquinas mais potentes) ou otimizar ainda mais a base de códigos existente. No entanto, com os avanços no processamento paralelo e nos sistemas distribuídos, é mais comum [expandir horizontalmente](https://en.wikipedia.org/wiki/Scalability#Horizontal) ou ter mais máquinas para executar a mesma tarefa em paralelo. Já podemos ver várias ferramentas de manipulação de dados no projeto Apache, como Spark, Hadoop, Kafka, Zookeeper e Storm. No entanto, para escolher efetivamente a ferramenta certa, é necessário uma idéia básica do [Teorema CAP](https://pt.wikipedia.org/wiki/Teorema_CAP). O Teorema CAP é um conceito que um sistema distribuído pode ter apenas 2 dos 3: **consistência**, **disponibilidade** e **partição (tolerante a falhas)**.

![](https://miro.medium.com/max/888/1*WPnv_6sG9k4oG3S1A09MDA.jpeg)
_Imagem 00_

O Teorema CAP é muito importante no mundo do Big Data, especialmente quando precisamos fazer trocas entre os três, com base em nosso caso de uso. Neste blog, tentarei explicar cada um desses conceitos e os motivos da troca. Evitarei usar exemplos específicos, pois os sistemas estão sempre evoluindo rapidamente.

# Partição (_Partition Tolerance_)

![](https://miro.medium.com/max/1624/1*qVoJNWH1osbrnOizRivF1A.png)
_Imagem 01_

Essa condição indica que o sistema continua em execução, apesar do número de mensagens atrasadas pela rede entre os nós. Um sistema tolerante a partições pode suportar qualquer quantidade de falha na rede, que não resulta em falha de toda a rede. Os registros de dados são replicados suficientemente em combinações de nós e redes para manter o sistema ativo por interrupções intermitentes. Ao lidar com sistemas distribuídos modernos, a tolerância a partição não é uma opção, é uma necessidade! Portanto, temos que negociar entre consistência e disponibilidade.

# Consistência (_High Consistency_)

![](https://miro.medium.com/max/1920/1*UnG2G7_h0kqI9IHtnUk3qg.png)
_Imagem 02_

Essa condição indica que todos os nós veem os mesmos dados ao mesmo tempo. Simplificando, a execução de uma operação de leitura, retornando o valor da operação de gravação mais recente fazendo com que todos os nós retornem os mesmos dados. Um sistema tem consistência se uma transação começa com o sistema em um estado consistente e termina com o sistema em um estado consistente. Nesse modelo, um sistema pode (e faz) mudar para um estado inconsistente durante uma transação, mas a transação inteira é revertida se houver um erro durante qualquer estágio do processo. Na _Imagem 02_ temos registros diferentes ("Bulbasaur" e "Pikachu") em diferentes timestamps. A saída na terceira partição é "Pikachu", a entrada mais recente. No entanto, os nós precisarão de tempo para atualizar e não estarão disponíveis na rede com tanta frequência.

# Disponibilidade (_High Availability_)

![](https://miro.medium.com/max/1870/1*ABrjUrZAY6V1hEkFPYvC7A.png)
_Imagem 03_

Essa condição afirma que toda solicitação obtém uma resposta em caso de êxito / falha. Atingir a disponibilidade em um sistema distribuído requer que o sistema permaneça operacional 100% do tempo. Todo cliente recebe uma resposta, independentemente do estado de qualquer nó individual no sistema. Essa métrica é trivial de medir: você pode enviar comandos de leitura / gravação ou não pode. Portanto, os bancos de dados são independentes do tempo, pois os nós precisam estar disponíveis online o tempo todo. Isso significa que, ao contrário do exemplo anterior, não sabemos se "Pikachu" ou "Bulbasaur" foi adicionado primeiro. A saída pode ser uma delas. Por isso, a alta disponibilidade não é viável ao analisar dados de streaming em alta frequência.

# Conclusão

Os sistemas distribuídos nos permitem atingir um nível de capacidade e disponibilidade de computação que simplesmente não estavam disponíveis no passado. Nossos sistemas têm maior desempenho, menor latência e quase 100% de tempo de atividade em data centers que abrangem todo o mundo. O melhor de tudo é que os sistemas atuais são executados em hardware comum que é facilmente obtido e configurável a custos acessíveis. No entanto, há um preço. Os sistemas distribuídos são mais complexos que os de rede única. É necessário entender a complexidade incorrida nos sistemas distribuídos, fazer as trocas apropriadas para a tarefa em questão (CAP) e selecionar a ferramenta certa para o trabalho com a escala horizontal.

# Créditos

- [CAP Theorem and Distributed Database Management Systems](https://towardsdatascience.com/cap-theorem-and-distributed-database-management-systems-5c2be977950e), escrito originalmente por [Syed Sadat Nazrul](https://twitter.com/ssnazrul1)