Как устроены под капотом ограничения уровней изоляции транзакций?

Как реализуются уровни изоляции транзакций в современных системах

В основе реализации уровней изоляции лежат несколько ключевых механизмов: версионирование данных, блокировки (lock) и многовариантная временная логика (MVCC). Конкретный механизм зависит от используемой базы данных и уровня изоляции.

Основные механизмы реализации

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

Это классический подход, используемый, например, в SQL Server при уровнях READ COMMITTED и REPEATABLE READ. Система создает блокировки на данные для контроля доступа.

• Shared locks (S-locks) для операций чтения.
• Exclusive locks (X-locks) для операций модификации.

-- При уровне READ COMMITTED в SQL Server
BEGIN TRANSACTION;
SELECT * FROM users WHERE id = 1; -- На строку устанавливается shared lock, который сразу отпускается после чтения
UPDATE users SET name = 'John' WHERE id = 1; -- Требуется exclusive lock, который блокирует другие транзакции
COMMIT;

Проблема блокировок: они могут приводить к взаимным блокировкам (deadlocks) и снижать параллельность операций.

2. Многовариантная временная логика (MVCC)

Это более современный подход, используемый в PostgreSQL, MySQL (InnoDB), Oracle. При каждом изменении данных создается новая версия строки, а старая сохраняется. Каждая транзакция работает со "снимком" данных (snapshot), соответствующим моменту ее начала.

-- В PostgreSQL при уровне READ COMMITTED
BEGIN TRANSACTION;
-- Транзакция видит только данные, которые были коммитированы до ее начала
SELECT * FROM accounts WHERE user_id = 1;
-- Если в параллельной транзакции данные изменятся, этот SELECT не увидит изменения
COMMIT;

Хранение версий: системы используют дополнительные структуры (например, в PostgreSQL это xmin и xmax в heap tuples) или отдельные области хранения (rollback segments в Oracle).

Реализация конкретных уровней изоляции

READ UNCOMMITTED

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

READ COMMITTED

• На блокировках: система устанавливает shared lock на читаемую строку, но отпускает его сразу после чтения. Поэтому между двумя SELECT в одной транзакции могут появиться данные от коммитированной параллельной транзакции.
• На MVCC: транзакция видит только последнюю коммитированную версию данных на момент выполнения каждого конкретного оператора.

REPEATABLE READ / SNAPSHOT ISOLATION

• На блокировках: shared locks удерживаются до конца транзакции, предотвращая изменение данных другими транзакциями.
• На MVCC: транзакция работает со снимком данных на момент своего начала. Все операторы видят одинаковое состояние данных.

-- REPEATABLE READ в MySQL (InnoDB с MVCC)
START TRANSACTION;
SELECT balance FROM accounts WHERE id = 1; -- Видит snapshot
-- Даже если другая транзакция обновила баланс и коммитилась
SELECT balance FROM accounts WHERE id = 1; -- Увидит то же значение
COMMIT;

SERIALIZABLE

Самая строгая изоляция, гарантирующая полную последовательность выполнения транзакций.

• На блокировках: используются блокировки диапазонов (range locks) для предотвращения фантомного чтения.
• На MVCC: часто реализуется через предикатные блокировки или агрессивную проверку конфликтов при коммите (например, в PostgreSQL).

Внутренние структуры и накладные расходы

Каждый механизм имеет свои издержки:

• Блокировки требуют управления lock manager, могут приводить к ожиданиям и deadlocks.
• MVCC требует хранения нескольких версий данных, что увеличивает нагрузку на хранилище и требует периодической очистки (vacuum в PostgreSQL).

// Пример логики проверки версий в MVCC (концептуальный код)
type Row struct {
    ID        int
    Data      string
    CreatedTx int // Идентификатор транзакции, создавшей версию
    DeletedTx int // Идентификатор транзакции, удалившей версию
}

func GetRowForTransaction(txID int, currentRows []Row) *Row {
    for _, row := range currentRows {
        // Видимость версии для транзакции txID
        if row.CreatedTx <= txID && (row.DeletedTx == 0 || row.DeletedTx > txID) {
            return &row
        }
    }
    return nil
}

Заключение

Таким образом, уровни изоляции транзакций реализуются через сложные внутренние механизмы, которые балансируют между гарантиями корректности данных и производительностью системы. Выбор реализации зависит от архитектуры базы данных: традиционные системы тяготеют к блокировкам, а современные — к MVCC, что позволяет повысить параллельность операций чтения.