ACID транзакции

ACID (Atomicity, Consistency, Isolation, Durability) — это набор свойств, гарантирующих надёжную обработку транзакций в базах данных и других системах управления данными. Транзакция представляет собой логически завершённую последовательность операций (например, перевод денег со счёта на счёт), которая переводит базу данных из одного целостного состояния в другое. Соблюдение принципов ACID необходимо для обеспечения корректности, предсказуемости и устойчивости данных при параллельном доступе и сбоях.

История возникновения

Понятие ACID было сформулировано в начале 1980-х годов как ответ на растущую потребность в надёжных системах управления базами данных (СУБД). Термин впервые ввёл Андреас Ройтер в 1983 году, а впоследствии популяризировали исследователи Джим Грей и Тео Хардер. До этого реляционные базы данных, такие как System R (IBM) и Ingres, уже реализовывали отдельные свойства транзакций, но общая модель была формализована именно в рамках ACID. В 1990-е годы ACID стал стандартом де-факто для большинства коммерческих СУБД (Oracle, IBM DB2, Microsoft SQL Server), а также для многих открытых систем (PostgreSQL, MySQL с InnoDB). С развитием NoSQL-баз данных (например, MongoDB, Cassandra) в 2000-х годах возникла альтернативная модель BASE (Basically Available, Soft state, Eventually consistent), которая жертвует строгой согласованностью ради масштабируемости, однако ACID остаётся обязательным требованием для финансовых, банковских и критических приложений.

Свойства ACID

Каждая буква аббревиатуры соответствует одному из четырёх фундаментальных свойств транзакции.

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

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

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

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

Изоляция (Isolation)

Изоляция гарантирует, что параллельно выполняющиеся транзакции не влияют друг на друга. Каждая транзакция видит данные так, как если бы она выполнялась в одиночку, даже если на самом деле их много. Уровни изоляции (от самого низкого до самого высокого) определяют, какие аномалии параллельного доступа допускаются:

• Read Uncommitted (чтение незафиксированных данных) — транзакция может читать данные, изменённые другой незавершённой транзакцией (грязное чтение). Используется редко из-за риска некорректных данных.
• Read Committed (чтение зафиксированных данных) — транзакция видит только те изменения, которые уже зафиксированы другими транзакциями. Грязное чтение исключено, но возможны неповторяющееся чтение (когда повторное чтение той же строки даёт разные значения) и фантомное чтение (появление новых строк, удовлетворяющих условию запроса).
• Repeatable Read (повторяемое чтение) — гарантирует, что при повторном чтении одной и той же строки в рамках транзакции её значение не изменится. Неповторяющееся чтение исключено, но фантомное чтение возможно.
• Serializable (сериализуемый) — самый строгий уровень. Транзакции выполняются так, как если бы они шли последовательно, одна за другой. Все аномалии параллельного доступа исключены. Достигается блокировками или механизмами многоверсионности (MVCC).

Большинство современных СУБД по умолчанию используют Read Committed (например, PostgreSQL, Oracle) или Repeatable Read (MySQL с InnoDB). Выбор уровня изоляции — компромисс между производительностью и надёжностью.

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

Долговечность гарантирует, что после успешного завершения транзакции (commit) все её изменения сохраняются даже в случае сбоя системы (отключение питания, крах операционной системы). Обычно это достигается записью данных на энергонезависимый носитель (жёсткий диск, SSD) и ведением журнала транзакций (write-ahead logging, WAL). В случае сбоя при восстановлении система воспроизводит (replay) зафиксированные транзакции из журнала, чтобы восстановить последнее согласованное состояние.

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

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

• Журнал транзакций (WAL) — запись всех изменений до их применения к основным файлам базы данных. Позволяет выполнять откат и восстановление.
• Блокировки (locks) — управление параллельным доступом. Разделяются на блокировки строк, страниц, таблиц. Бывают разделяемые (shared) и исключительные (exclusive). Используются для обеспечения изоляции.
• Многоверсионность (MVCC) — хранение нескольких версий одной строки, чтобы читающие транзакции не блокировали пишущие и наоборот. Широко применяется в PostgreSQL, Oracle, MySQL (InnoDB).
• Буферный кеш — временное хранение данных в оперативной памяти для ускорения доступа. При сбое содержимое кеша может быть потеряно, поэтому требуется синхронизация с журналом.

Критика и ограничения

Строгое соблюдение ACID может приводить к снижению производительности, особенно в распределённых системах с высокой нагрузкой. Например, сериализуемый уровень изоляции требует интенсивных блокировок, что замедляет параллельную обработку. В распределённых базах данных (кластеры, шардирование) полная согласованность ACID часто невозможна из-за теоремы CAP (Consistency, Availability, Partition tolerance) — одновременно можно обеспечить только два из трёх свойств. Поэтому многие современные системы (особенно NoSQL) выбирают модель BASE, где согласованность достигается в конечном счёте (eventual consistency), а не мгновенно.

Тем не менее, для финансовых транзакций, бронирования билетов, управления заказами и других критических сценариев ACID остаётся обязательным требованием. В таких системах допустимы компромиссы в производительности ради гарантии целостности данных.

Примеры

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

Источники

• Gray, J., & Reuter, A. (1993). Transaction Processing: Concepts and Techniques. Morgan Kaufmann.
• Date, C. J. (2003). An Introduction to Database Systems (8th ed.). Addison-Wesley.
• Silberschatz, A., Korth, H. F., & Sudarshan, S. (2010). Database System Concepts (6th ed.). McGraw-Hill.
• Документация PostgreSQL: «Transaction Isolation» (https://www.postgresql.org/docs/current/transaction-iso.html).
• Документация MySQL: «InnoDB and ACID» (https://dev.mysql.com/doc/refman/8.0/en/mysql-acid.html).