ACID

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

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

Понятие ACID возникло в контексте развития реляционных баз данных и систем управления базами данных (СУБД). В 1970-х годах, с ростом популярности реляционной модели Эдгара Кодда, возникла потребность в стандартизации поведения транзакций — последовательностей операций, которые должны выполняться как единое целое. В 1983 году Тео Хардер и Андреас Ройтер опубликовали работу «Principles of Transaction-Oriented Database Recovery», где впервые систематизировали требования к транзакциям. Позднее, в 1985 году, Джим Грей, один из пионеров теории транзакций, формализовал эти свойства под аббревиатурой ACID. С тех пор ACID стал фундаментальным принципом для большинства классических реляционных СУБД (Oracle, PostgreSQL, MySQL, Microsoft SQL Server).

Свойства ACID

Каждое свойство ACID описывает определённый аспект поведения транзакции:

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

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

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

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

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

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

• Грязное чтение (dirty read) — чтение данных, изменённых незавершённой транзакцией.
• Неповторяющееся чтение (non-repeatable read) — повторное чтение в рамках одной транзакции даёт разные результаты из-за изменений, внесённых другой транзакцией.
• Фантомное чтение (phantom read) — при повторном чтении появляются новые строки, добавленные другой транзакцией.

Для управления изоляцией существуют уровни изоляции (Read Uncommitted, Read Committed, Repeatable Read, Serializable), которые определяют, какие из этих проблем допускаются.

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

Долговечность гарантирует, что после успешного завершения транзакции (фиксации, commit) все внесённые изменения сохраняются в базе данных и не могут быть потеряны даже при последующем сбое системы (отключение питания, сбой диска). Обычно это достигается записью изменений в журнал транзакций (transaction log) до того, как они будут применены к основным файлам данных. В случае сбоя система восстанавливает состояние по журналу.

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

Большинство классических реляционных СУБД (Oracle, PostgreSQL, MySQL с движком InnoDB, Microsoft SQL Server) реализуют полную поддержку ACID. Это достигается за счёт:

• Журнала транзакций (Write-Ahead Logging, WAL) — все изменения сначала записываются в журнал, а затем применяются к данным. Это обеспечивает долговечность и атомарность.
• Механизмов блокировок (locks) и многоверсионности (MVCC) — для обеспечения изолированности. MVCC позволяет читателям видеть «снимок» данных на момент начала транзакции, не блокируя записывающие транзакции.
• Проверок ограничений (constraints, triggers) — для обеспечения согласованности.

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

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

Несмотря на широкое распространение, ACID имеет ограничения, особенно в распределённых системах и системах с высокой нагрузкой (high-load). Обеспечение строгой изолированности и атомарности в распределённой среде требует значительных накладных расходов (синхронизация, блокировки, сетевые задержки). Это привело к появлению альтернативных моделей, таких как BASE (Basically Available, Soft state, Eventual consistency) — принцип, используемый в NoSQL-системах (Cassandra, MongoDB, CouchDB). BASE жертвует строгой согласованностью ради доступности и производительности, допуская временные расхождения данных, которые со временем приходят к согласованному состоянию (eventual consistency). Выбор между ACID и BASE зависит от требований конкретного приложения: для финансовых систем, банковских операций, систем бронирования критична строгая согласованность (ACID); для социальных сетей, систем кэширования, аналитики — допустима модель BASE.

Применение

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

• Банковские и финансовые системы — переводы, списания, начисления процентов.
• Системы бронирования — авиабилеты, гостиницы, залы.
• Системы управления складскими запасами — учёт товаров, инвентаризация.
• Медицинские информационные системы — запись пациентов, назначения, результаты анализов.
• Электронная коммерция — оформление заказов, списание средств, обновление остатков.

В этих областях потеря данных или нарушение согласованности могут привести к серьёзным финансовым или юридическим последствиям.

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

• Аббревиатура ACID была придумана Джимом Греем как противопоставление термину «BASE», который он же предложил для описания свойств распределённых систем с ослабленной согласованностью.
• В некоторых СУБД (например, PostgreSQL) уровень изоляции по умолчанию — Read Committed, что допускает неповторяющееся чтение, но защищает от грязного чтения. Для полной изолированности требуется уровень Serializable.
• Термин «транзакция» в контексте баз данных происходит от латинского transactio — «соглашение», «сделка».

Источники

• 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.
• Date, C. J. (2003). «An Introduction to Database Systems» (8th ed.). Addison-Wesley.
• Elmasri, R., Navathe, S. B. (2016). «Fundamentals of Database Systems» (7th ed.). Pearson.
• Документация PostgreSQL: «Transaction Isolation».