Teorema CAP
IBM® Cloudant® for IBM Cloud® usa um modelo "Eventualmente Consistente" . Quando você faz uma atualização para uma parte de IBM Cloudant,
a atualização é eventualmente vista por outras partes do sistema.
Para entender como esse modelo funciona e por que ele é uma parte essencial do uso do IBM Cloudant, considere o que significa Consistência.
A consistência é uma das quatro propriedades "ACID" que são necessárias para que as transações dentro de um banco de dados sejam processadas e relatadas de forma confiável.
Adicionalmente, a consistência é um dos três atributos no teorema de "CAP" . Os atributos são Consistency, Availability e Partition tolerance. O teorema afirma que não é possível para um sistema de computador distribuído, como IBM Cloudant para garantir três atributos simultaneamente:
- Consistência, em que todos os nós veem os mesmos dados ao mesmo tempo.
- Disponibilidade, que garante que cada solicitação receba uma resposta sobre se foi bem-sucedida ou falhou.
- Tolerância de partição, em que o sistema continuará a operar, mesmo se qualquer parte do sistema for perdida ou falhar.
A impossibilidade de garantir todos os três atributos ao mesmo tempo significa que o IBM Cloudant não garante o atributo de Consistência. À medida que a atualização se propaga, o sistema é configurado para "convergir" para uma consistência completa.
A consistência eventual é boa para o desempenho. Com um modelo de consistência forte, um sistema deve esperar que quaisquer atualizações sejam propagadas por completo e com sucesso para que uma solicitação de gravação ou atualização possa ser concluída. Com um modelo eventualmente consistente, a solicitação de gravação ou de atualização podem retornar quase imediatamente, enquanto a propagação pelo sistema continua nos bastidores.
Um banco de dados pode demonstrar somente dois desses três atributos por razões teóricas e práticas. Um banco de dados priorizando consistência e disponibilidade é simples: um único nó armazena uma única cópia de seus dados. Mas este modelo é difícil de escalar, pois deve-se fazer upgrade do nó para obter mais desempenho, em vez de usar nós extras. E mesmo uma falha menor do sistema pode encerrar um sistema de único nó, enquanto qualquer perda de mensagem significa perda de dados significativos. Para suportar, o sistema deve se tornar mais sofisticado.
Trocas em tolerância à partição
Um banco de dados que prioriza a consistência e a tolerância de partição comumente emprega uma configuração primária-secundária, em que um nó dos muitos no sistema é eleito líder. Somente o líder aprova gravações de dados, enquanto todos os nós secundários replicam dados do líder para manipular leituras. Se o líder perder a conexão com a rede ou não puder se comunicar com vários dos nós do sistema, o restante elegerá um novo líder. Esse processo eleitoral difere entre os sistemas, e pode ser uma fonte de problemas significativos.
O IBM Cloudant prioriza a disponibilidade e a tolerância de partição empregando uma configuração primária-primária, de tal forma que cada nó pode aceitar gravações e leituras em sua parte dos dados. Diversos nós incluem cópias de cada parte de seus dados. Cada nó copia dados com outros nós. Se um nó se tornar inacessível, outros poderão entregar em seu lugar, enquanto a rede sana o problema. Desta forma, o sistema retorna seus dados de maneira oportuna apesar da falha arbitrária do nó, e mantém eventual consistência. A troca em despriorizar a consistência absoluta é que leva tempo para todos os nós verem os mesmos dados. Como resultado, algumas respostas podem incluir dados antigos enquanto os dados novos são propagados no sistema.
Mudando a abordagem
A manutenção de uma visualização consistente de dados é lógica e fácil de entender, porque um banco de dados relacional faz esse trabalho para você. A expectativa é que os serviços baseados na web que interagem com sistemas de banco de dados se comportem dessa maneira. Mas essa expectativa não significa que eles funcionam dessa maneira. A consistência não é uma certeza e é preciso um pouco de trabalho para mudar a abordagem.
Na verdade, a consistência não é necessariamente essencial para vários serviços de nuvem corporativos. Sistemas grandes com alta utilização trazem com eles uma grande probabilidade de que uma parte do sistema pode falhar. Um banco de dados planejado em torno da necessidade de priorizar a disponibilidade e a consistência eventual é mais adequado para manter seu aplicativo on-line. A consistência de dados do aplicativo pode ser tratada após o fato.
Disponibilidade do aplicativo versus consistência na empresa
Uma olhada nos populares serviços baseados na web mostra que as pessoas já esperam alta disponibilidade e, felizmente, comercializam essa disponibilidade para dados eventualmente consistentes, muitas vezes sem perceber que estão fazendo isso.
Muitos aplicativos enganam os usuários por causa da disponibilidade. Considere ATMs: dados financeiros inconsistentes é o motivo de ainda ser possível realizar saque a descoberto sem perceber. Será impraticável apresentar uma visualização consistente de seu saldo da conta em todo o sistema bancário se cada nó na rede precisar parar e registrar essa figura antes que as operações continuem. Uma opção melhor é tornar o sistema altamente disponível.
O setor financeiro percebeu isso nos anos 80, mas várias organizações de TI ainda estão preocupadas em sacrificar a consistência por causa da disponibilidade. Pense no número de chamadas de suporte feitas quando sua equipe de vendas não pode acessar o app CRM. Agora considere se eles perceberiam mesmo, uma vez que leva alguns segundos para uma atualização de banco de dados se propagar em todo o aplicativo.
A disponibilidade supera a consistência mais do que se pode esperar. Sistemas de carrinho de compras on-line, caches HTTP e DNS são mais alguns exemplos. As organizações devem considerar o custo do tempo de inatividade, como frustração do usuário, perda de produtividade e oportunidades perdidas.
Da teoria à implementação
Tratar a alta disponibilidade é vital para aplicativos em nuvem. Caso contrário, a consistência de banco de dados global permanece um grande gargalo à medida que você escala. Os aplicativos altamente disponíveis precisam manter contato constante com seus dados, mesmo que esses dados não estejam atualizados. Este é o conceito de consistência eventual e não há nada a temer. Às vezes, com uma larga escala, é melhor entregar respostas que não são perfeitamente corretas do que não entregar nenhuma.
Os sistemas de banco de dados escondem as complexidades da disponibilidade versus consistência de diferentes formas, mas elas sempre existem. O IBM Cloudant, o CouchDB e outras equipes de banco de dados NoSQL acreditam que a melhor política requer que os desenvolvedores abordem essas complexidades logo no início do processo de design. Ao fazer o trabalho duro na frente, você reduz as surpresas porque os aplicativos estão prontos para ajuste de escala desde o primeiro dia.