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

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

A (Atomicity) — Атомарность. Это значит, что операция — как ебля. Либо всё, либо нихуя. Либо ты довёл дело до конца и кончил, либо тебя вырвало на полпути и всё отменилось. В базе данных так же: либо все изменения внутри транзакции применяются, либо, если что-то пошло не так, откатываются к ебеням, как будто ничего и не было. Никаких промежуточных состояний, когда деньги уже списали, но никуда не зачислили. Или ты купил пиво, или нет. Полбутылки в мире транзакций не существует.

C (Consistency) — Согласованность. Это когда наш бухгалтер, даже будучи в говно пьяным, не нарушает внутренние правила ларька. Нельзя списать с твоего счёта больше денег, чем на нём есть. Нельзя принять в зачёт пустые бутылки от "Балтики", если у тебя в чеке только "Жигулёвское". База данных после каждой транзакции должна оставаться в адекватном, валидном состоянии. Если правило нарушается — вся операция летит в пизду. Это не обсуждается.

I (Isolation) — Изолированность. А вот это, блядь, самое интересное. Представь, что к нашему бухгалтеру одновременно подходят два клиента. Один хочет проверить баланс, а второй — как раз перевести деньги. Уровни изоляции — это как сильно бухгалтер забил хуй на окружающих. На самом низком уровне (Read Uncommitted) он может дать первому клиенту посмотреть черновик, где цифры ещё даже не верные, грязные. На нормальном уровне (Read Committed) — он покажет только зафиксированные, чистые данные. А на самом строгом (Serializable) он будет обслуживать клиентов по очереди, как в совковой очереди за колбасой, чтобы их операции вообще никак не пересекались. Выбираешь между скоростью и полной, блядь, предсказуемостью.

D (Durability) — Долговечность. Это железное правило: если уж бухгалтер сказал "окей, операция прошла" и поставил печать (COMMIT), то это навсегда. Он не имеет права через пять минут сказать: "Ой, ёпта, я забыл записать" или "Меня током ударило, и я всё стёр". Информация должна быть сброшена на диск так надёжно, что даже если на сервер упадёт метеорит, после восстановления из бэкапа данные будут целы. По-другому никак, иначе доверия ебать ноль.

Ну а теперь, сука, смотри, как это выглядит в коде на Node.js с PostgreSQL:

import { Client } from 'pg';
const client = new Client();
await client.connect();

try {
  // Начинаем эту вакханалию
  await client.query('BEGIN');

  // Две операции: с одного счёта списать, на другой зачислить
  await client.query(
    'UPDATE accounts SET balance = balance - $1 WHERE id = $2',
    [100, 1]
  );
  await client.query(
    'UPDATE accounts SET balance = balance + $1 WHERE id = $2',
    [100, 2]
  );

  // Всё прошло гладко? Фиксируем на века!
  await client.query('COMMIT');
  console.log('Транзакция успешно завершена');
} catch (err) {
  // Что-то пошло не так? Откатываем ВСЁ к чёртовой матери!
  await client.query('ROLLBACK');
  console.error('Транзакция откачена:', err);
} finally {
  await client.end();
}

Вот в этом примере ACID работает как часовой механизм, только вместо шестерёнок — принципы.

• Атомарность: BEGIN/COMMIT/ROLLBACK гарантируют, что либо оба апдейта сработают, либо оба отвалятся. Деньги не испарятся в никуда.
• Согласованность: Если на счёте id=1 меньше 100 денег, то первый же UPDATE ебнет ошибку нарушения ограничения (constraint), и ROLLBACK всё отменит. База не позволит уйти в минус.
• Изолированность: Пока эта транзакция не завершилась, другие соединения не увидят этих промежуточных изменений (зависит от уровня изоляции, но по умолчанию в Postgres так). Никто не увидит состояние, когда деньги уже списались, но ещё не зачислились.
• Долговечность: После COMMIT можешь вырубать свет — когда база поднимется, перевод будет учтён. Всё, пиши пропало.

Вот и вся магия, ёпта. Не транзакция, а песня.