O CTO do Couchbase, Ravi Mayuram, anunciou as transações ACID distribuídas de vários documentos no Couchbase Server 6.5. Eu recomendo fortemente lendo o blog do Ravi que destaca como as transações do Couchbase são uma união inovadora de garantias ACID com escala, alta disponibilidade, desempenho e flexibilidade.
Neste blog, vou me aprofundar em nosso projeto de Transações ACID funcionalidade.
Simples, mas poderoso
Primeiramente, vamos ver como é fácil escrever uma transação do Couchbase. Você abre uma transação, faz algum trabalho e confirma (ou falha) com Atomicidade, Consistência, Isolução e Durabilidade. Aproveitando o SDK e as APIs regulares do Couchbase, você pode utilizar os recursos da plataforma de programação subjacente. Aqui está um trecho de código que mostra um débito/crédito básico, transferindo fundos de uma conta para outra com uma transação ACID:
Há muitos recursos incorporados para facilitar a programação com transações no Couchbase:
- Confirmação ou reversão automática com flexibilidade para também fazer isso explicitamente.
- Tentativas automáticas para erros transitórios, como atrasos de durabilidade devido a falhas na rede ou conflitos de bloqueio.
- Duração configurável para uma transação. Os deadlocks são resolvidos automaticamente, pois uma das transações atingirá o tempo limite e liberará seus recursos.
- Limpeza automática de transações órfãs em caso de falha do cliente.
Se você quiser um tutorial rápido sobre programação com a API Java de transações e um exemplo de código para download, consulte Blog e vídeo de Graham Pople.
Garantias da ACID
As transações do Couchbase fornecem atomicidade, consistência, isolamento e durabilidade, conforme exigem as garantias ACID:
- Atomicidade e Durabilidade são propriedades binárias - ou você tem ou não tem.
- Isolamento é um espectro com compensações. Os bancos de dados relacionais populares, como Oracle, MySQL e SQL Server, escolheram diferentes níveis de isolamento padrão e máximo.
- Consistência tem significados diferentes para o público do ACID tradicional e para o público dos sistemas distribuídos. A definição tradicional de ACID diz que uma transação deve levar o banco de dados de um estado válido para outro. A definição de sistemas distribuídos decorrente do teorema CAP diz que cada leitura deve receber a última gravação, embora isso comece a parecer um pouco com a semântica de isolamento.
Aqui está um resumo das garantias ACID fornecidas pelas transações no Couchbase Server 6.5.
| Atomicidade | Semântica de tudo ou nada para atualizar vários documentos em vários fragmentos em nós diferentes. |
| Consistência | As réplicas são imediatamente consistentes com a confirmação da transação.
GSI, FTS, XDCR são eventualmente consistentes com o commit da transação (O N1QL pode impor uma consistência forte na leitura com request_plus) |
| Isolação | Leitura Isolamento comprometido para todos os leitores simultâneos - se são leituras transacionais ou não transacionais |
| Durabilidade | 3 níveis de durabilidade disponíveis para proteção de dados:
|
Sim, eles são distribuídos
As transações ACID do Couchbase são multi-documento e multi-nó - portanto, são realmente distribuídas, como você pode ver na ilustração arquitetônica simplificada do Couchbase abaixo. A ilustração mostra um cluster simples do Couchbase com 3 nós e 9 vbuckets/shards com 2 réplicas (total de 3 cópias de dados). A transação modifica dois documentos, Andy e Beth, com sua cópia ativa em dois nós separados. A conclusão bem-sucedida da transação garantirá que a cópia ativa de cada um dos dois documentos, bem como a maioria de suas cópias totais (o que, nesse caso, significa 1 de 2 réplicas além da ativa), sejam atualizadas com o novo valor. A falha garantirá que o estado permaneça inalterado e idêntico ao anterior à transação.
Detalhamento de recursos
Embora o resumo do ACID forneça uma perspectiva de alto nível, os detalhes a seguir fornecem uma compreensão mais profunda da semântica:
Multi-nó, multi-bucket, multi-documento
Uma única transação pode abranger vários documentos, em vários buckets, em vários nós. Como no Couchbase, um bucket mapeia um banco de dados, uma transação pode, na verdade, abranger vários bancos de dados que vivem no mesmo cluster do Couchbase. Isso, juntamente com a capacidade do Couchbase de executar JOINs entre buckets, proporciona enorme flexibilidade ao aplicativo.
Somente os dados confirmados podem ser lidos pelos consumidores de DCP
Todas as leituras feitas de qualquer maneira, inclusive de N1QL, XDCR, Analytics, Mobile, Eventing e Connectors, retornarão apenas dados confirmados. Ninguém jamais poderá ler dados não confirmados/sujos. O protocolo DCP (Data Change Protocol) do Couchbase garante que nenhum dado intermediário não confirmado seja lido por um consumidor downstream.
Bloqueio e detecção de conflitos
Os conflitos entre transações que tentam atualizar os mesmos documentos são detectados e tratados revertendo uma delas e tentando novamente (até o tempo limite da transação que, por padrão, é de 15s). Isso é feito por meio de uma combinação de otimismo e bloqueio pessimista no nível do documento.
Qualquer documento que você queira modificar em uma transação deve ser lido primeiro dentro da transação e todas as gravações nela são automaticamente gravações CAS (Check and Set). Portanto, se uma transação ler dados que posteriormente são alterados por outra gravação transacional (ou não transacional), no momento da gravação essa transação detectará o conflito de CAS, reverterá e tentará novamente.
Na transação de débito/crédito acima, em que o dinheiro está sendo transferido da conta de Beth para a conta de Andy, se a conta de Beth for alterada após a transação ter lido a conta dela, mas antes de modificá-la, a transação detectará isso, reverterá e tentará novamente.
Quando o documento é modificado na transação, ele obtém implicitamente um bloqueio de gravação no documento, que é liberado somente quando a transação termina. Se uma segunda transação tentar modificar um documento que já esteja bloqueado por uma transação, essa última transação detectará o conflito de gravação, fará uma reversão e tentará novamente até o período de tempo limite da transação.
Voltando ao exemplo de débito/crédito acima, suponha uma transação durante o voo em que a conta de Beth tenha sido deduzida, mas a de Andy ainda não tenha sido atualizada. Nesse momento, o documento da conta de Beth está bloqueado. Portanto, se outra transação para transferir dinheiro da conta da Beth para a conta do Bill estiver sendo tentada simultaneamente, ela detectará o conflito de gravação na Beth e reverterá.
Durabilidade síncrona
No Couchbase Server 6.5, temos uma nova implementação do protocolo de replicação que garante que uma mutação seja visível para os leitores somente depois de atender aos critérios de replicação/persistência e possa ser revertida se esses critérios não forem atendidos. Esse novo mecanismo de replicação está sendo submetido a testes internos abrangentes da Jepsen. Leia o blog de Korrigan para saber mais.
A replicação síncrona oferece durabilidade ajustável, permitindo que você escolha o nível de proteção contra falhas (falha de nó, falha de disco, falhas únicas ou múltiplas) que deseja para cada gravação. Há três níveis para escolher:
- maioria - Esse nível de durabilidade garante que a gravação seja propagada para a maioria das réplicas antes de retornar (por exemplo, se o cluster estiver configurado com 2 réplicas, ela será gravada na RAM na réplica ativa e propagada para pelo menos 1 réplica antes de retornar o sucesso ao aplicativo)
- persistToActive - Esse nível garante que a gravação seja propagada na RAM para a maioria das réplicas e persista no disco na réplica ativa antes de retornar o sucesso ao aplicativo.
- persistToMajority - esse nível garante que a gravação seja mantida no disco na maioria dos nós antes de retornar o sucesso ao aplicativo.
Se a durabilidade falhar (tempo limite, falha no nó etc.), a gravação será automaticamente revertida e o cliente será notificado da falha.
Observação: as novas gravações de durabilidade síncrona são aplicáveis a transações e a mutações de documentos únicos.
Observação: se você não especificar nenhum nível de durabilidade, ele será tratado de forma assíncrona, o que acaba sendo durável.
As transações são colocadas em camadas sobre o novo mecanismo de replicação síncrona e, por padrão, definem o nível de durabilidade em 'maioria'. Você pode substituir o padrão escolhendo um nível de durabilidade diferente por transação. 'persistToMajority' oferece a mais forte proteção de dados em caso de várias falhas.
Compartimentos efêmeros
Você também pode usar transações e durabilidade síncrona em buckets efêmeros. Há casos de uso de cache que não precisam de persistência, mas ainda querem garantir que os itens no cache sejam atualizados com garantias ACID.
Próximas etapas
O suporte a transações ACID de vários documentos no Couchbase Server 6.5 é inovador e abre novos casos de uso para sua empresa. Aplicativos NoSQL. Gostaríamos muito de receber seus comentários e sugestões sobre os aprimoramentos adicionais necessários para as transações. Aqui estão alguns recursos para você começar:
Baixar
Faça o download do Couchbase Server 6.5
Documentação
Documentação do Couchbase Transactions 6.5
Guia de instruções do Couchbase Transactions 6.5 para SDKs
Blogs
O Couchbase traz as transações ACID multidocumento distribuídas para o NoSQL
Introdução à API Java do Couchbase Transactions [Vídeo]
Anunciando o Couchbase Server 6.5 - Novidades e aprimoramentos
