Mvcc Как Один Из Способов Обеспечения Изоляции Транзакций

Сегодня мы более подробно обсудим один из способов обеспечить эту самую изоляцию и избежать рассмотренных аномалий.

Как вы могли заметить, в прошлой статье часто выделялись два подхода: один основывался на том факте, что записи имеют некоторые версии , а второе - мы так или иначе будем записывать блокировать .

Таким образом, выделяют два класса баз данных: Версионеры и блокировщики .

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

Его также называют оптимистичный подход или MVCC (управление многоверсионным параллелизмом) .

Фактически сохраняются версии для активных транзакций.

Я приведу примеры некоторых из них.

Идентификаторы транзакций монотонно растут. Любая строка имеет 2 атрибута, которые представляют метаинформацию для обеспечения механизма: update_by_id — идентификатор транзакции, которая последней обновила эту запись, и delete_by_id — идентификатор транзакции, которая удалила эту запись.

Когда поступает новая транзакция, база данных определяет идентификаторы выполняющихся в данный момент транзакций; изменения, внесенные этими транзакциями, будут игнорироваться во входящей транзакции.

Получается, что входящая транзакция работает как бы со своей версией данных.

Старые версии данных хранятся там же, где и текущие.

Если приходит Update, то добавляется еще одна строка и эта запись становится активной.

Также понятно, что для корректной работы этой схемы необходим «сборщик мусора»: если какая-то запись имеет delete_by_id = 100, а минимальный id среди выполняющихся в данный момент транзакций равен 150, то такую запись необходимо удалить.

При поступлении Update данные внутри файла с таблицей исправляются.

После исправления данных в журнале отката сохраняется предыдущая версия.

MySQL имеет несколько журналов отката (они разные для вставок и обновлений).

Если для транзакции требуется предыдущая версия строки, система переходит к журналу отмены и восстанавливает необходимую версию.

Версия также определяется идентификатором транзакции.

Журнал отмены в Oracle циклически перезаписывается.

Поэтому возможна ситуация, когда для транзакции нужна очень старая версия записи, но ее уже нет в журнале отмены.

Если такая ситуация произойдет, транзакция завершится с ошибкой.

Для включения версионного режима в настройках базы данных необходимо включить работу со снапшотами.

В MS SQL есть системная таблица (tempdb), которая предназначена для хранения временных таблиц.

Для хранения старых версий используется база данных tempdb, а в таблице — текущие версии.

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

Если транзакция длительная, то для нее будут сохранены версии.

Tempdb растет, достигает максимального размера, MS SQL выделяет некоторое дисковое пространство.

Если оно также заканчивается, то транзакции с изоляцией моментального снимка не могут быть выполнены.

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

Например, в PostgreSQL транзакция помечается как откатанная, и очистка освобождает дисковое пространство.

Этот механизм работает довольно быстро.

В Oracle для выполнения отката данные восстанавливаются из журнала отмены.

В этом случае время работы увеличивается, но все равно гораздо быстрее, чем в блокировщиках.

Поэтому версионирование выгодно, если основная нагрузка приходится на чтение, а не на написание (блог, отчетность и другие случаи, когда нужно много и часто читать).