Можно ли получить согласованность данных без использования изоляции в БД?

# Можно ли получить согласованность данных без использования изоляции в БД?

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

Теория ACID и роль изоляции

Изоляция — это один из четырех столпов ACID (Atomicity, Consistency, Isolation, Durability). Она определяет, как одновременные транзакции взаимодействуют между собой. Полное отсутствие изоляции приводит к таким проблемам, как:

• Грязное чтение (Dirty Read) — чтение незафиксированных данных другой транзакции
• Неповторяемое чтение (Non-repeatable Read) — одна строка изменилась в ходе одной транзакции
• Фантомное чтение (Phantom Read) — набор строк, удовлетворяющих условию, изменился

Однако согласованность (Consistency) — это не то же самое, что изоляция (Isolation). Согласованность означает, что данные остаются в корректном состоянии, а изоляция — это способ её достижения.

Альтернативные подходы к согласованности

1. Оптимистичная блокировка (Optimistic Locking)

Вместо блокировок на уровне БД используется версионирование:

from sqlalchemy import Column, Integer, String, DateTime
from datetime import datetime

class User(Base):
    __tablename__ = 'users'
    id = Column(Integer, primary_key=True)
    name = Column(String)
    email = Column(String)
    version = Column(Integer, default=1)
    updated_at = Column(DateTime, default=datetime.utcnow)

# При обновлении проверяем версию
def update_user(session, user_id, new_name, expected_version):
    user = session.query(User).filter(User.id == user_id).first()
    if user.version != expected_version:
        raise ValueError("Данные изменились, операция отменена")
    user.name = new_name
    user.version += 1
    session.commit()

Преимущества: минимальные блокировки, высокая пропускная способность Недостатки: требует обработки конфликтов на уровне приложения

2. Пессимистичная блокировка (Pessimistic Locking)

Блокируем данные сразу при чтении:

from sqlalchemy import select
from sqlalchemy.orm import Session

def update_user_pessimistic(session: Session, user_id: int, new_name: str):
    # SELECT FOR UPDATE — блокируем строку до конца транзакции
    user = session.execute(
        select(User).where(User.id == user_id).with_for_update()
    ).scalar_one()
    user.name = new_name
    session.commit()

Преимущества: гарантирует отсутствие конфликтов Недостатки: снижает параллелизм, риск deadlock'ов

3. Event Sourcing и CQRS

Вместо хранения текущего состояния сохраняются все события (immutable log):

from dataclasses import dataclass
from datetime import datetime
from enum import Enum

class UserEventType(Enum):
    CREATED = "user_created"
    EMAIL_CHANGED = "email_changed"
    NAME_CHANGED = "name_changed"

@dataclass
class UserEvent:
    event_type: UserEventType
    user_id: int
    data: dict
    timestamp: datetime
    version: int  # для обнаружения конфликтов

class EventStore:
    def append_event(self, event: UserEvent):
        # Только добавление — никогда не изменение
        sql = """
        INSERT INTO user_events (user_id, event_type, data, version)
        VALUES (:user_id, :event_type, :data, :version)
        """
        self.db.execute(sql, event.__dict__)
    
    def rebuild_user_state(self, user_id: int) -> dict:
        events = self.db.query(UserEvent).filter(
            UserEvent.user_id == user_id
        ).order_by(UserEvent.timestamp).all()
        
        state = {'id': user_id, 'name': None, 'email': None}
        for event in events:
            if event.event_type == UserEventType.NAME_CHANGED:
                state['name'] = event.data['name']
            elif event.event_type == UserEventType.EMAIL_CHANGED:
                state['email'] = event.data['email']
        return state

Преимущества: полная история изменений, аудит встроен, хорошо для распределенных систем Недостатки: сложнее в реализации, требует проекций для чтения

4. Распределенные транзакции и Saga pattern

Для микросервисной архитектуры:

from enum import Enum

class TransactionStatus(Enum):
    PENDING = "pending"
    COMMITTED = "committed"
    ROLLED_BACK = "rolled_back"

class Saga:
    def __init__(self, saga_id: str):
        self.saga_id = saga_id
        self.steps = []
    
    async def execute(self):
        for step in self.steps:
            try:
                await step.execute()
                await self.log_step_success(step)
            except Exception as e:
                # Rollback в обратном порядке
                for completed_step in reversed(self.steps[:self.steps.index(step)]):
                    await completed_step.compensate()
                raise

Преимущества: согласованность в распределенных системах Недостатки: требует компенсирующих транзакций

5. Последовательная обработка (Serialization)

Обрабатываем все изменения одного агрегата последовательно через очередь:

from queue import Queue
from threading import Thread

class AggregateProcessor:
    def __init__(self):
        self.queues = {}  # user_id -> Queue
    
    def enqueue_change(self, user_id: int, change):
        if user_id not in self.queues:
            self.queues[user_id] = Queue()
            worker = Thread(target=self._process_queue, args=(user_id,))
            worker.daemon = True
            worker.start()
        self.queues[user_id].put(change)
    
    def _process_queue(self, user_id: int):
        queue = self.queues[user_id]
        while True:
            change = queue.get()
            # Обновляем данные пользователя
            self.apply_change(user_id, change)
            queue.task_done()

Преимущества: гарантирует порядок операций для одного агрегата Недостатки: масштабируемость ограничена числом потоков/процессов

Практический ответ

Да, можно получить согласованность без использования встроенной изоляции БД, но:

1. Нужно выбрать альтернативный механизм — в зависимости от требований (оптимистичная блокировка, Event Sourcing, Saga и т.д.)
2. Это требует большей сложности на уровне приложения и тестирования
3. Производительность может быть ниже из-за конфликтов или компенсирующих операций
4. Изоляция БД остается более простым и надежным подходом для большинства сценариев

В реальных приложениях часто комбинируют несколько подходов: используют нужный уровень изоляции БД где возможно, добавляют оптимистичную блокировку для некритичных данных, Event Sourcing для аудита, и Saga для межсервисных операций.