Какие плюсы и минусы уровня изоляции SERIALIZABLE?

Плюсы и минусы уровня изоляции SERIALIZABLE

Что такое уровень изоляции SERIALIZABLE?

SERIALIZABLE — это самый высокий уровень изоляции транзакций в SQL. При этом уровне все одновременно выполняемые транзакции ведут себя так, как если бы они выполнялись последовательно (серийно), без перекрытия друг друга. Это полностью исключает race conditions и phantom reads.

Иерархия уровней изоляции (от низшего к высшему)

1. READ UNCOMMITTED — может читать грязные данные
2. READ COMMITTED — читает только коммитные данные
3. REPEATABLE READ — последовательные чтения одних и тех же данных идентичны
4. SERIALIZABLE — полная изоляция, как если бы транзакции выполнялись последовательно

Плюсы SERIALIZABLE

1. Максимальная безопасность данных

• Полностью исключены race conditions
• Невозможны грязные чтения (dirty reads)
• Невозможны неповторяемые чтения (non-repeatable reads)
• Невозможны phantom reads
• Полная корректность данных

-- SERIALIZABLE гарантирует, что результат будет корректным
SET TRANSACTION ISOLATION LEVEL SERIALIZABLE;
BEGIN TRANSACTION;

SELECT SUM(balance) FROM accounts; -- 100000
-- Другая транзакция переводит деньги
SELECT SUM(balance) FROM accounts; -- 100000 (ДА, одно и то же значение!)

COMMIT;

2. Предсказуемость и простота логики

• Разработчику не нужно думать о race conditions
• Код становится проще и понятнее
• Меньше ошибок, связанных с конкурентностью
• Меньше нужно знать о внутреннем устройстве БД

// Код простой и понятный
@Transactional(isolation = Isolation.SERIALIZABLE)
public void transferMoney(Long fromAccount, Long toAccount, BigDecimal amount) {
    Account from = repository.findById(fromAccount); // блокирует строку
    Account to = repository.findById(toAccount);     // блокирует строку
    
    from.setBalance(from.getBalance().subtract(amount));
    to.setBalance(to.getBalance().add(amount));
    
    repository.save(from);
    repository.save(to);
    // Никакая другая транзакция не может вмешаться
}

3. Исключает сложные race conditions

• Lost updates невозможны
• Double charging невозможен
• Overselling невозможен
• Все edge cases решены

-- Пример: перевод денег
Transaction 1: SELECT balance FROM account WHERE id = 1; -- 100
Transaction 2: SELECT balance FROM account WHERE id = 1; -- 100
Transaction 1: UPDATE account SET balance = 50 WHERE id = 1; -- Transfer
Transaction 2: UPDATE account SET balance = 50 WHERE id = 1; -- Transfer (ERROR!)
-- С SERIALIZABLE это невозможно

4. Хороша для критичных операций

• Платежи и финансовые транзакции
• Инвентарь и управление складом
• Бронирование билетов
• Любые операции, где нужна максимальная корректность

Минусы SERIALIZABLE

1. Серьёзное снижение производительности

• Транзакции блокируют друг друга
• При высокой конкурентности много deadlocks и timeouts
• Пропускная способность (throughput) сильно снижается
• Может быть замедление в 10x и более

// Без SERIALIZABLE: 10000 операций в секунду
// С SERIALIZABLE: 1000 операций в секунду
// Потому что транзакции ждут друг друга

2. Много deadlocks

• Транзакции часто вступают в deadlock
• Требуется логика retry для обработки deadlocks
• Непредсказуемые задержки
• Усложнение кода для обработки исключений

// Нужна обработка deadlocks
@Transactional(isolation = Isolation.SERIALIZABLE)
public void transferMoney(...) {
    try {
        // операция
    } catch (DeadlockLoserDataAccessException e) {
        // retry с backoff
        Thread.sleep(random(1, 100));
        transferMoney(...); // recursion или loop
    }
}

3. Плохо масштабируется

• Чем больше одновременных пользователей, тем хуже
• При 1000+ одновременных транзакций может быть критично
• Невозможно использовать для high-traffic приложений
• Требует дорогого hardware

// Сценарий: e-commerce с SERIALIZABLE
// Black Friday: 10000 одновременных пользователей
// Каждая покупка блокирует инвентарь
// Результат: множество timeouts и ошибок
// Better: использовать READ COMMITTED + explicit locks

4. Timeout и ошибки

• Пользователь получает ошибку "Transaction timeout"
• Нужна логика retry на клиенте
• Плохой UX: "Ошибка, повторите попытку"
• Сложнее диагностировать проблемы

5. Может быть избыточно для многих случаев

• Для чтения данных SERIALIZABLE полностью излишний
• Для некритичных операций может быть оverkill
• Можно использовать более низкий уровень с явными блокировками

// SERIALIZABLE для чтения — излишне
@Transactional(isolation = Isolation.SERIALIZABLE, readOnly = true)
public Account getAccount(Long id) {
    return repository.findById(id);
}

// Достаточно READ COMMITTED
@Transactional(isolation = Isolation.READ_COMMITTED, readOnly = true)
public Account getAccount(Long id) {
    return repository.findById(id);
}

6. Сложность с распределённым системами

• SERIALIZABLE требует координации между узлами
• Увеличивает latency
• Требует консенсуса (Raft, Paxos)
• Очень дорого в распределённых системах

Проблема: все уровни изоляции

-- READ UNCOMMITTED
Transaction 1: INSERT INTO logs SELECT * FROM accounts; -- Грязное чтение
Transaction 2: DELETE FROM accounts; -- Что прочитала T1 теперь не существует

-- READ COMMITTED
Transaction 1: SELECT * FROM products WHERE price > 100; -- 5 продуктов
Transaction 2: INSERT INTO products VALUES (...); -- price = 150
Transaction 1: SELECT * FROM products WHERE price > 100; -- 6 продуктов (Phantom read!)

-- REPEATABLE READ
Transaction 1: SELECT * FROM inventory WHERE id = 1; -- 100 units
Transaction 2: UPDATE inventory SET quantity = 50 WHERE id = 1;
Transaction 1: SELECT * FROM inventory WHERE id = 1; -- 100 units (consistent)

-- SERIALIZABLE
-- Все вышеперечисленные проблемы исключены

Когда использовать SERIALIZABLE?

Используй SERIALIZABLE если:

• Критичные финансовые операции
• Перевод денег между счётами
• Бронирование редких ресурсов
• Системы управления инвентарём
• Очень небольшое количество одновременных транзакций
• Производительность не критична

НЕ используй SERIALIZABLE если:

• High-traffic приложение
• Много одновременных пользователей
• Требуется высокая пропускная способность
• Некритичные операции
• Чтение данных

Рекомендации

// Правильный подход: гибридный

// Критичная операция: платёж
@Transactional(isolation = Isolation.SERIALIZABLE)
public void processPayment(Payment payment) {
    Account from = repository.findForUpdate(payment.getFromId());
    Account to = repository.findForUpdate(payment.getToId());
    // ...
}

// Некритичная операция: чтение
@Transactional(isolation = Isolation.READ_COMMITTED, readOnly = true)
public Account getAccount(Long id) {
    return repository.findById(id);
}

// Критичная, но частая: инвентарь
@Transactional(isolation = Isolation.READ_COMMITTED)
public void updateInventory(Long productId, int quantity) {
    Product product = repository.findForUpdate(productId); // явная блокировка
    product.setQuantity(product.getQuantity() - quantity);
    if (product.getQuantity() < 0) {
        throw new OutOfStockException();
    }
}

Вывод

SERIALIZABLE — это мощный инструмент для обеспечения корректности данных, но его цена высока. Правильный подход — использовать различные уровни изоляции для разных операций, в зависимости от их критичности и частоты. Для критичных операций можно использовать явные блокировки (SELECT FOR UPDATE) вместо SERIALIZABLE для лучшего баланса между безопасностью и производительностью.