Какие знаешь уровни изоляции?

Уровни изоляции транзакций в базах данных

Уровни изоляции — это ключевое понятие в теории транзакций в базах данных, определяющее, насколько одна транзакция изолирована от воздействия других параллельных транзакций. Они регулируют баланс между консистентностью данных и производительностью системы. Стандартные уровни изоляции определены в стандарте ANSI/ISO SQL и реализованы (с некоторыми вариациями) в большинстве реляционных СУБД, таких как PostgreSQL, MySQL, Oracle и SQL Server.

Основные проблемы, которые призваны решать уровни изоляции:

• Потерянное обновление (Lost Update): Два процесса читают одну запись, оба изменяют её и записывают, но второе обновление перезаписывает первое.
• Грязное чтение (Dirty Read): Транзакция читает данные, которые были изменены другой транзакцией, но ещё не зафиксированы.
• Неповторяемое чтение (Non-repeatable Read): Одна транзакция дважды читает одну и ту же запись, но между чтениями другая транзакция изменила и зафиксировала эту запись, и результаты двух чтений различаются.
• Фантомное чтение (Phantom Read): Похоже на неповторяемое чтение, но касается диапазона записей (например, строк, удовлетворяющих условию WHERE). При повторном выполнении одного и того же запроса появляются новые («фантомные») строки, добавленные другой зафиксированной транзакцией.

Стандартные уровни изоляции (по возрастанию строгости)

1. Read Uncommitted (Чтение незафиксированных данных)

Это самый низкий уровень изоляции. Транзакция может видеть данные, изменённые другими транзакциями, даже если они ещё не зафиксированы. Это позволяет избежать только потерянного обновления, но не защищает от грязного, неповторяемого и фантомного чтений.

• Использование: Крайне редко в production из-за рисков. Может применяться для агрессивной оптимизации чтения некритичных данных (например, аналитических отчётов).
• Пример (псевдокод):

  -- Сессия 1
  BEGIN TRANSACTION ISOLATION LEVEL READ UNCOMMITTED;
  UPDATE users SET balance = balance - 100 WHERE id = 1; -- Не фиксируется пока
  -- Сессия 2 (параллельно) видит незафиксированное значение balance, которое может быть откачено
  SELECT balance FROM users WHERE id = 1; -- Видит "грязные" данные
  

2. Read Committed (Чтение зафиксированных данных)

Это уровень по умолчанию в PostgreSQL и многих других СУБД. Транзакция видит только данные, которые были зафиксированы к моменту начала её каждой отдельной операции чтения. Решает проблемы потерянного обновления и грязного чтения, но не защищает от неповторяемого и фантомного чтений.

• Механизм: Часто реализуется через блокировки строк на запись или механизм версий данных (MVCC).
• Пример:

  -- Сессия 1
  BEGIN TRANSACTION ISOLATION LEVEL READ COMMITTED;
  SELECT * FROM accounts WHERE user_id = 5; -- Читает, например, 1000
  -- Сессия 2 фиксирует UPDATE accounts SET amount = 800 WHERE user_id = 5;
  -- Сессия 1 при повторном чтении УЖЕ увидит 800 (неповторяемое чтение)
  SELECT * FROM accounts WHERE user_id = 5;
  

3. Repeatable Read (Повторяемое чтение)

Гарантирует, что данные, прочитанные в течение транзакции, не изменятся другими транзакциями до её завершения. Решает проблемы потерянного обновления, грязного и неповторяемого чтения, но не защищает от фантомного чтения в классической трактовке ANSI (хотя в PostgreSQL, благодаря реализации через MVCC, защищает и от него).

• Механизм: В СУБД с блокировками (MySQL/InnoDB) удерживаются разделяемые блокировки (shared locks) на все прочитанные строки. В PostgreSQL MVCC создаёт снимок данных (snapshot) на момент начала транзакции.
• Пример для PostgreSQL:

  -- Сессия 1
  BEGIN TRANSACTION ISOLATION LEVEL REPEATABLE READ;
  SELECT SUM(amount) FROM accounts WHERE type = 'savings'; -- Возвращает 5000
  -- Сессия 2 ВСТАВЛЯЕТ новую запись с type='savings' и фиксируется
  INSERT INTO accounts (user_id, type, amount) VALUES (10, 'savings', 1000);
  COMMIT;
  -- Сессия 1 при повторном запросе УВИДИТ те же 5000 (фантом не появится в PostgreSQL)
  SELECT SUM(amount) FROM accounts WHERE type = 'savings'; -- Всё ещё 5000
  COMMIT;
  

4. Serializable (Сериализуемый)

Самый строгий уровень. Гарантирует, что результат параллельного выполнения транзакций будет идентичен их некоторому последовательному выполнению. Решает все четыре проблемы изоляции.

• Механизм: Реализации разнятся:

    *   **PostgreSQL (Оптимистичная сериализация через MVCC)**: Использует **технику распознавания сериализационных конфликтов (Serializable Snapshot Isolation - SSI)**. Транзакции работают параллельно, но система отслеживает зависимости "чтения-записи" между ними и прерывает одну из них в случае обнаружения цикла (возможного нарушения сериализуемости).
    *   **Другие СУБД (Пессимистичные блокировки)**: Могут использовать **блокировки диапазонов ключей (next-key locks)** или таблиц для предотвращения любых вставок в просмотренные диапазоны.

• Пример конфликта в PostgreSQL:

  -- Сессия 1
  BEGIN TRANSACTION ISOLATION LEVEL SERIALIZABLE;
  SELECT * FROM accounts WHERE user_id = 1;
  -- Сессия 2 параллельно делает
  BEGIN TRANSACTION ISOLATION LEVEL SERIALIZABLE;
  SELECT * FROM accounts WHERE user_id = 2;
  -- Если обе попробуют обновить одну и ту же запись, основанную на прочитанных данных,
  -- одна из транзакций получит ошибку сериализации:
  -- ERROR: could not serialize access due to read/write dependencies among transactions
  

Выбор уровня изоляции в DevOps-контексте

Как инженеру DevOps, мне критически важно понимать выбор уровня изоляции для проектов, так как он напрямую влияет на:

1. Производительность и масштабируемость: Более строгие уровни (Repeatable Read, Serializable) увеличивают contention (конфликт за ресурсы) и могут снижать throughput.
2. Целостность данных: Для финансовых или транзакционных систем часто необходим минимум Repeatable Read.
3. Архитектуру приложения: Уровень изоляции должен быть согласован с логикой приложения. Использование Serializable может требовать реализации логики повторных попыток (retry logic) для обработки ошибок сериализации.
4. Настройку СУБД: Например, в postgresql.conf можно задать уровень по умолчанию (default_transaction_isolation).

На практике, Read Committed является наиболее сбалансированным и часто используемым уровнем. Serializable следует выбирать осознанно для критически важных операций, где любая аномалия недопустима, будучи готовым к потенциальному падению производительности и необходимости доработки приложения. Понимание этих уровней помогает в проектировании отказоустойчивых, консистентных и производительных систем.