🛡 Изолированность транзакций в БД: MVCC, блокировки

Изолированность транзакций в БД гарантирует, что параллельные транзакции не влияют друг на друга. Предотвращает видимость промежуточных результатов транзакции для других до её завершения, сохраняя целостность данных
Это одно из свойств ACID

Как обеспечить изолированность

🟣 MVCC (multiversion concurrency control) — создание отдельной версии данных для каждой транзакции
🟠 Блокировка — ограничение доступа к данным


MVCC

Принцип работы

Во время транзакции создается копия данных, в которой происходят изменения
➖Если транзакция завершилась успешно, копия становится основным источником, старая версия — удаляется
➖Если во время транзакции произошла ошибка, старая версия остается основной, а копия удаляется

Пример

Два пользователя одновременно меняют карточку товара
⚪️ Они открывают карточку товара, создается две копии записи о товаре
⚪️ Одновременно меняют поля товара. Обе копии могут стать основной записью
⚪️ Перед сохранением БД пытается слить две записи в одну
▫️ Если конфликтов нет (менялись разные поля), транзакции завершаются успешно
▫️ Если появились конфликты, обе транзакции откатываются


Блокировки

Примеры видов блокировок

*️⃣ Централизованная
*️⃣ Распределенная
*️⃣ Независимая


😀 Централизованная
Приложение-координатор дает доступ к БД или отклоняет запрос, если БД занята.

Алгоритмы выбора координатора

⏩ Забияка
🟡 рассылается сообщение о выборе координатора
🟡 отвечают все неупавшие приложения
🟡 инициатор выбирает приложение с наибольшим ID

⏩ Выбор в кольце
🟡процессы образуют кольцо, передавая сообщение о выборе координатора, пропуская неотвечающие узлы
🟡по завершению инициатору приходит список "живых" приложений
🟡инициатор выбирает приложение с наибольшим ID

📍Проблемы: координатор становится бутылочным горлышком системы, может ограничивать производительность


😀 Распределенная
Каждый процесс отправляет запросы на доступ к ресурсу всем другим (и себе)

Действия получателя:
🟠ОК: если другое приложение не имеет доступа и не запрашивает его
🟠В очередь: если получатель уже использует ресурс
🟠Сравнение времени: если получатель планирует использовать ресурс, он
сравнивает время запроса со времени своего запроса
— ОК: если у входящего сообщения время меньше
— В очередь: если время больше
После отправки запросов приложение останавливается, ждет подтверждения от остальных.
Далее отправляет OK всем в своей очереди и чистит ее

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

😀  Независимая
Минимизация блокировок за счет работы с копиями данных.

*️⃣Каждая транзакция работает изолированно со своей копией данных
*️⃣Перед фиксацией изменений, проводится проверка на наличие конфликтов.
  — если не обнаружено, изменения транзакции применяются к основной БД
  — если обнаружено (например, другой транзакцией изменены те же данные), текущая транзакция откатывается и, возможно, повторяется

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


Пример блокировки в БД

Две транзакции (T1 и T2) работают с таблицей accounts (информация о балансах пользователей)

🟡T1: Начинает транзакцию, читает баланс аккаунта
🟡T1: Запрашивает блокировку на аккаунт для обновления баланса
🟡T2: Начинает транзакцию и пытается прочитать баланс аккаунта
⏩ Блокировка: т.к.T1 удерживает блокировку, T2 ждет, пока T1 завершит свою транзакцию
🟡T1: обновляет баланс и фиксирует транзакцию, освобождая блокировку
🟡T2: читает обновленный баланс


Что выбрать для обеспечения изолированности?

🟣 MVCC
    ▫️если важен параллельный доступ
    ▫️скорость обработки транзакции
    ▫️когда важно, чтобы чтения не блокировали записи
🟠Блокировки
    🟡если нельзя допустить любую рассогласованность данных
    🟡важна строгая последовательность данных
    🟡недостаточно памяти для хранения копий


#бд