Концепция ACID

3.1 Появление ACID

ACID аббревиатура появилась в 1983 г. в статье Тео Хаердера и Адреаса Рейтера. Это акроним для атомарности, целостности, изоляции и дурации, четыре характеристики, которые должны быть выполнены в транзакциях в базах данных. Чтобы сделать текст проще и понятнее, я приведу перевод фрагмента этой статьи (с небольшими изменениями). Это фрагмент описывает пример банковской транзакции, при которой деньги переводятся с одного счета на другой.

Для того чтобы обеспечить атомарность, целостность, изоляцию и дурацию этой транзакции, необходимо проверить и подтвердить все детали транзакции перед проведением дальнейших действий. После подтверждения деталей транзакции система ACID проверит окончательную целостность до проведения платежа и защитит его от некорректных изменений.

Концепция транзакции заставляет все изменения между $BEGIN_TRANSACTION и $COMMIT_TRANSACTION выполняться полностью: или все изменения отражаются в базе данных, или ничего не происходит. Если пользователь ввел оператор ERROR с $RESTORE_TRANSACTION до $COMMIT_TRANSACTION, никакие изменения не будут зафиксированы.

Чтобы достичь неделимости, транзакция должна иметь следующие четыре свойства:

Atomicity (Атомарность). Транзакция должна иметь описанный выше тип "все или ничего" и должна быть выполнена без ошибок и проблем. Таким образом, пользователь может быть уверенным, что все действия по его транзакции будут выполнены правильно. После завершения транзакции пользователь должен получить подтверждение о ее успешном завершении, и быть уверенным в том, что все действия были выполнены корректно и правильно.

Consistency (Согласованность). Транзакция завершается нормально (EOT - конец транзакции) и сохраняет согласованность базы данных. Другими словами, успешная транзакция зафиксирует допустимые результаты. Это необходимо для поддержки долговечности.

Isolation (Изоляция). События, происходящие внутри транзакции, должны быть абсолютно скрыты от других одновременно выполняемых транзакций. Такое условие очень важно, поскольку иначе могут возникнуть сложности при попытке восстановить данную транзакцию в исходное состояние. Для того чтобы достичь изоляции, специально используются различные методы синхронизации, которые позволяют поддерживать достаточно высокий уровень защиты данных. Применяя различные методы синхронизации, можно получить стойкость и противостоять любым попыткам вмешательства, помогая гарантировать безопасность и целостность данных.

Durability (Долговечность). После завершения транзакции и записи результатов в базу данных система должна гарантировать их надежность в случае последующих сбоев. Так как нет никакого механизма управления наборами транзакций, система управления базами данных (СУБД) не имеет контроля за границами транзакций.

Поэтому пользователю должно быть гарантировано, что если система уведомляет о произошедшем событии, то это событие действительно произошло. Все успешно завершенные транзакции являются корректными. Ошибочные данные в результате некорректных транзакций могут быть устранены с помощью соответствующей "контр"-транзакции.

3.2 Появление транзакций

Четыре свойства ACID влияют на разработку баз данных. Тест ACID является испытанием для оценки качества системы. Примером может быть программа на PL/1-SQL для перевода средств с одного счета на другой.

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 */

Я привел пример кода, чтобы подчеркнуть, что свойства ACID можно рассматривать как требования к любой СУБД, претендующей на поддержку транзакций, и как определение транзакции в системе баз данных. Это соответствует житейской практике. Например, клиент, выполняющий банковскую транзакцию, ожидает, что банк будет соблюдать свойства ACID. Банк, не поддерживающий эти свойства, потеряет клиентов или даже обанкротится.

3.3 Связность ACID

Очень важно, чтобы все свойства ACID были вместе. Если мы выбрасываем какое-либо из них, то другие становятся неполезными. Например, без свойства согласованности мы не можем узнать, можно ли использовать транзакции. Тогда проверка правильности действий должна быть выполнена в приложениях, что усложняет программирование.

Нужно понимать, что в данном случае речь идет о логической согласованности. Клиенту банка нужно, чтобы банк работал по установленным и известным клиентам правилам. Таким образом, нельзя будет выполнять транзакции, нарушающие эти правила. Следующая транзакция будет выполняться в среде, согласованной с этими правилами.

Клиенту онлайн-магазина нужно, чтобы заказанный и оплаченный товар был доставлен вовремя и в соответствии с установленными и известными клиенту правилами. В этом случае ему предоставляется гарантия доверия к магазину и его способности выполнять поставленные транзакции в срок. Клиенту нет дела до внутренней кухни предприятия, до того, какие действия предпринимаются для выполнения транзакции, до того, каким образом поддерживается физическая согласованность предприятия и каким образом выполняются операции на физическом уровне. Однако, чтобы достичь этой цели, магазину необходимо иметь процессы и систему, которые позволяют доставлять заказы в соответствии с ответственностью и обеспечивают поддержание предоставленной гарантии клиенту.

Когда СУБД берет на себя ответственность за поддержку логической согласованности транзакций и баз данных, приложения становятся проще, понятнее и надежнее. Приложение хранит всю логику прикладной области (такую как банк, магазин или склад) касающуюся транзакций и допустимого состояния данных. Для этой системы требуется поддержка ACID-транзакций с согласованностью, обеспеченной приложением. Отказ от ACID-транзакций создаст огромные проблемы для разработчиков приложений, которые будут иметь дело с похожей реализацией, чтобы удовлетворить потребности клиентов.

Свойства ACID определяют понятие транзакции. Чтобы говорить о транзакционной системе управления данными, в которой не поддерживается свойство согласованности транзакций, необходимо понять, что подразумевается под термином «транзакция».

В многих случаях (особенно в NoSQL) люди говорят о поддержке приложений с транзакциями. Так что в этой статье я буду называть эти транзакции "ACID-транзакциями". Термин "транзакция" будет использоваться в неформальном смысле, в зависимости от контекста.