Introdução

Há um bem conhecido ciência da computação teorema proposto por Eric Brewer que diz que para um banco de dados com dados distribuídos, você só pode promessa dois dos três seguintes qualidades:

• Consistência
• Disponibilidade
• Partição tolerância

Isso é muito abstrato e a terminologia não é exatamente intuitivo assim, neste artigo nós vamos fazer o nosso melhor para quebrar essa teoria para baixo do abstrato para o mais real world talk e exemplos. Este teorema pode fazer você pensar sobre sua arquitetura de banco de dados em termos do que sua aplicação realmente precisa e os sacrifícios que ele pode ter que fazer para alcançá-los.

definir a terminologia do CAP

vamos tirar algumas definições básicas do caminho para que possamos estar na mesma página enquanto avançamos falando sobre este teorema.

CAP-consistência, disponibilidade, tolerância de partição

• consistência – todos os seus servidores de dados têm os mesmos dados, então você pode consultar qualquer servidor no sistema e obter os mesmos dados exatos.disponibilidade-cada pedido para os servidores de dados recebe uma resposta. Se um servidor está ocupado, ele é encaminhado para outro que é capaz de responder.tolerância de partição
• – a capacidade do sistema para continuar a funcionar mesmo que haja falhas de rede e alguns dos servidores não podem se comunicar.

suposição subjacente-P é impossível

num sistema de base de dados distribuído, os seus dados são divididos em diferentes servidores e esses servidores falam uns com os outros através de uma rede para que possam manter o mesmo conjunto de dados. O problema é que as redes quebram e então assumimos que ele sempre vai se comunicar, ou seja, não podemos ter uma rede perfeita. Em termos dessa teoria, isso significa que no mundo real você tem que sacrificar a tolerância de partição. Se a rede perfeita unfailing existisse então nós não teríamos um problema alcançando consistência e Disponibilidade, mas este é o mundo real construído sobre fios físicos que falham e assim nós assumimos que falhará. se P é impossível, quais são as nossas escolhas?

Uma vez que desistimos da tolerância à partição, o teorema diz que agora temos que escolher entre consistência e Disponibilidade.

Você pode optar por ter disponibilidade Onde sua aplicação pode satisfazer todas as solicitações recebidas, mas não pode garantir que os dados são os mais recentes.

de que necessita a sua aplicação?

Se sua aplicação é um site de mídia social e não precisa ter os dados mais recentes em todos os momentos, então você pode querer escolher a disponibilidade. Importa que seus usuários vejam um post após um atraso de 30 segundos? Se não, então você pode preferir a disponibilidade, porque você prioriza que seus usuários podem acessar os dados mesmo que não sejam os dados mais atualizados.

Se, por outro lado, a sua aplicação requer que cada leitura para a base de dados seja a informação mais recente absoluta, então você terá que sacrificar a disponibilidade e escolher a consistência. Alguns pedidos terão de ser extraídos devido ao facto de a informação não poder ser garantida como a mais recente.

the Choices Made by Relational and NoSQL

Database tech like SQL and other relational database systems designed with ACID priorite Consistency. Por outro lado, a maioria das bases de dados NoSQL prioriza a disponibilidade.

conclusão

acreditamos que examinar este teorema em termos de sua aplicação é um excelente exercício e ajuda você a avaliar as prioridades de sua aplicação. Se você tem um sistema de dados distribuídos examinar sua arquitetura e entender que sacrifício você está fazendo.

MongoDB, CockroachDB e Postgres são todos grandes database tech hoje em dia que tornam nossas arquiteturas de banco de dados extremamente robustas, mas como discutimos eles não são perfeitos. Não temos uma rede perfeita e há sempre “erro de usuário”. Se você está se movendo para um ambiente de produção e quer discutir as melhores opções para a sua aplicação, por favor, não hesite em contactar-nos no Object Rocket.