4.1 Consistência sobre Brewera
Para começar, Eric Brewer não é, e nunca afirmou ser, um especialista em banco de dados. Ele pertence à comunidade de sistemas distribuídos, e sua famosa palestra, na qual apareceu o "teorema" CAP, foi proferida na conferência "Princípios da Computação Distribuída". (A propósito, dez anos depois, em 2010, voltou a dar uma palestra convidada na mesma conferência, e nesta palestra deu, em particular, uma série de exemplos de sistemas distribuídos, cujo desenvolvimento teve em conta o " teorema" do CAP.) Nesta área tem a sua própria interpretação dos termos utilizados no domínio das bases de dados.
Em particular, o termo "consistência imediata" significa que, após o usuário receber uma notificação do sistema sobre a conclusão bem-sucedida de alguma operação de atualização de dados, o resultado dessa operação torna-se instantaneamente visível para todos os observadores.
Consistência eventual significa que, se nenhuma nova operação de atualização de dados entrar no sistema por um período de tempo suficientemente longo, pode-se esperar que os resultados de todas as operações de atualização de dados anteriores se espalhem por todos os nós do sistema e todos os dados de réplica sejam consistente (aparentemente, isso deve ser entendido como "todas as réplicas terão o mesmo estado".
Com esse senso de consistência em mente, o "teorema" de Brewer pode ser considerado bastante compreensível e óbvio: em qualquer sistema distribuído com dados compartilhados, apenas duas propriedades quaisquer de consistência, disponibilidade e tolerância de partição da rede podem ser asseguradas simultaneamente. A este respeito, Brewer ainda contrasta o conjunto de propriedades ACID com seu conjunto proposto de propriedades BASE (basicamente disponível, estado flexível, consistência eventual - disponibilidade na maioria dos casos; estado instável; consistência final). Mas essa oposição, na minha opinião, é injustificada, pois no primeiro caso estamos falando das características lógicas das transações, e no segundo - das propriedades físicas dos sistemas distribuídos.
4.2 Prova do "teorema"
Muitos acreditam que o "teorema" de Brewer foi formalmente provado. De fato, o artigo de Seth Gilbert e Nancy Lynch apresenta algumas definições (quase) formais em que contexto o "teorema" realmente se torna um teorema e é provado. No entanto, vejamos como são determinadas essas três propriedades de um sistema distribuído, das quais, de acordo com o "teorema" de Brewer, apenas duas propriedades podem ser suportadas simultaneamente.
A consistência é chamada de consistência atômica ou linearizável (consistência atômica ou linearizável), que é uma propriedade do sistema, todos os objetos de dados individuais dos quais são atômicos (linearizáveis). Por sua vez, um objeto atômico é um objeto com várias operações, de modo que a chamada da operação e o recebimento dos dados de resposta ocorrem como se instantaneamente, ou seja, o objeto não aceita a chamada da próxima operação até que a operação anterior tenha sido completamente concluída. A ordem na qual as operações são recebidas deve ser tal que, se uma operação do tipo leitura chegar após a execução de alguma operação do tipo gravação, a operação de leitura deverá retornar o valor gravado por esta ou por alguma operação de gravação posterior.
Um sistema distribuído está sempre disponível se todas as requisições recebidas por um nó sem falhas devem ser atendidas. A resiliência do sistema à partição de rede é modelada como a preservação da viabilidade do sistema no caso de perda de um número arbitrário de mensagens enviadas de um nó para outro.
Com base nessas definições, Hilbert e Lynch formulam o seguinte teorema (não há relógio no modelo de rede assíncrona e os nós devem tomar decisões apenas com base nas mensagens recebidas e nos cálculos locais):
Em um modelo de rede assíncrono, não é possível implementar um objeto de dados de leitura/escrita que garanta propriedades de disponibilidade e consistência atômica para todas as execuções válidas (incluindo aquelas que perdem mensagens).
Este teorema é realmente muito simplesmente provado formalmente pelo método "por contradição". O artigo continua concluindo que:
Em um modelo de rede assíncrono, não é possível implementar um objeto de dados de leitura/gravação que garanta propriedades de acessibilidade para todas as execuções válidas e consistência atômica para execuções válidas nas quais as mensagens não sejam perdidas.
Além disso, a verdade do teorema principal é provada para um modelo de rede parcialmente síncrono, no qual cada nó possui um relógio, cujo tempo mostrado aumenta na mesma taxa, mas que não são sincronizados, ou seja, pode mostrar tempos diferentes no mesmo momento real. Mostra-se que para este caso não é derivada uma consequência semelhante e, portanto, para redes parcialmente síncronas há mais possibilidades de organizar sistemas distribuídos com "boas" propriedades.
Sim, em certo sentido (não necessariamente o mesmo pretendido por Brewer), pode-se considerar que Gilbert e Lynch provaram que é impossível garantir simultaneamente as propriedades de consistência atômica, disponibilidade e tolerância à partição de uma rede em um único sistema distribuído. Mas o que isso tem a ver com transações de banco de dados em geral e transações ACID em particular?
4.3 Transações ACID
Aqui está o que Julian Browne escreve sobre isso em sua nota sobre a discussão do "teorema" do CAP:
Em sua prova, Hilbert e Lynch usam o termo atomicidade em vez de consistência, o que faz mais sentido do ponto de vista técnico porque, estritamente falando, a consistência no sentido de ACID refere-se às propriedades ideais das transações do banco de dados e significa que nenhum dado será tornam-se persistentes se violarem algumas restrições pré-estabelecidas. Mas se assumirmos que uma limitação pré-estabelecida dos sistemas distribuídos é a proibição da presença de vários valores diferentes para o mesmo elemento de dados, então, na minha opinião, essa falha na abstração da consistência pode ser considerada insignificante (além disso, se Brewer usasse o termo atomicidade, apareceria o teorema AAP, cujo nome seria extremamente inconveniente de pronunciar).
Isso é escrito não muito a sério, mas honestamente. E, de fato, a exigência de consistência atômica não deve ser misturada com as exigências de consistência transacional no sentido de ACID. As restrições de integridade do banco de dados são requisitos de negócios lógicos. Eles vêm da lógica do domínio do aplicativo. A exigência de consistência atômica é de um tipo muito diferente. Este é um requisito de implementação que se enquadra na categoria tradicionalmente referida na indústria de banco de dados como consistência física (por exemplo, ao realizar qualquer operação de alteração de índice, todos os blocos da árvore B+ correspondente devem conter valores válidos e estar vinculados por referências válidas ).
E aqui está o que os representantes da comunidade de banco de dados Daniel Abadi e Alexander Thomson escrevem com bastante seriedade em sua nota:
... a exigência de disponibilidade de sistemas transacionais escaláveis está se tornando cada vez mais crítica, e isso geralmente é atendido por meio de replicação e redirecionamento automático de solicitações em caso de falha de um dos nós. Portanto, os desenvolvedores de aplicativos esperam que as garantias de consistência dos sistemas ACID (originalmente consistindo em suporte local para invariantes definidos pelo usuário) sejam estendidas para garantir consistência forte (que todas as réplicas dos mesmos dados em um determinado momento serão cópias idênticas, ou seja, em neste caso, a consistência está implícita no sentido de CAP/PACELC.
Em outras palavras, a consistência do Brewer não tem nada a ver com a consistência no sentido do ACID, mas é em sistemas focados em fornecer alta disponibilidade por meio da replicação de dados que é desejável manter uma forte consistência de réplica. Esta não é uma propriedade ACID, mas um recurso técnico (físico) de DBMS massivamente paralelo que facilita o desenvolvimento de aplicativos.
De acordo com Michael Stonebreaker, a chave para construir um DBMS moderno de alta qualidade é a escolha certa de compromissos técnicos. Ao escolher uma solução de engenharia específica, muitos fatores devem ser levados em consideração - os requisitos de futuros usuários, a probabilidade de várias situações de falha, etc., e não ser guiados dogmaticamente por nenhuma orientação teórica geral (incluindo o "teorema" CAP).
Stonebreaker acredita que, no domínio dos sistemas de banco de dados paralelos transacionais, abandonar a consistência de Brewer em favor do suporte de alta disponibilidade e tolerância à partição de rede é uma compensação ruim porque (a) a consistência da réplica é um recurso muito útil do sistema; (b) SGBD transacionais massivamente paralelos não precisam de clusters com um número muito grande de nós, então situações de divisão de rede são improváveis; (c) o sistema pode facilmente ficar indisponível, não por causa de uma partição de rede, mas, por exemplo, devido à presença de erros de software que ocorrem regularmente.
Assim, a alta atividade dos representantes do campo NoSQL (leia-se NoACID), que frequentemente se referem ao "teorema" de Brewer, não está relacionada com a impossibilidade teórica de construir DBMS transacionais massivamente paralelos que suportam transações ACID, mas com o fato de que sistemas simplificados que não suportam apenas transações ACID, mas também consistência de réplica, são criadas de forma mais fácil e rápida. Devido à sua organização simplista, eles são capazes de processar dados muito rapidamente e, para algumas aplicações, isso é mais importante do que todas as conveniências inerentes à tecnologia de banco de dados.
Vamos ver como a comunidade de banco de dados responde a esse desafio.