ACID-транзакции

ACID-транзакции (от английского Atomicity, Consistency, Isolation, Durability — атомарность, согласованность, изолированность, долговечность) — это набор свойств, гарантирующих надёжное выполнение последовательности операций с данными в базах данных (БД) и информационных системах. Транзакция, удовлетворяющая требованиям ACID, считается атомарной единицей работы, которая переводит систему из одного согласованного состояния в другое, даже в условиях сбоев, параллельного доступа и ошибок. Концепция была формализована в начале 1980-х годов, а термин введён в 1983 году исследователями Тревором Хардером и Андреасом Райтером. ACID-транзакции являются фундаментом реляционных СУБД (систем управления базами данных), таких как PostgreSQL, MySQL, Oracle Database, Microsoft SQL Server, и широко применяются в финансовых, банковских, учётных и других критически важных системах.

История и предпосылки возникновения

До появления реляционных баз данных (1960–1970-е годы) обработка информации в компьютерных системах часто была последовательной и не гарантировала целостности при сбоях. С развитием многопользовательских систем и распределённых вычислений возникла потребность в механизмах, которые позволяли бы выполнять несколько операций как единое целое, не допуская частичного обновления данных. В 1970-х годах Эдгар Кодд, создатель реляционной модели, заложил основы для обеспечения согласованности, но формальные требования к транзакциям были сформулированы позже. В 1983 году вышла работа Хардера и Райтера «Principles of Transaction-Oriented Database Recovery», где впервые явно выделены четыре свойства — ACID. С тех пор эти принципы стали стандартом де-факто для всех промышленных СУБД, стремящихся к высокой надёжности.

Свойства ACID

Каждое из четырёх свойств определяет конкретное ограничение на поведение транзакции.

Атомарность (Atomicity)

Атомарность означает, что транзакция выполняется полностью или не выполняется вовсе. Если в процессе выполнения транзакции происходит сбой (отказ оборудования, ошибка программы, потеря связи), все уже выполненные операции должны быть отменены (откат, rollback). Система гарантирует, что никакие промежуточные результаты не сохраняются в базе данных. Пример: при переводе денег со счёта на счёт операция списания и операция зачисления должны быть выполнены обе, иначе, при сбое после списания, средства не пропадают — транзакция откатывается, и оба счёта возвращаются в исходное состояние.

Согласованность (Consistency)

Согласованность гарантирует, что до начала и после завершения транзакции база данных находится в логически корректном состоянии. Все определённые в схеме БД ограничения (первичные ключи, внешние ключи, уникальность, проверочные условия, триггеры) должны быть соблюдены. Транзакция не может нарушить целостность данных. Если какое-либо ограничение оказывается нарушено, транзакция откатывается. Согласованность — это ответственность как системы (проверка ограничений), так и разработчика (правильная бизнес-логика).

Изолированность (Isolation)

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

• READ UNCOMMITTED — допускается чтение незафиксированных данных других транзакций.
• READ COMMITTED — читаются только зафиксированные данные (используется по умолчанию во многих СУБД).
• REPEATABLE READ — гарантирует, что повторное чтение тех же строк в рамках одной транзакции даст одинаковый результат.
• SERIALIZABLE — самый строгий уровень, обеспечивающий полную изолированность.

Долговечность (Durability)

Долговечность гарантирует, что после успешного завершения транзакции (коммита) все внесённые изменения сохраняются в базе данных постоянно и не могут быть потеряны даже при последующем сбое питания, крахе системы или аппаратной ошибке. Обычно это достигается записью изменений в энергонезависимый журнал (WAL — Write-Ahead Logging) до того, как они будут применены к основным файлам данных. Таким образом, после перезапуска система может восстановить все зафиксированные транзакции.

Реализация в СУБД

Большинство реляционных СУБД реализуют ACID-гарантии с помощью комбинации механизмов:

• Блокировки (locks) — для управления параллельным доступом (например, блокировка строки или таблицы на время транзакции).
• Журналирование (logging) — для обеспечения долговечности и возможности отката.
• Управление версиями (MVCC — Multi-Version Concurrency Control) — позволяет читателям не блокировать писателей и наоборот, обеспечивая изолированность. MVCC широко применяется в PostgreSQL, Oracle, MySQL (InnoDB).
• Точки сохранения (savepoints) — позволяют откатывать часть транзакции, не отменяя её целиком.

Критика и альтернативы

ACID-транзакции обеспечивают высокую надёжность, но налагают ограничения на масштабируемость и производительность, особенно в распределённых системах с высокой нагрузкой. В 2000-х годах, с развитием NoSQL-баз данных (например, Apache Cassandra, MongoDB, Riak), возникла концепция BASE (Basically Available, Soft state, Eventual consistency — базовая доступность, мягкое состояние, согласованность в конечном счёте), которая жертвует строгой согласованностью и изолированностью ради доступности и горизонтального масштабирования. Однако для задач, где критична целостность данных (финансы, бухгалтерия, учёт), ACID остаётся обязательным требованием. Некоторые NoSQL-системы, такие как FoundationDB или CockroachDB, стремятся обеспечить ACID-гарантии в распределённой среде, используя распределённые протоколы (например, Paxos или Raft) и строгую сериализуемость.

Применение

ACID-транзакции используются везде, где требуется точность и надёжность обработки данных:

• Банковские переводы и платежи.
• Бронирование билетов и отелей.
• Управление складскими запасами (учёт товаров).
• Электронная коммерция (оформление заказов).
• Медицинские информационные системы (ведение историй болезней).
• Системы управления версиями (Git, SVN).

Интересные факты

• Термин ACID был предложен как антоним к BASE, чтобы подчеркнуть противоположность подходов.
• В русскоязычной литературе и документации часто используется транслитерация «АСИД» или «КИСЛОТА», но стандартным является написание латиницей.
• Не все СУБД, называющие себя реляционными, полностью реализуют ACID — например, SQLite не поддерживает полную изолированность для параллельных записей.
• В распределённых системах теорема CAP (Consistency, Availability, Partition tolerance) утверждает, что невозможно одновременно обеспечить строгую согласованность (аналог ACID), высокую доступность и устойчивость к разделению сети. Поэтому ACID-гарантии в распределённых БД достигаются за счёт снижения доступности или производительности.

Источники

• Harder, T., Reuter, A. (1983). «Principles of Transaction-Oriented Database Recovery». ACM Computing Surveys.
• Gray, J., Reuter, A. (1993). «Transaction Processing: Concepts and Techniques». Morgan Kaufmann.
• Кодд, Э. Ф. (1970). «A Relational Model of Data for Large Shared Data Banks». Communications of the ACM.
• Документация PostgreSQL: «Chapter 13. Concurrency Control».
• Документация MySQL: «InnoDB and the ACID Model».
• Bernstein, P. A., Newcomer, E. (2009). «Principles of Transaction Processing». Morgan Kaufmann.