В этом уроке разбираем механизм, на котором держится весь конкурентный доступ в postgresql - многоверсионность, или MVCC (Multi-Version Concurrency Control). Главная задача, которую он решает: дать многим транзакциям одновременно читать и писать одни и те же данные так, чтобы читающий никого не ждал, а пишущий никого не блокировал на чтении. Мы посмотрим, что такое версии строк, откуда берутся служебные поля xmin и xmax, как снимок данных (snapshot) определяет, какую версию строка покажет именно вашей транзакции, что такое HOT-обновления и почему обычные DELETE и UPDATE оставляют после себя мёртвые версии, которые потом приходится убирать через vacuum.
Как это работает
Ключевая идея простая: строку в таблице нельзя менять на месте. Вместо этого каждое изменение порождает новую версию строки (по-русски часто говорят "кортеж", в исходниках tuple), а старая версия физически остаётся лежать в той же таблице. То есть в один момент времени на диске может существовать несколько версий одной и той же логической строки, и задача системы - показать каждой транзакции ровно ту версию, которую она имеет право видеть.
Чтобы это работало, у каждой версии есть два служебных поля. xmin - номер транзакции, которая эту версию создала (вставила или родила при обновлении). xmax - номер транзакции, которая эту версию пометила удалённой или устаревшей; пока версия живая, xmax равен нулю. Номера транзакций (их называют xid) выдаются по возрастанию, поэтому по xmin и xmax всегда можно понять относительный порядок событий.
Видимость строится на снимке (snapshot). Когда транзакция начинает читать, postgresql фиксирует снимок: какие транзакции на этот момент уже завершились успешно (зафиксированы), какие ещё в работе. Дальше для каждой версии действует грубо такое правило: версия видна, если её xmin принадлежит уже зафиксированной транзакции, а xmax либо ноль, либо принадлежит транзакции, которая ещё не зафиксирована. Иначе говоря, вы видите строку, если её "создатель" уже закоммитился, а "удалятель" - ещё нет или его нет вовсе.
Отсюда и главное свойство: читающая транзакция не блокирует пишущую и наоборот. Писатель создаёт новую версию и трогает только конкурентных писателей той же строки; читатели спокойно смотрят на старую версию по своему снимку. Именно так достигается уровень изоляции Read Committed по умолчанию - каждый новый оператор внутри транзакции берёт свежий снимок.
UPDATE технически - это не правка на месте, а удаление старой версии (проставляется xmax) плюс вставка новой. DELETE - это просто проставление xmax без новой версии. Поэтому и то, и другое плодит мёртвые версии: данные логически исчезли или поменялись, но физически старый кортеж лежит в файле, пока его не соберёт vacuum.
HOT-обновление (Heap-Only Tuple) - оптимизация для частого случая. Если UPDATE не меняет ни одного индексированного столбца и новая версия влезает на ту же страницу, postgresql связывает старую и новую версии цепочкой прямо внутри страницы и не трогает индексы. Это резко снижает раздувание индексов и нагрузку. Но стоит изменить индексированный столбец или не остаться на странице - и HOT не сработает, придётся писать во все индексы.
SQL и примеры
Посмотрим на служебные поля прямо в демобазе "Авиаперевозки" (схема bookings). Псевдостолбцы ctid, xmin, xmax есть у любой таблицы.
Код: Выделить всё
SELECT ctid, xmin, xmax, book_ref, total_amount
FROM bookings
LIMIT 5;
Код: Выделить всё
CREATE TABLE demo_mvcc (id int PRIMARY KEY, note text);
INSERT INTO demo_mvcc VALUES (1, 'first');
SELECT ctid, xmin, xmax, * FROM demo_mvcc;
Код: Выделить всё
UPDATE demo_mvcc SET note = 'second' WHERE id = 1;
SELECT ctid, xmin, xmax, * FROM demo_mvcc;
Код: Выделить всё
CREATE EXTENSION IF NOT EXISTS pageinspect;
SELECT lp, t_xmin, t_xmax, t_ctid
FROM heap_page_items(get_raw_page('demo_mvcc', 0));
Код: Выделить всё
CREATE EXTENSION IF NOT EXISTS pgstattuple;
SELECT dead_tuple_count, dead_tuple_percent
FROM pgstattuple('bookings.flights');
Код: Выделить всё
SELECT pg_current_xact_id(); -- xid текущей транзакции (PG 13+)
SELECT pg_snapshot_xmin(pg_current_snapshot()); -- нижняя граница снимка
- Думать, что UPDATE дешевле INSERT. Под капотом UPDATE - это delete + insert; частые мелкие апдейты раздувают таблицу не меньше вставок.
- Отключать или душить автовакуум на нагруженной таблице. Без vacuum мёртвые версии копятся, таблица и индексы пухнут (bloat), запросы замедляются.
- Считать, что xmax больше нуля означает "строка удалена". xmax может стоять и от незавершённой транзакции, и от блокировки SELECT FOR UPDATE - строка при этом живая.
- Полагать, что long-running транзакция безвредна. Старый снимок держит горизонт видимости и не даёт вакууму чистить мёртвые версии во всей базе.
- Ждать HOT-обновлений при изменении индексированного столбца - их не будет, индексы перепишутся.
- Бояться "wraparound" xid: в старых версиях это была реальная угроза, в PG 14+ счётчики 64-битные для функций, но физический формат на странице 32-битный, и aggressive vacuum по-прежнему обязателен.
- Создайте таблицу: CREATE TABLE lab33 (id int PRIMARY KEY, v int); вставьте одну строку и запросите ctid, xmin, xmax.
- Сделайте UPDATE значения v и снова посмотрите ctid и xmin - убедитесь, что версия сменилась.
- Откройте второй сеанс psql. В первом начните BEGIN и сделайте UPDATE, но не коммитьте. Во втором сделайте SELECT этой строки - какое значение вы видите и почему.
- Закоммитьте первый сеанс, повторите SELECT во втором - проследите, как сменилась видимая версия.
- Поставьте pageinspect и через heap_page_items посмотрите все версии на нулевой странице, найдите мёртвую.
- Выполните VACUUM lab33; и снова загляните в heap_page_items - мёртвая версия должна исчезнуть.
- Сделайте UPDATE неиндексированного столбца и проверьте через pg_stat_user_tables (поле n_tup_hot_upd), что обновление прошло как HOT.
- Что хранят поля xmin и xmax и как по ним определяется видимость версии строки?
- Почему в MVCC читающая транзакция не блокирует пишущую?
- Чем DELETE и UPDATE отличаются на уровне версий строк и откуда берутся мёртвые кортежи?
- При каких условиях срабатывает HOT-обновление и что оно экономит?
- Как long-running транзакция мешает работе vacuum и к чему это приводит?
- Что такое snapshot и почему при Read Committed разные операторы одной транзакции могут видеть разные данные?
