As transações ACID estão chegando ao Apache Cassandra: eis por que estamos entusiasmados

An extraordinary computer science breakthrough called Accord is bringing globally available, general-purpose ACID transactions to the next Cassandra release

Vamos tirar a melhor parte primeiro. estão chegando ao Apache Cassandra.

Transações de uso geral disponíveis globalmente que funcionam da mesma forma que o Cassandra. Isso não é um truque com letras miúdas ou a aplicação de técnicas antigas.

É devido a um avanço extraordinário da ciência da computação chamado de uma equipe da Apple e da Universidade de Michigan. Isso ajudará Cassandra a mudar a forma como pensamos nos dados, abrindo novos casos de uso.

Veja o que isso significa para aqueles que não estão familiarizados com os meandros do projeto Cassandra e seus recursos. Nada é mais importante do que a rapidez com que você pode colocar um aplicativo em produção. Mas os desenvolvedores que desejam colocar a escala, a resiliência e o lendário suporte de vários centros de dados do Cassandra para trabalhar em algo como transações financeiras tiveram que codificar um monte de soluções alternativas complicadas em seus aplicativos. As vantagens e desvantagens em relação ao uso, digamos, da Oracle foram significativas.

Com Acordo? Sem compensações. O Cassandra agora oferecerá o que o tornou incrível, ao mesmo tempo em que transfere o suporte a transações para o banco de dados, reduzindo significativamente a complexidade do código.

O Olho do Observador

Um sistema de banco de dados tem funções essenciais, como e estar disponível para consulta. Gerenciar alterações nos dados nem sempre é uma função do banco de dados. No caso de muitos sistemas NoSQL, o ônus do gerenciamento de mudanças é transferido para o usuário. O observador da mudança de dados é quem atribui a importância da exclusividade.

Suponha que o objetivo seja acumular dados conforme dados. Nesse caso, o observador deve saber que os dados foram recebidos e armazenados de forma durável - por exemplo, dados de cotações de ações em que cada ponto de dados é único e cumulativo. Não há necessidade de exclusividade.

Em operações mais sensíveis, o observador de uma alteração de dados precisa sentir que é o único processo usando o banco de dados. É um conceito da ciência da computação chamado “isolamento”; é o “eu” em ACID (atomicidade, consistência, isolamento, durabilidade).

Um exemplo clássico é uma transferência bancária em que o dinheiro é subtraído de uma conta bancária e adicionado a outra — exatamente nessa ordem. O processo de observação precisa de exclusividade para evitar que outros processos façam alterações que possam levar a inconsistências ou surpresas.

As surpresas incluem permitir inadvertidamente uma transferência de uma conta que ficou abaixo de $ 0.

O isolamento garante que apenas um processo pode fazer uma alteração por vez e, se dois estiverem competindo pelos mesmos dados, um deles terá que esperar a conclusão do outro.

Abrace sua preguiça

Os desenvolvedores precisam se mover rapidamente com um sistema em que possam confiar. As transações ACID têm sido o padrão ouro de confiança nos sistemas de banco de dados por quase 50 anos. Os desenvolvedores trabalham com compensações com base nos requisitos, às vezes levando-os a trabalhar com sistemas que não suportam transações ACID.

Com os sistemas NoSQL, os vieses de trade-off tendiam historicamente a inclinar-se para a escala e o tempo de atividade, sacrificando as transações.

Trazer transações ACID para o Cassandra tem a ver com a redução de trade-offs. O Cassandra já tem uma sólida reputação de escalonamento linear, mantendo o tempo de atividade nos piores cenários. Cassandra tem sido a escolha certa quando você precisa de um banco de dados que atenda ao que a Internet pode oferecer. Sem surpresa, a necessidade de transações tem sido uma fonte de conflito de compensação para os desenvolvedores.

Podemos chegar a um consenso?

Em sistemas distribuídos, cada nó membro no cluster maior pode agir de forma independente ou precisa se coordenar com outros nós. Em uma transação em que “Ei, todos nós precisamos concordar em algo”, os cientistas da computação chamam isso de consenso, e o desenvolvimento desses protocolos é uma área de melhoria contínua.

é um protocolo de consenso estabelecido há muito tempo, adotado por Cassandra em 2013 para “transações leves”.

Leve porque garante que uma única alteração de dados de partição seja isolada em uma transação, mas mais de uma tabela ou partição não é uma opção. Além disso, o Paxos requer várias viagens de ida e volta para obter um consenso, o que cria muita latência extra e detalhes sobre quando usar transações leves em seu aplicativo.

O protocolo foi desenvolvido como a próxima geração para substituir o Paxos, e vários sistemas como Etcd, CockroachDB e DynamoDB o adotaram. Reduziu as viagens de ida e volta ao criar um líder eleito.

A desvantagem para Cassandra nessa abordagem é que os líderes não abrangem datacenters, portanto, vários líderes são necessários (consulte ).

Ter um líder eleito também viola os princípios de “não compartilhar nada” de Cassandra e criaria novos requisitos para lidar com falhas.

Se um nó cair, um novo líder deve ser eleito.

Outros bancos de dados — FaunaDB e FoundationDB, por exemplo — seguiram o caminho de tentar resolver o problema de multilíder reduzindo a um único líder global, conforme descrito no .

Como eles foram criados para outros bancos de dados com requisitos diferentes, as abordagens usadas nesses casos falharam em atender aos critérios que Cassandra espera com modos de falha.

Cassandra assume falhas como parte da execução de um sistema distribuído extensivo. Um ou mais nós ficando off-line não devem causar rápida degradação do desempenho ou problemas de disponibilidade. Precisávamos de uma abordagem diferente.

Chegamos a um Acordo?

Podemos opinar muito sobre o que é aceitável para o projeto Cassandra. Nossos critérios são sobre manter-se fiel às crenças básicas sobre como os sistemas distribuídos devem ser executados. O desempenho e o dimensionamento devem sempre ser preservados durante a operação de vários nós em um ou mais data centers. Podemos ser bastante exigentes, mas é isso que faz da Cassandra a escolha de tantas organizações.

As iterações anteriores de protocolos de consenso resolveram diferentes partes do problema, mas cada uma apresentou uma compensação que violaria alguns dos valores de Cassandra. Dizem que o próximo grande avanço está a dois artigos do último. Nesse caso, o jornal era , e foi preciso um grande esforço para eliminar as compensações.

O acordo aborda dois problemas que não foram resolvidos em protocolos de consenso anteriores: como podemos ter um consenso globalmente disponível e alcançá-lo em uma viagem de ida e volta? O primeiro novo mecanismo é o buffer de reordenação.

Supondo que o hardware de commodity esteja em uso, as diferenças nos clocks entre os nós são inevitáveis. O buffer de reordenação mede a diferença entre os nós, além da latência entre eles. Cada réplica pode usar essas informações para ordenar corretamente os dados de cada nó e contabilizar as diferenças, garantindo um consenso de ida e volta com um protocolo de registro de data e hora.

O outro mecanismo são os eleitorados rápidos. Os modos de falha podem criar latência ao eleger um novo líder antes de retomar. Eleitorados de acesso rápido usam recursos pré-existentes no Cassandra com algumas novas implementações para manter um caminho rápido sem líder para o quorum sob o mesmo nível de falha tolerado pelo Cassandra. Mais detalhes podem ser lidos na .

Como funciona?

O maior impacto será na produtividade do desenvolvedor, então vamos ver como isso acontece na prática. Considere o seguinte exemplo de transferência de conta bancária que mencionamos anteriormente:

A primeira é a nova sintaxe que você verá na Cassandra Query Language (CQL). As transações estão contidas em uma declaração BEGIN TRANSACTION e COMMIT TRANSACTION . Tudo dentro dos marcadores de transação acontecerá atomicamente isolado de outros processos. Transferiremos $ 20 da conta de Alice para Bob neste exemplo. Não existe nada mais clássico do que isso!

Na seção A, podemos selecionar dados de um registro existente e atribuir o resultado a uma tupla (vários itens armazenados em uma única variável). Dependendo de quantas colunas estão na cláusula SELECT , você pode armazenar um ou mais valores na tupla. Esses valores serão usados na seção B para testar as condições antes de fazer alterações nos dados.

Nesse caso, testaremos se Alice tem $ 20 em sua conta antes de transferir para Bob. Nesse caso, um UPDATE diminui o saldo da conta de Alice em $ 20 e, em seguida, incrementa o de Bob em $ 20. Se Alice tivesse menos de $ 20, as mudanças não aconteceriam.

Nos bastidores está um conjunto serializado de comandos de banco de dados que são executados exclusivamente, como visto no processo de observação. Em um ou mais datacenters, a transação exigia apenas uma ida e volta para obter consenso e, se algum nó estivesse offline, a ação ainda ocorreria se pelo menos um quorum de réplicas estivesse disponível.

É exatamente assim que Cassandra gosta de trabalhar, mas acabamos de melhorar nosso jogo com uma transação disponível globalmente.

Qual é o próximo

O Accord e todo o trabalho que o acompanha ainda está em andamento e está programado para ser incluído na próxima versão do Cassandra. Como tudo isso é de código aberto, aqueles que mal podem esperar podem clonar uma cópia do ramo cep-15-accord do repositório Cassandra e criar sua própria cópia.

Para o resto de vocês, à medida que nos aproximamos do tempo de lançamento, teremos compilações disponíveis para você usar e testar. Será uma virada de jogo para Cassandra, e tenho certeza que você vai querer ver por si mesmo. Estou mais interessado em ouvir a comunidade sobre quais casos de uso você encontrará com uma transação disponível globalmente em execução na velocidade e resiliência que você espera do Cassandra. Finalmente chegou a hora de abandonar as últimas cargas de trabalho de banco de dados relacional?

Também estamos ansiosos para ouvir seus comentários em todos os nossos canais, incluindo o Apache Software Foundation . Os recursos em um projeto de código aberto estão em constante evolução para atender às necessidades dos usuários. É por isso que você tem um papel crítico a desempenhar na formação para o futuro.

E fique atento para mais casos de uso e informações à medida que desenvolvemos esse novo recurso interessante. Você pode esperar que haverá várias palestras sobre isso no encontro digital em 14 de março. Você não vai querer perder isso.

Por Patrick McFadin, DataStax

Patrick McFadin é coautor do livro da O'Reilly 'Managing Cloud Native Data on Kubernetes'. Ele atualmente trabalha na DataStax em relações com desenvolvedores e como colaborador do projeto Apache Cassandra. Patrick trabalhou como evangelista-chefe para Apache Cassandra (ele também é um committer de Cassandra recém-formado!) e como consultor para DataStax, onde se divertiu muito construindo algumas das maiores implantações em produção.