conceito ACID

3.1 Surgimento de ACID

A abreviação ACID apareceu pela primeira vez em 1983 em um artigo de Theo Haerder e Andreas Reuter. Para simplificar o texto e torná-lo mais convincente, darei uma tradução de um fragmento deste artigo (com pequenas reduções). Este trecho usa um exemplo de transação bancária na qual o dinheiro é transferido de uma conta para outra.

O conceito de transação, que no exemplo inclui todas as interações com o banco de dados entre $BEGIN_TRANSACTIONe $COMMIT_TRANSACTION, exige que todas as ações sejam executadas indivisivelmente: ou todas as ações são refletidas adequadamente no estado do banco de dados ou nada acontece. Se em algum momento antes de chegar $COMMIT_TRANSACTIONao usuário inserir uma instrução ERRORcontendo $RESTORE_TRANSACTION, nenhuma alteração será refletida no banco de dados.

Para alcançar essa indivisibilidade, uma transação deve ter as seguintes quatro propriedades:

Atomicidade (Atomicidade). A transação deve ser do tipo tudo ou nada descrito acima e, não importa o que aconteça, o usuário deve saber em que estado a transação está.

Consistência (consistência). Uma transação que atinge seu final normal de transação (EOT) e, portanto, confirma seus resultados mantém a consistência do banco de dados. Em outras palavras, toda transação bem-sucedida, por definição, compromete apenas resultados válidos. Essa condição é necessária para sustentar a quarta propriedade - durabilidade.

Isolamento (isolamento). Os eventos que ocorrem em uma transação devem ser ocultados de outras transações em execução simultânea. Se esta condição não fosse atendida, então, pelos motivos acima mencionados, seria impossível a transação retornar ao seu início. Para obter isolamento, métodos chamados de sincronização são usados ​​...

Durabilidade (Durabilidade). Depois que uma transação é concluída e seus resultados confirmados no banco de dados, o sistema deve garantir que esses resultados sobrevivam a quaisquer falhas subsequentes. Como não há escopo de controle que abranja conjuntos de transações, o sistema de gerenciamento de banco de dados (DBMS) não tem controle além dos limites das transações.

Portanto, o usuário deve ter a garantia de que, se o sistema o informar que algo aconteceu, esse "algo" realmente aconteceu. Uma vez que, por definição, qualquer transação (concluída com sucesso - S.K.) está correta, os resultados de transações inevitavelmente incorretas (ou seja, transações contendo dados incorretos) só podem ser eliminados pela transação "contra" correspondente (contratransação).

3.2 O surgimento das transações

Essas quatro propriedades — Atomicidade, Consistência, Isolamento e Durabilidade (ACID) — descrevem os principais recursos do paradigma transacional que afetam muitos aspectos do design do sistema de banco de dados. Portanto, acreditamos que a capacidade de qualquer sistema em suportar transações é a pedra de toque (teste ACID) da qualidade desse sistema.

Um programa PL/1-SQL simples que transfere fundos de uma conta para outra.

FUNDS_TRANSFER. PROCEDURE,
 $BEGIN_TRANSACTION;
 ON ERROR DO;                                   /* in case of error */
          $RESTORE_TRANSACTION,                 /* undo all work */
          GET INPUT MESSAGE;                    /* reacquire input */
          PUT MESSAGE ('TRANSFER FAILED');      /* report failure */
          GO TO COMMIT;
          END;
 GET INPUT MESSAGE;                             /* get and parse input */
 EXTRACT ACCOUNT_EBIT, ACCOUNT_CREDIT,
  AMOUNT FROM MESSAGE,
 $UPDATE ACCOUNTS                               /* do debit */
              SET BALANCE ffi BALANCE - AMOUNT
     WHERE ACCOUNTS.NUMBER = ACCOUNT_DEBIT;
 $UPDATE ACCOUNTS                               /* do credit */
              SET BALANCE = BALANCE + AMOUNT
     WHERE ACCOUNTS.NUMBER = ACCOUNT_CREDIT;
 $INSERT INTO HISTORY                           /* keep audit trail */
    <DATE, MESSAGE>;
 PUT MESSAGE ('TRANSFER DONE');                 /* report success */
COMMIT:                                         /* commit updates */
 $COMMIT_TRANSACTION;
 END;                                           /* end of program */

Forneci um exemplo desse código para lembrá-lo de que, de fato, as propriedades ACID, por um lado, podem ser consideradas como requisitos para qualquer SGBD que afirma suportar transações e, por outro lado, como a definição de uma transação em um sistema de banco de dados . Esta definição é totalmente consistente com a prática mundana. É difícil imaginar, por exemplo, que um cliente realizando uma transação bancária (seja com a ajuda de um caixa humano ao vivo ou usando serviços bancários pela Internet) não espere que o banco satisfaça todas as propriedades do ACID. Um banco que não oferece suporte a propriedades ACID para suas transações, na melhor das hipóteses, perderá clientes e, na pior, irá à falência.

3.3 Conectividade ACID

É muito importante que as propriedades ACID sejam inseparáveis, descartar qualquer uma delas torna a combinação restante sem sentido. Em particular, se descartarmos a propriedade de consistência (no sentido em que foi usada na citação acima), perderemos o critério de correção de uma transação. O sistema de banco de dados não será capaz de decidir de forma significativa se as transações são permitidas ou não, e todas as verificações da exatidão das operações executadas no estado atual do banco de dados deverão ser executadas no código do aplicativo.

Você precisa entender que, neste caso, estamos falando de consistência lógica. O cliente do banco precisa que o banco trabalhe de acordo com as regras por ele estabelecidas e conhecidas pelos clientes, para que seja impossível realizar qualquer transação que viole essas regras, para que a próxima transação do mesmo cliente seja executada em um ambiente acordado de acordo com estas regras.

O cliente da loja online necessita que os bens por ele encomendados e pagos lhe sejam entregues em tempo útil (de acordo com as regras estabelecidas e do conhecimento do cliente). Caso contrário, ele não confiará nesta loja. Ao mesmo tempo, nem o cliente do banco nem o cliente da loja na Internet se preocupam com a cozinha interna da empresa, quais ações internas são realizadas para concluir sua transação. O cliente não se importa como a consistência física dessa empresa é mantida, como as operações são realizadas na camada física.

Se o DBMS cuidar de manter a consistência lógica das transações (e do banco de dados), os aplicativos se tornarão mais simples, compreensíveis e confiáveis. Toda a lógica da área de aplicação (banco, loja, armazém, etc.) sobre as transações e o estado válido dos dados vai para o sistema de banco de dados. E os requisitos para este sistema são muito simples: suporte para transações ACID, levando em consideração as regras de consistência fornecidas no banco de dados pelo aplicativo. Do meu ponto de vista, a rejeição das transações ACID cria dificuldades imoderadas para os desenvolvedores de aplicativos, que, goste ou não, terão que implementar algo semelhante para atender às necessidades naturais de seus clientes.

E mais uma vez observo que as propriedades ACID, de fato, definem o conceito de uma transação. Na minha opinião, para ter pelo menos alguma possibilidade de falar sobre um sistema de gerenciamento de dados transacionais em que a propriedade de consistência da transação não é suportada, é absolutamente necessário definir o que se entende pelo termo transação neste caso.

Infelizmente, hoje, em muitos casos (em particular, isso é característico da direção do NoSQL), as pessoas falam sobre o suporte a aplicativos OLTP sem especificar nada a que tipo de transação eles se referem. Portanto, neste artigo, usarei a combinação ACID transação para me referir a transações reais, e o termo não qualificado transação será usado em um sentido informal, diferente em diferentes contextos.

Vamos agora lidar com o "teorema" do CAP e tentar descobrir o que significa consistência no sentido de Brewer.