Что такое ACID в контексте баз данных?

Question

Что такое ACID в контексте баз данных?

Тип вопроса: Базы данных Вероятность: 49% Категория: PHP Разработчик

Ответ

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

Расшифровка и практический смысл:

Атомарность (Atomicity): Транзакция выполняется как единое целое. Либо выполняются все ее операции, либо ни одна. При сбое (ошибка в коде, отключение питания) СУБД откатывает (rollback) частично выполненные изменения. Это решается механизмом отката (rollback) и журналирования (WAL - Write-Ahead Logging).
- Пример: Перевод денег между счетами. Списание с одного и зачисление на другой должны произойти вместе. Если зачисление не удалось, списание должно быть отменено.
Согласованность (Consistency): Транзакция переводит базу данных из одного валидного состояния в другое валидное состояние. Это означает, что не нарушаются все заданные правила: ограничения целостности (PRIMARY KEY, FOREIGN KEY, UNIQUE, CHECK), триггеры и бизнес-правила.
- Пример: В таблице employees есть ограничение salary > 0. Транзакция, пытающаяся установить зарплату в -100, будет отменена, и база останется в согласованном состоянии.
Изолированность (Isolation): Параллельно выполняющиеся транзакции не должны влиять друг на друга. Результаты их работы должны быть такими же, как если бы они выполнялись последовательно. На практике полная изоляция дорога, поэтому СУБД предлагают уровни изоляции (читаемость, повторяемость чтения и т.д.), которые ослабляют это свойство для повышения производительности.
- Проблема: "Грязное" чтение (чтение незафиксированных данных другой транзакции).
- Решение: Уровень изоляции READ COMMITTED в PostgreSQL предотвращает это.
Долговечность (Durability): После успешного завершения транзакции (COMMIT) внесенные ею изменения становятся постоянными и сохраняются даже в случае сбоя системы (например, после восстановления питания). Это обеспечивается записью данных и журналов транзакций на постоянное хранилище (диск).

Практический пример на SQL:

-- Начало транзакции
BEGIN TRANSACTION;

-- 1. Резервируем товар на складе
UPDATE warehouse SET quantity = quantity - 1 WHERE product_id = 123;
-- 2. Создаем запись о заказе
INSERT INTO orders (user_id, product_id, status) VALUES (456, 123, 'reserved');

-- Если все операции прошли успешно, фиксируем изменения
COMMIT;

-- Если на любом этапе произошла ошибка (например, товара нет в наличии),
-- мы можем откатить все изменения этой транзакции:
-- ROLLBACK;

Важно: Не все СУБД или режимы работы (например, некоторые NoSQL) полностью соответствуют ACID. Часто в распределенных системах жертвуют строгой согласованностью (C) или изолированностью (I) в пользу доступности и устойчивости к разделению (CAP-теорема), что приводит к моделям вроде BASE.

Ответ 18+ 🔞

А, слушай, про ACID? Ну это такая классика, ёпта, как "Терминатор 2" — все знают, что круто, но половина нихуя не помнит, в чём конкретно прикол. Сейчас разжую.

Короче, это не химия, а четыре правила, чтобы твоя база данных не превратилась в пиздопроебибну, когда ты пытаешься что-то важное сделать. Типа денег перевести или заказ оформить. Без этого — волнение ебать, доверия к системе ноль.

Разбираем по косточкам, что это за зверь:

Атомарность (Atomicity). Это про "всё или ничего". Представь, ты делаешь перевод. Со счёта списали, а на другой — нихуя не зачислили. Вот это пиздец. Атомарность говорит: либо оба действия проходят, либо оба откатываются нахуй, как будто ничего и не было. Внутри это работает через журналы и откаты (rollback), чтобы даже если свет вырубили — система охуела, но потом всё вернула как было.
Согласованность (Consistency). Это чтобы правила не нарушались. Ну, например, у тебя в базе написано, что зарплата не может быть меньше нуля. И какой-нибудь долбоёб-разработчик пытается записать -100. База ему такая: "Чувак, ты чё, охренел?" — и транзакцию отменяет. База всегда переходит из одного нормального состояния в другое нормальное. Никаких "зарплата минус сто" в итоге не появляется.
Изолированность (Isolation). А вот это, блядь, интересная тема. Представь, два процесса одновременно лезут в одни и те же данные. Один считает остаток на складе, а второй в этот же момент его меняет. Может получиться такая каша — "грязное чтение", когда ты видишь промежуточный, недоделанный результат другого процесса. Полная изоляция — это дорого, как яхта. Поэтому СУБД дают уровни изоляции, где можно чуть расслабиться ради скорости. Но хотя бы на уровне READ COMMITTED тебе уже не подсунут всякую хуйню, которую другая транзакция ещё не подтвердила.
Долговечность (Durability). Самый простой принцип. Раз уж транзакция сказала "COMMIT" и прошла успешно — всё, приехали. Эти изменения теперь высечены в камне, точнее, на диске. Даже если сервер накрылся медным тазом, после перезагрузки твои данные будут на месте. Потому что всё сперва честно пишется в журнал на постоянное хранилище, а уж потом отмечается как готовое.

Ну и примерчик, чтобы совсем понятно стало:

-- Начинаем наш опасный манёвр
BEGIN TRANSACTION;

-- 1. Пытаемся спиздить единицу товара со склада
UPDATE warehouse SET quantity = quantity - 1 WHERE product_id = 123;
-- 2. И сразу фиксируем заказ
INSERT INTO orders (user_id, product_id, status) VALUES (456, 123, 'reserved');

-- Если оба действия прошли без косяков — красота, фиксируем!
COMMIT;

-- А если на втором шаге вылезла ошибка (скажем, товара уже нет),
-- то кричим "отмена!" и откатываем ВСЁ, включая первый UPDATE.
-- ROLLBACK;

И главное напоследок: не все системы этим ACID'ом страдают. Особенно всякие модные распределённые NoSQL-базы. Там часто жертвуют строгой согласованностью или изоляцией, чтобы система не ложилась под нагрузкой. Это уже другой подход — BASE. Но это, как говорится, уже совсем другая история, и там тоже своих граблей овердохуища.