Требования ACID: Краткий обзор
ACID (Atomicity, Consistency, Isolation, Durability) — это набор характеристик, обеспечивающих надежность транзакций в базах данных.
Транзакция в БД — это логическая операция, состоящая из одного или нескольких запросов, которые выполняются как единое целое.
Атомарность
Транзакция рассматривается как "неделимая" единица работы. Транзакция либо полностью выполняется, либо вообще не выполняется. Нет промежуточных состояний.
Согласованность
Транзакция должна переводить базу данных из одного согласованного состояния в другое (например, в каждом столбце значения имеют нужный тип данных, сохранена ссылочная целостность, операции выполнены по порядку). Если БД была в согласованном состоянии до транзакции, она должна остаться такой и после.
Изолированность
Другие транзакции не должны видеть промежуточных результатов текущей транзакции. Каждая транзакция должна быть изолирована от других: её выполнение не должно влиять на другие транзакции.
Долговечность (надёжность)
После успешного завершения транзакции изменения в БД должны сохраняться даже в случае сбоев системы. Данные, внесённые в БД, должны быть долговечными.
Когда применяется ACID
- В финансовых, банковских, бухгалтерских приложениях, где точность данных является критически важной.
- В системах управления заказами и инвентарем, управления ресурсами (таких как авиабилеты, номера номеров и т.д.).
ACID не актуальны, когда:
- Производительность имеет большее значение, чем полная гарантия целостности данных.
- Часто выполняются параллельные операции и где допустимы некоторые компромиссы в обмен на повышенную производительность.
- Данные имеют низкую ценность или могут быть легко восстановлены.
- Данные имеют высокую степень избыточности или дублирования.
ACID в реляционных/нереляционных СУБД
- Большинство традиционных реляционных БД поддерживают требования ACID.
- В распределенных БД связанные данные находятся на нескольких узлах. Транзакции в NoSQL затруднены, и в большинстве СУБД требования ACID не удовлетворяются. Но некоторые NoSQL СУБД (например, графовая Neo4j и документоориентированная MarkLogic) могут обеспечивать свойства ACID.
Пример
Пусть есть БД с информацией о банковских счетах Алисы и Боба. Рассмотрим две транзакции:
- Перевод денег: Боб переводит Алисе 100$ со своего счета.
- Покупка печенек: Алиса покупает на 50$ со своей банковской карты.
У Алисы изначально 0 на счету. У Боба 110$.
Применение ACID гарантирует:
- Атомарность: Покупка печенек завершится ошибкой, так как баланс 0$, деньги не будут списаны. Отмена всей транзакции.
- Согласованность: После обеих транзакций у Алисы должно остаться 50$ (0 + 100 - 50), а у Боба 10$. Операции выполнены в правильном порядке. Данные по клиентам корректно отражены.
- Изолированность: Если покупка происходит в то время, когда перевод еще не завершился, в БД не появится несогласованных данных. Блокировки и версионирование в БД изолируют транзакции во избежание путаницы в значениях.
- Долговечность: Если обе транзакции завершились успешно, изменения (перевод и покупка) будут сохранены в базе данных даже в случае сбоев системы.
Как связаны ACID и CAP-теорема
Это две разные концепции, касающиеся транзакций в распределенных системах. Они не противоречат друг другу.
- Цель ACID — обеспечить надежность в транзакционных БД, где данные обрабатываются в рамках централизованной системы.
- CAP-теорема рассматривается там, где система распределена между несколькими узлами, что создает потенциальные проблемы согласованности и доступности.