Архитектура

Изоляция и многоверсионность

12

Авторские права

© Postgres Professional, 2017–2021

Авторы: Егор Рогов, Павел Лузанов

Обратная связь

Отзывы, замечания и предложения направляйте по адресу:

Отказ от ответственности

Компания Postgres Professional не несет никакой ответственности за

любые повреждения и убытки, включая потерю дохода, нанесенные

прямым или непрямым, специальным или случайным использованием

материалов курса. Компания Postgres Professional не предоставляет

каких-либо гарантий на материалы курса. Материалы курса

предоставляются на основе принципа «как есть» и компания Postgres

пишущие — тоже (в этом случае они выстраиваются в очередь и

выполняют изменения друг за другом). Самый интересный вариант —

как взаимодействуют пишущая и читающая транзакции.

Простых пути два. Такие транзакции могут блокировать друг друга —

но тогда страдает производительность. Либо же читающая транзакция

сразу видит изменения, сделанные пишущей транзакцией, даже если

они не зафиксированы (это называется «грязным чтением») — но это

очень плохо, ведь изменения могут быть отменены.

PostgreSQL идет сложным путем и использует многоверсионность —

хранит несколько версий одной и той же строки. При этом пишущая

Когда строка создается, она помечается номером транзакции,

выполнившей команду INSERT. Когда удаляется — версия помечается

номером транзакции, выполнившей DELETE (но физически не

удаляется). UPDATE состоит из двух операций DELETE и INSERT.

снимок

Транзакция, обращаясь к таблице, должна видеть только одну из

видны. Иными словами, от каждой строки в снимок попадает версия,

соответствующая моменту создания снимка.

снимка (он определяет тот самый момент времени);

- список активных транзакций на этот момент.

Список нужен для того, чтобы исключить из снимка изменения тех

транзакций, которые начались до создания снимка, но еще не были

зафиксированы.

Зная эти числа, мы всегда можем сказать, какая из версий строки будет

видна в снимке. Иногда это будет актуальная (самая последняя)

версия, как для строки 1 на иллюстрации. Иногда не самая последняя:

строка 2 удалена (и изменение уже зафиксировано), но транзакция

еще продолжает видеть эту строку, пока работает со своим снимком.

считалось, что чем строже уровень, тем сложнее его реализовать и тем

сильнее его влияние на производительность (с тех пор эти

представления несколько изменились).

Самый нестрогий уровень Read Uncommitted допускает грязные

чтения и не поддерживается PostgreSQL — он не представляет

практической ценности и не дает выигрыша в производительности.

Уровень Read Committed является уровнем изоляции по умолчанию

в PostgreSQL. На этом уровне снимки данных строятся в начале

выполнения каждого оператора SQL. Таким образом, оператор

работает с неизменной и согласованной картиной данных, но два

разные данные.

транзакция будет ждать освобождения блокировки — если она

пытается менять строку, которая уже изменена другой, еще не

зафиксированной, транзакцией.

Блокировки также устанавливаются на более высоком уровне,

в частности на таблицах. Они нужны для того, чтобы никто не смог

удалить таблицу, пока другие транзакции читают из нее данные, или

чтобы запретить доступ к перестраиваемой таблице. Как правило,

перестроение таблиц — очень редкие операции.

образом, для представления состояния каждой транзакции требуются

два бита. Статусы хранятся в специальных служебных файлах,

а работа с ними происходит в общей памяти сервера, чтобы не

При любом завершении транзакции (как успешном, так и неуспешном)

необходимо всего лишь установить соответствующие биты статуса. Как

фиксация, так и обрыв транзакций происходят одинаково быстро.

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

версии не уничтожаются (не происходит «физического» отката данных).

Благодаря информации о статусах другие транзакции увидят, что

прервана, и не станут принимать ее изменения во внимание.