Casos de uso e práticas recomendadas para transações distribuídas por meio do N1QL

O Couchbase é compatível com transações?

Sim! Com a versão 6.5, introduzimos o Transação ACID no Couchbase por meio dos SDKs. O 1st A pergunta que recebemos na época dos clientes que souberam disso foi:

O suporte a transações está disponível por meio do N1QL?

Sim! Com a versão 7.0, começamos a oferecer suporte a transações por meio do N1QL também!As transações N1QL são multitudo. Vários documentos que podem abranger várias coleções de vários escopos em vários buckets. Você pode ter várias transações em execução em um único nó de consulta e pode ter vários nós de consulta. NÃO há um coordenador central, o que elimina um único ponto de falha ou contenção e abre caminho para a escalabilidade infinita!

O que é N1QL e por que ele é tão importante para o Couchbase?

Assim como o SQL está para o RDBMS, o N1QL está para o Couchbase!

N1QL é uma linguagem declarativa, quase idêntica ao SQL, e é usada para inserir/recuperar e manipular os dados armazenados na forma de documentos JSON.Saiba mais sobre o N1QL aqui .

Se o N1QL é como o SQL, então por que ele não tinha ACID antes?

O N1QL sempre teve ACID em um único documento. O que não tínhamos antes da versão 7.0 era o suporte a transações com vários documentos por meio do N1QL.

Bem, vamos pensar primeiro no motivo pelo qual muitas pessoas acreditam que precisam de transações com vários documentos. O primeiro princípio da modelagem de dados relacionais é a normalização dos dados entre as tabelas. Isso significa que muitas operações comuns do banco de dados, como a criação de contas, exigem atualizações atômicas em muitas linhas e colunas.

No Couchbase, o modelo de dados é fundamentalmente diferente. O modelo de documento incentiva os usuários a armazenar dados relacionados em um único documento. O N1QL sempre deu suporte a transações ACID em um único documento e, ao aproveitar o modelo de documento adequadamente, muitos aplicativos não precisam de garantias ACID em vários documentos. Conforme mostrado abaixo, os dados que precisam ser armazenados em três tabelas diferentes vinculadas por PK-FK são armazenados em um único documento no Couchbase.  

Por exemplo, adicionar um item a um carrinho de compras não precisa de transações no Couchbase, pois você está atualizando apenas um único documento

Entretanto, as transações não são apenas uma caixa de seleção. As transações, como todos os recursos do Couchbase, têm como objetivo facilitar a vida dos desenvolvedores. As garantias ACID entre documentos simplificam a lógica de aplicativo necessária para satisfazer aplicativos complexos.

Quais são os casos de uso para transações com vários documentos?:

Há casos de uso em que as garantias ACID transacionais precisam ser aplicadas a um conjunto de operações que abrangem vários documentos. Os aplicativos de "Sistema de registro" são a classe típica de carga de trabalho em que as transações de vários documentos são úteis. Os exemplos incluem:

• Processamento de eventos de aplicativos quando os usuários executam ações que, se repetidas, podem causar resultados diferentes, de modo que todos eles devem ser bem-sucedidos ou falhar. Por exemplo, débito e crédito bancários típicos.
• Registro de ações personalizadas do aplicativo - que não podem ser revertidas mesmo em caso de falha do sistema, por exemplo, quando um usuário transfere a propriedade de um carro ou de uma casa, a gravação não deve ser bem-sucedida se o registro não for.
• Relacionamentos de muitos para muitos em que os dados se encaixam naturalmente em objetos definidos - por exemplo, clientes, pedidos de clientes, produtos e fabricantes. Para calcular o total em um pedido de cliente, os valores de cada tabela precisam ser coletados e somados para cada cliente.

Detalhes sobre transações por meio do N1QL no Couchbase:

Vamos nos aprofundar nas transações N1QL com uma transação simples, débito e crédito. Os Selects precisam ler suas próprias atualizações (RYOW)

INICIAR A TRANSAÇÃO;

UPDATE customer SET balance = balance - 100 WHERE cid = 4872;

UPDATE customer SET balance = balance + 100 WHERE cid = 1924;

SELECT cid, name, balance from customer where cid in [4872,1924];

COMMIT ;

Essa é a mesma sintaxe que você escreveria no MySQL. Essa é a beleza do N1QL.

Você não precisa aprender uma nova linguagem para usar o Couchbase se já estiver familiarizado com SQL.

No exemplo acima,

Se você já estiver familiarizado com a arquitetura do Couchbase, então

• START TRANSACTION irá para um nó de consulta. O nó de consulta atribuirá um ID de transação exclusivo (txid) a essa transação.

• Em seguida, vem a instrução de atualização. O nó de consulta examinará a cláusula where, selecionará o índice apropriado que atenderá à consulta, encontrará o ID do documento, enviará o ID do documento para o armazenamento de dados (KV) e buscará o documento no nó de consulta e, em seguida, atualizará o saldo. Se isso não estivesse em uma transação, seria enviado de volta ao armazenamento de dados imediatamente. Mas, como está dentro da transação, esse documento será armazenado no cache do nó de consulta. Esse cache é chamado de tabela delta. Temos uma tabela delta por transação e por coleção. É por isso que precisamos que todas as declarações de uma transação cheguem ao mesmo nó de consulta. Essa junção é feita com o txid fornecido por START TRANSACTION.
• Com a próxima atualização, a mesma coisa, o nó de consulta examinará a cláusula where, selecionará o índice apropriado que atenderá à consulta, encontrará o ID do documento, mas agora, em vez de ir diretamente para a KV para buscar o documento, como há uma tabela delta, ele primeiro procurará na tabela delta se esse documento já existe na tabela delta. Nesse caso, não existe, então ele vai buscar no KV, atualiza o saldo e o armazena na tabela delta.
• Em seguida, vem a instrução select para o nó de consulta. Novamente, o nó de consulta examinará a cláusula where, selecionará o índice apropriado que atenderá à consulta e encontrará o ID do documento. Agora ele procurará os ids do documento na tabela delta, os encontrará lá e enviará os campos projetados de volta ao cliente.

• Até agora, você vê que lemos do armazenamento de dados, mas nunca gravamos no armazenamento de dados. Só escrevemos no cache do nó de consulta. Por isso, dizemos que seguimos a simultaneidade otimista. Várias transações poderiam estar operando nesses mesmos documentos ao mesmo tempo.
• Agora, quando a próxima instrução atingir o nó de consulta "COMMIT", será quando os documentos atualizados irão para o nó KV e usaremos o protocolo de confirmação destacado aqui para realmente confirmar as alterações. 
• Nesse ponto, se houvesse várias transações atualizando os mesmos documentos, uma seria bem-sucedida e as outras seriam revertidas e teriam que tentar novamente.

Práticas recomendadas para transações N1QL :

Quando você deve usar as transações N1QL?

1. Quando você tem vários extratos de consulta que devem ser aprovados ou reprovados, um exemplo típico: crédito de débito, reserva de companhia aérea com várias etapas
2. Se você quiser ter certeza de que as alterações feitas não serão revertidas, mesmo em caso de falha do sistema, como a transferência do título de uma casa/carro.
3. Quando a lógica necessária abrange dados que não podem ser mesclados em um único documento e exige atualizações em vários documentos.
4. Normalmente, cargas de trabalho de execução muito curta envolvendo pequenos conjuntos de resultados - sem grandes agregados.
5. Quando você precisar modificar/ler os mesmos documentos várias vezes (com o suporte de Read your own writes usando tabelas delta)

O que você deve evitar fazer ao usar transações N1QL?

Mesmo com o exemplo simples acima, você provavelmente pode ver isso:

1. A tabela delta (que é por transação/por coleção) crescerá a cada mutação. Se você tiver uma transação com muitas mutações, o uso da memória aumentará. Portanto, a recomendação é limitar o número de mutações em uma transação. Para cargas do tipo ETL ou atualizações massivas que precisam de garantias ACID, fornecemos outra opção de transações implícitas. Você pode ler sobre elas aquiA configuração "memory-quota" no serviço de consulta pode controlar a quantidade de memória consumida pelas tabelas delta.
2. Use as transações somente em documentos com menos de 10 MB de tamanho.
3. Não inclua Operações DDL em transações N1QL. Qualquer operação DDL resultará em um erro.
4. Por padrão, o tempo limite é de 15s. Isso pode ser modificado dependendo do meio que você está usando para usar as transações N1QL (shell cbq, UI, Java SDK ou API REST)
5. O serviço de consulta foi projetado para oferecer alta taxa de transferência e baixa latência, o que pode ser afetado pelas transações. Use transações N1QL quando seus casos de uso necessitarem de transações.
6. Como usamos a concorrência otimista, precisamos ter certeza de que a maior parte da nossa carga de trabalho é tal que várias transações não estão modificando os mesmos documentos ao mesmo tempo. Porque, nesse caso, uma será bem-sucedida e as outras serão revertidas com erros de "incompatibilidade de CAS" ou "conflito de gravação".
7. Não deveríamos estar modificando os mesmos documentos usando transações e não transações ao mesmo tempo.

Entenda como as transações funcionam usando o Simulador de transações

Mais informações sobre o suporte a transações por meio do N1QL

https://www.couchbase.com/blog/transactions-n1ql-couchbase-distributed-nosql/

https://www.couchbase.com/blog/couchbase-transactions-with-n1ql/

https://docs.couchbase.com/java-sdk/current/howtos/distributed-acid-transactions-from-the-sdk.html#n1ql-queries