O SQL é a única linguagem do século XXII disponível para os desenvolvedores atualmente.
RESUMO
Nos sistemas de bancos de dados relacionais, o SQL é mais do que uma linguagem de consulta declarativa. Ela inclui linguagem procedural (T-SQL, PL/SQL etc.) e define transações e sua semântica. O SQL como linguagem de consulta tem sido não razoavelmente eficaz, mesmo em Sistemas de banco de dados NoSQL. No entanto, poucos sistemas de banco de dados NoSQL oferecem suporte a transações. Os que oferecem suporte vêm com uma longa lista de limitações e/ou não conseguem oferecer suporte a operações SQL dentro da transação. Apresentamos e explicamos as transações no Couchbase N1QL: SQL para JSON. As transações do N1QL são multiuso: multidocumento, multibucket, multiescopo, multicoleção e multiexecução DML.
O N1QL Transactions está disponível com o Couchbase 7.0 Beta. Você pode baixá-lo aqui: https://www.couchbase.com/downloads. Consulte a documentação aqui.
INTRODUÇÃO
N1QL é uma linguagem declarativa para manipular JSON. O Couchbase armazena todos os documentos no serviço de dados. O serviço de consulta orquestra o execução de consultas otimizando a consulta, criando um plano de execução e, em seguida, executando-a usando dados, indexação e FTS. O SDK do Couchbase e o protocolo de interação de consulta é criado via REST sobre HTTP/S. As instruções DML do N1QL incluem SELECIONAR, INSERIR, ATUALIZAÇÃO, UPSERT, DELETEe MERGE.
TRANSAÇÕES N1QL
Veja um exemplo de transações no RDBMS e no Couchbase N1QL.
Transações |
Banco de dados MySQL (as declarações são iguais/similares em Oracle, SQL Server, Informix e DB2) |
Banco de dados Couchbase (Cheshire-Cat) |
Inserir dados. Tuplas no MySQL, documentos JSON no Couchbase |
INSERT INTO customer(cid, name, balance) VALUES(4872, "John Doe", 724.23);INSERT INTO customer(cid, name, balance) VALUES(1924, "Bob Stanton", 2735.48); |
INSERT INTO cliente
|
Transação simples, débito e crédito. As seleções intermediárias precisam ler suas próprias atualizações (RYOW) |
INICIAR A TRANSAÇÃO;UPDATE customer SET balance = balance + 100 WHERE cid = 4872;SELECT cid, name, balance from customer;UPDATE customer SET balance = balance - 100 WHERE cid = 1924;SELECT cid, name, balance from customer;COMMIT ; |
INICIAR A TRANSAÇÃO;UPDATE customer SET balance = balance + 100 WHERE cid = 4872;SELECT cid, name, balance from customer;UPDATE customer SET balance = balance - 100 WHERE cid = 1924;SELECT cid, name, balance from customer;COMMIT ; |
A segunda transação com reversão parcial. |
INICIAR A TRANSAÇÃO;UPDATE customer SET balance = balance + 100 WHERE cid = 4872;SELECT cid, name, balance from customer;SAVEPOINT s1;UPDATE customer SET balance = balance - 100 WHERE cid = 1924;SELECT cid, name, balance from customer;ROLLBACK WORK TO SAVEPOINT s1;SELECT cid, name, balance from customer;COMMIT ; |
INICIAR A TRANSAÇÃO;UPDATE customer SET balance = balance + 100 WHERE cid = 4872;SELECT cid, name, balance from customer;SAVEPOINT s1;UPDATE customer SET balance = balance - 100 WHERE cid = 1924;SELECT cid, name, balance from customer;ROLLBACK WORK TO SAVEPOINT s1;SELECT cid, name, balance from customer;COMMIT ; |
Se você não viu muita diferença, é porque não há.
DECLARAÇÕES DE TRANSAÇÕES N1QL
Transações N1QL um conjunto de transações que incluem qualquer uma das instruções DML em todos os formulários: sem restrições. A proteção transacional é emitida a partir de novas declarações: BEGIN/START, COMMIT, ROLLBACK, SAVEPOINT.
START TRANSACTION (igual a BEGIN WORK)
Essa instrução inicia uma nova transação, atribui um novo ID de transação e retorna o ID de transação para o chamador. Há duas regras que os SDKs e as ferramentas (por exemplo, CBQ shell) seguem para executar com êxito o restante da transação.
- Envie esse ID de transação como parâmetro a cada instrução subsequente dentro da transação. É assim que o serviço de consulta sabe que o comando deve ser executado como parte de uma determinada transação.
- O Couchbase pode ter vários nós de serviço de consulta, mas uma única transação é executada em um único nó de consulta. Você pode iniciar uma nova transação em QUALQUER NÓ DE CONSULTA. No entanto, o restante das instruções PARA AQUELA TRANSAÇÃO ÚNICA deve ser enviado para o MESMO nó de consulta.
COMMIT TRANSACTION ou COMMIT WORK;
Isso confirma todas as alterações na transação para o armazenamento de dados. Trata-se de uma confirmação distribuída da transação no armazenamento de dados de valor-chave do Couchbase. O commit é compatível com todos os Durabilidade do Couchbase opções. Esse ainda é um sistema distribuído - assim como na astronomia, coisas raras acontecem com frequência. Em qualquer falha, a transação completa é revertida automaticamente e o aplicativo precisa tentar novamente a transação. As falhas podem ocorrer por vários motivos: falha de rede, falha de nó, sobrecarga de nó e conflito de gravação-escrita. Assim como os WRITEs diretos do Couchbase são otimistas e as falhas podem ocorrer devido a gravações simultâneas, resultando em Conflitos no CASAs transações N1QL também podem falhar devido a conflitos de gravação. Implementamos uma forma de concorrência otimista abordagem de transações.
ROLLBACK TRANSACTION ou ROLLBACK WORK;
Em uma reversão emitida pelo aplicativo, todas as modificações feitas na transação são revertidas.
Como você viu nos exemplos acima, o N1QL também suporta pontos de salvamento e reversões para os pontos de salvamento dentro da transação. Do ponto de vista do aplicativo, eles funcionam da mesma forma que as contrapartes do RDBMS.
RECURSOS TRANSACIONAIS
A transação é mais do que apenas as declarações - é tudo sobre a semântica e as garantias. Por isso, a ÁCIDO definição. Falamos anteriormente sobre atomicidade em relação ao COMMIT. Vamos falar um pouco mais sobre isso.
ATOMICIDADE é necessário para toda a transação e para cada instrução. As instruções DML serão revertidas atomicamente em qualquer falha, mas a transação em si está aberta e pode ser continuada. Um exemplo de falha é um conflito de chave de documento na inserção.
CONSISTÊNCIA garante que as restrições sejam aplicadas de forma consistente para cada declaração. A única restrição no Couchbase é a restrição exclusiva na chave do documento. O N1QL verifica a pré-existência de cada uma das chaves inseridas e reverte a declaração em caso de conflito. Lembre-se de que usamos o controle de simultaneidade otimista. Isso significa que, mesmo depois que o INSERT for bem-sucedido, o estágio de confirmação ainda poderá se deparar com um conflito de gravação-escrita, pois alguma outra sessão poderia ter inserido algo entre a inserção e a confirmação. Você terá que tentar novamente a transação nessas falhas.
ISOLAMENTO
Oferecemos suporte ao nível de isolamento COMMITTED READ. Todos os dados que são lidos e avaliados são dados confirmados no índice e no armazenamento de dados. Por padrão, usamos o rigoroso nível de isolamento request_plus consistência nas leituras do índice. Isso significa que, para um determinado predicado, usamos os dados mais recentes no índice para qualificar os documentos para qualificar o select/update/delete. Em seguida, vamos além para buscar os documentos no repositório KV e reaplicar os predicados para garantir que a última versão confirmada do documento seja qualificada e atualizada.
Se o desempenho não fosse uma consideração, todos teriam usado transações serializáveis ;-) Você pode alterar a consistência da varredura para ilimitado para melhorar o desempenho da varredura de índice.
DURABILIDADE
O N1QL é compatível com todos os opções de durabilidade e recursos com o armazenamento de dados do Couchbase para garantir a durabilidade em nosso banco de dados distribuído.
CONCURRÊNCIA
Em termos gerais, as transações de banco de dados usam tanto o método pessimista quanto o otimista controle de simultaneidade. Os bancos de dados tradicionais de nó único seguem o controle de simultaneidade pessimista para evitar conflitos. Essa abordagem também é aplicada a algumas das implementações de vários nós, como Oracle RAC e DB2 Sysplex. As implementações de vários nós são possíveis, mas exigem Infiniband caro, hardware personalizado, etc.
Versão de controle de simultaneidade otimista cada unidade de base da tupla (linhas em rdbms, documentos no Couchbase), lembre-se da versão que leu para modificar e verifique se a versão foi alterada durante a gravação. Se houver de fato um conflito, toda a transação deverá ser repetida. A vantagem dessa abordagem é que, em um aplicativo bem projetado, deve haver poucos conflitos: você não vai sacar dinheiro e transferir dinheiro entre contas no mesmo nanossegundo. Nas raras ocasiões em que isso acontece, a nova tentativa é tolerada.
Concorrência no serviço de consulta N1QL
O Couchbase N1QL usa controle de simultaneidade otimista. Cada transação lê os documentos que precisa atualizar, atualiza-os e mantém os documentos atualizados em sua pasta privada por transação cache. Quando você emite uma instrução subsequente, o serviço de consulta está ciente dos documentos atualizados dentro das transações e usa essa versão em vez da versão mais antiga refletida no índice/dados. É assim que ele oferece suporte a READ-YOUR-OWN-WRITE. Isso é modelado de forma que todas as instruções DML, todas as operações (selecionar, unir, projetar, agregar, aninhar, unnesst etc.) obtenham esse benefício RYOW, fornecendo um recurso consistente e crucial da transação. Mesmo enquanto o aplicativo está realizando transações (fazendo leituras e gravações), dentro da transação, estamos lendo e armazenando em cache as atualizações até o momento da confirmação. Essa é a fase READ da transação e, devido a essa abordagem, não há coordenação entre várias transações ou vários nós de consulta em uma transação até a confirmação (fase WRITE). Isso garante o desempenho e a escalabilidade das transações distribuídas no Couchbase. E, antes que você pergunte, tudo isso funciona simultaneamente com Transações distribuídas do Couchbase nós lançado na versão 6.5.
A coordenação é a ruína dos sistemas dimensionáveis. Peter Bailis
PRÓXIMAS ETAPAS
Acabamos de anunciar que o Couchbase 7.0 Beta será lançado em novembro de 2020. Fique atento aos detalhes.
Esta é uma breve visão geral do que está por vir com o Couchbase Transactions. Na próxima série de artigos, vamos nos aprofundar na implementação, no uso, no suporte ao SDK, nas Transações Lambda, no suporte ao Spring, etc., e muito mais.
AGRADECIMENTOS
Tenho o prazer de anunciar as transações N1QL aqui. Esse é o resultado de intenso trabalho e colaboração das equipes de consulta, SDK e QE do Couchbase para projetar e implementar. Muito obrigado!
