Arquitetura de Software: O Teorema CAP

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 (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 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. 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).

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)

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)

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)

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, escrito originalmente por Syed Sadat Nazrul