Изоляция данных

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

История и предпосылки

Понятие изоляции данных возникло в 1970-х годах с развитием реляционных баз данных и теории транзакций. Одним из первых формальных описаний стала работа Джима Грея «Granularity of Locks and Degrees of Consistency in a Shared Data Base» (1975), где были введены понятия степеней согласованности. В 1983 году Андреас Ройтер и Тео Хердер в статье «Principles of Transaction-Oriented Database Recovery» закрепили аббревиатуру ACID. Потребность в изоляции была продиктована необходимостью одновременной работы множества пользователей и приложений с общими данными без искажения их целостности.

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

Стандарт SQL (ISO/IEC 9075) определяет четыре уровня изоляции транзакций, различающихся по степени защиты от аномалий параллельного доступа. Каждый последующий уровень обеспечивает более строгую изоляцию, но потенциально снижает производительность за счёт увеличения блокировок.

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

Самый низкий уровень изоляции. Транзакция может читать данные, изменённые другими параллельными транзакциями, даже если эти изменения ещё не зафиксированы (commit). Это допускает «грязное» чтение (dirty read). На практике используется редко, в основном в системах, где допустима некоторая неточность данных (например, при мониторинге счётчиков).

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

Гарантирует, что транзакция читает только те данные, которые были зафиксированы на момент чтения. «Грязное» чтение исключено. Однако возможны неповторяющееся чтение (non-repeatable read) — когда повторное чтение той же строки в рамках одной транзакции даёт разные результаты из-за изменений, внесённых и зафиксированных другой транзакцией. Этот уровень является уровнем по умолчанию во многих СУБД, включая PostgreSQL и Microsoft SQL Server.

Repeatable Read (повторяемое чтение)

Гарантирует, что данные, прочитанные транзакцией, не могут быть изменены другими транзакциями до её завершения. Неповторяющееся чтение исключено. Однако остаётся возможность фантомного чтения (phantom read) — когда повторное выполнение запроса с тем же условием возвращает новые строки, добавленные другой транзакцией. В некоторых СУБД (например, MySQL с InnoDB) этот уровень дополнительно блокирует фантомы через механизм gap locks.

Serializable (сериализуемый)

Самый строгий уровень. Гарантирует полную изоляцию: все транзакции выполняются так, как если бы они были запущены последовательно, одна за другой. Исключены все аномалии (грязное, неповторяющееся, фантомное чтение, потерянное обновление). Реализуется либо через блокировки (блокировка диапазонов), либо через механизм многоверсионного контроля параллелизма (MVCC) с проверкой сериализуемости (как в PostgreSQL с уровнем Serializable). Снижает производительность при высокой конкуренции.

Механизмы реализации изоляции

Блокировки (Locking)

Традиционный способ обеспечения изоляции. Транзакции устанавливают блокировки на объекты данных (строки, страницы, таблицы). Различают разделяемые блокировки (Shared Lock, S) — для чтения, и исключительные блокировки (Exclusive Lock, X) — для записи. Блокировки могут быть двухфазными (2PL — Two-Phase Locking): фаза захвата блокировок и фаза освобождения (обычно при завершении транзакции). Двухфазный протокол гарантирует сериализуемость, но может приводить к взаимоблокировкам (deadlocks), которые СУБД разрешает автоматически, откатывая одну из транзакций.

Многоверсионный контроль параллелизма (MVCC)

Альтернативный подход, при котором каждая транзакция работает со снимком данных на определённый момент времени (версией). При изменении данных создаётся новая версия строки, а старая остаётся доступной для других транзакций, начавшихся раньше. MVCC позволяет избежать большинства блокировок при чтении, что повышает производительность в системах с высокой нагрузкой на чтение. Этот механизм используется в PostgreSQL, Oracle, MySQL (InnoDB), Microsoft SQL Server (snapshot isolation). Уровень изоляции при MVCC обычно соответствует Read Committed или Repeatable Read, а для Serializable требуется дополнительная проверка конфликтов.

Оптимистичный контроль параллелизма (Optimistic Concurrency Control, OCC)

Предполагает, что конфликты между транзакциями редки. Транзакция выполняется без блокировок, а перед фиксацией проверяется, не изменились ли данные, которые она читала или изменяла. Если обнаружен конфликт, транзакция откатывается и повторяется. OCC эффективен в средах с низкой конкуренцией, но при высокой — приводит к частым откатам.

Аномалии параллельного доступа

• Потерянное обновление (lost update) — две транзакции одновременно читают одно и то же значение, затем каждая записывает своё изменение; последняя запись перезаписывает результат первой, и первое изменение теряется.
• «Грязное» чтение (dirty read) — транзакция читает данные, изменённые другой незафиксированной транзакцией. Если та впоследствии откатывается, прочитанные данные оказываются некорректными.
• Неповторяющееся чтение (non-repeatable read) — в рамках одной транзакции повторное чтение одной и той же строки даёт разные результаты, поскольку другая транзакция изменила и зафиксировала эту строку.
• Фантомное чтение (phantom read) — в рамках одной транзакции повторное выполнение запроса с условием (например, WHERE id > 100) возвращает новый набор строк, добавленных другой транзакцией.

Изоляция в распределённых системах

В распределённых базах данных и системах на основе микросервисов (например, Apache Cassandra, Amazon DynamoDB) классическая ACID-изоляция часто недостижима из-за ограничений CAP-теоремы. Вместо этого применяются более слабые гарантии, такие как согласованность в конечном счёте (eventual consistency). Для критичных операций используются распределённые транзакции с протоколом двухфазной фиксации (2PC) или саги (sagas), которые обеспечивают изоляцию на уровне бизнес-логики, а не на уровне данных.

Изоляция и производительность

Выбор уровня изоляции — компромисс между целостностью данных и пропускной способностью системы. Высокие уровни (Serializable) требуют больше блокировок и увеличивают вероятность взаимоблокировок, что снижает производительность при параллельной работе. Низкие уровни (Read Uncommitted) минимизируют блокировки, но допускают аномалии. Администраторы баз данных и разработчики выбирают уровень исходя из требований приложения: для банковских операций предпочтителен Serializable или Repeatable Read, для аналитических отчётов — Read Committed.

Изоляция в законодательстве РФ

В контексте российского законодательства изоляция данных может рассматриваться как часть требований к защите информации. Федеральный закон № 152-ФЗ «О персональных данных» требует обеспечения конфиденциальности и целостности персональных данных при их обработке. СУБД, используемые в государственных информационных системах, должны соответствовать требованиям Федеральной службы по техническому и экспортному контролю (ФСТЭК России) по уровню защищённости, что включает механизмы изоляции транзакций для предотвращения несанкционированного доступа и искажения данных.

Источники

• ISO/IEC 9075-1:2023 «Information technology — Database languages — SQL — Part 1: Framework»
• Gray, J. «Granularity of Locks and Degrees of Consistency in a Shared Data Base» (1975)
• Reuter, A., Härder, T. «Principles of Transaction-Oriented Database Recovery» (1983)
• Bernstein, P. A., Hadzilacos, V., Goodman, N. «Concurrency Control and Recovery in Database Systems» (1987)
• Федеральный закон от 27.07.2006 № 152-ФЗ «О персональных данных»
• Требования ФСТЭК России к средствам защиты информации