Свойства ACID

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

История и происхождение

Понятие ACID было введено в конце 1970-х — начале 1980-х годов. Термин впервые предложил в 1983 году исследователь Тэо Хэрдер (Theo Härder) и Андреас Ройтер (Andreas Reuter) в статье «Principles of Transaction-Oriented Database Recovery». Однако сами свойства были сформулированы ранее, в контексте разработки ранних реляционных СУБД (System R, Ingres). Основной целью было создание модели, которая позволила бы разработчикам абстрагироваться от проблем параллельного доступа и сбоев, гарантируя, что транзакция либо выполняется полностью, либо не выполняется вовсе.

Основные свойства ACID

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

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

Атомарность означает, что транзакция выполняется как неделимая единица работы. Все операции внутри транзакции (например, чтение, запись, обновление) либо выполняются полностью, либо не выполняются вовсе. Если в процессе выполнения транзакции происходит сбой (отказ оборудования, ошибка программного обеспечения, нарушение целостности), система должна откатить все изменения, сделанные в рамках этой транзакции, до состояния, предшествовавшего её началу. Это состояние называется «откат» (rollback). Если транзакция завершается успешно, все её изменения фиксируются (commit) и становятся постоянными.

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

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

Изоляция (Isolation)

Изоляция определяет, как изменения, вносимые одной транзакцией, видны другим параллельно выполняющимся транзакциям. Свойство изоляции предотвращает проблемы параллельного доступа, такие как «грязное чтение» (dirty read), «неповторяющееся чтение» (non-repeatable read) и «фантомное чтение» (phantom read). В идеале, каждая транзакция должна выполняться так, как если бы она была единственной в системе, даже если на самом деле их несколько. На практике для повышения производительности СУБД предлагают различные уровни изоляции, которые ослабляют строгость этого требования.

Уровни изоляции

Стандарт SQL определяет четыре уровня изоляции, перечисленные от наиболее строгого к наименее строгому:

1. Serializable (Сериализуемый): Самый строгий уровень. Транзакции выполняются последовательно, полностью изолированно. Гарантирует отсутствие любых аномалий параллельного доступа.
2. Repeatable Read (Повторяемое чтение): Гарантирует, что если транзакция считывает одну и ту же строку дважды, она получит одинаковые данные, даже если другая транзакция изменит эту строку. Однако возможны «фантомные» строки (появление новых строк, удовлетворяющих условию запроса, после его выполнения).
3. Read Committed (Чтение зафиксированных данных): Гарантирует, что транзакция видит только те данные, которые были зафиксированы (commit) другими транзакциями. Предотвращает «грязное чтение», но допускает «неповторяющееся чтение» и «фантомы».
4. Read Uncommitted (Чтение незафиксированных данных): Самый слабый уровень. Транзакция может видеть данные, которые ещё не были зафиксированы другими транзакциями («грязное чтение»). Используется редко, так как может привести к серьёзным ошибкам.

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

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

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

Большинство классических реляционных систем управления базами данных (СУБД), таких как PostgreSQL, MySQL (с движками InnoDB или NDB Cluster), Oracle Database, Microsoft SQL Server, в полной мере поддерживают ACID-транзакции. Однако реализация может различаться в деталях. Например, MySQL с движком MyISAM не поддерживает транзакции, в то время как InnoDB — поддерживает.

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

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

В ответ на это была предложена альтернативная модель — BASE (Basically Available, Soft state, Eventually consistent — «базовая доступность, мягкое состояние, конечная согласованность»). Системы, основанные на BASE, жертвуют строгой согласованностью и изоляцией в пользу высокой доступности и производительности. Они гарантируют, что данные в конечном итоге станут согласованными, но не обязательно сразу после записи. Такие системы часто называют NoSQL-базами данных (например, Cassandra, MongoDB, Couchbase). Однако и в NoSQL-системах существуют свои механизмы обеспечения атомарности и долговечности на уровне отдельных операций.

Применение

Свойства ACID критически важны в следующих областях:

• Финансовые системы: Переводы средств, обработка платежей, ведение бухгалтерского учёта. Ошибка в транзакции может привести к финансовым потерям.
• Системы бронирования: Авиабилеты, гостиницы, билеты на мероприятия. Необходимо гарантировать, что один и тот же ресурс не будет продан дважды.
• Системы управления запасами: Учёт товаров на складе, инвентаризация.
• Медицинские информационные системы: Хранение и обработка записей пациентов, рецептов, результатов анализов.
• Электронная коммерция: Обработка заказов, управление корзинами покупок, списание средств.

Источники

• Härder, T., & Reuter, A. (1983). Principles of transaction-oriented database recovery. ACM Computing Surveys (CSUR), 15(4), 287-317.
• Gray, J., & Reuter, A. (1993). Transaction Processing: Concepts and Techniques. Morgan Kaufmann.
• Silberschatz, A., Korth, H. F., & Sudarshan, S. (2010). Database System Concepts (6th ed.). McGraw-Hill.
• Стандарт ISO/IEC 9075:2016 (SQL:2016) — раздел, описывающий уровни изоляции транзакций.