Зачем многоверсионность: транзакции наблюдаемо

Представь банковскую таблицу. Один запрос считает суммарный баланс по всем счетам - читает миллион строк, и это занимает время. В этот момент идёт перевод денег: списать с одного счёта, зачислить на другой.

Вопрос: что увидит отчёт, если перевод пройдёт прямо посреди его чтения? Если отчёт прочитает счёт-отправитель уже после списания, а счёт-получатель ещё до зачисления, он недосчитается денег. Сумма получится неверной не из-за ошибки в данных, а из-за того, что отчёт поймал систему в промежуточном состоянии.

Это и есть проблема согласованности при конкурентном доступе. Её надо решить так, чтобы отчёт видел целостную картину, а перевод не ждал окончания отчёта.

Простое решение - блокировки. Пишущий запирает строки, читающие ждут, пока он закончит. Тогда отчёт либо целиком до перевода, либо целиком после - промежуточного состояния он не увидит.

Просто и надёжно, но медленно. Отчёт на миллион строк держит блокировки долго, и все переводы на это время встают. А если наоборот - перевод ждёт, пока отчёт дочитает, то быстрые операции записи зависят от медленных операций чтения. Чтение и запись начинают мешать друг другу, и система буксует именно тогда, когда нагрузка высокая.

Хочется иначе: чтобы читающие не блокировали пишущих, а пишущие - читающих. Для этого нужно, чтобы старое и новое состояние строки какое-то время существовали одновременно.

Решение PostgreSQL - многоверсионность (MVCC). Строка не правится на месте. Вместо этого каждое изменение порождает новую версию, а старая остаётся жить, пока её кто-то видит.

Это ровно те поля xmin/xmax, что мы видели в заголовке кортежа (tuple-header). Теперь понятно, зачем они: по ним каждая транзакция решает, какую версию ей показать. Отчёт видит счета такими, какими они были на его старте, а перевод спокойно создаёт новые версии рядом. Подробнее идея разобрана в why-mvcc.

Лучший способ поверить - посмотреть. Откроем две сессии к одной базе.

Сессия 1 начинает транзакцию и меняет бронь, но не коммитит:

-- сессия 1

BEGIN;

UPDATE bookings SET total = 999 WHERE book_ref = '000001';

-- приглашение сменилось на lab=*# : звёздочка значит «идёт транзакция»

Сессия 2 в этот момент читает ту же бронь:

-- сессия 2

SELECT total FROM bookings WHERE book_ref = '000001';

--  total

-- --------

--  101.00     <- старое значение! изменения сессии 1 не видны

Сессия 2 видит старую версию: незакоммиченное изменение для неё не существует. Теперь сессия 1 фиксирует:

-- сессия 1

COMMIT;

И только теперь сессия 2 увидит новое значение:

-- сессия 2

SELECT total FROM bookings WHERE book_ref = '000001';

--  total

-- --------

--  999.00     <- после COMMIT видна новая версия

Звёздочка в приглашении lab=*# - удобный индикатор: пока она есть, твоя транзакция открыта и её изменения никто, кроме тебя, не видит.

В этом опыте есть главное свойство MVCC: сессия 2 читала, пока сессия 1 держала открытую запись, и никто никого не ждал. Сессия 2 не зависла в ожидании коммита - она просто увидела старую версию. Сессия 1 не ждала, пока сессия 2 дочитает.

Это и есть ответ на задачу из начала главы. Отчёт по балансу видит согласованный срез данных на момент своего старта (его снимок - тема snapshot и следующей главы). Перевод тем временем пишет новые версии. Чтение не блокирует запись, запись не блокирует чтение - именно то, чего не давали голые блокировки.

Бесплатно это не даётся. Каждый UPDATE и DELETE оставляет мёртвые версии. В опыте выше после коммита сессии 1 старая версия брони с total = 101 осталась лежать на странице - её больше никто не увидит, но место она занимает.

Пока такую версию видит хоть одна транзакция, тронуть её нельзя. Когда последняя такая транзакция завершится, версия становится мусором. Убирает мусор vacuum - ему посвящена целая часть книги. Поэтому активно изменяемая таблица в PostgreSQL всегда чуть больше «чистого» объёма данных. Это не дефект, а обратная сторона того, что читатели и писатели не мешают друг другу.

Раз мёртвую версию нельзя убрать, пока её кто-то видит, появляется коварное следствие. Одна долгая транзакция - открытая и забытая, или огромный отчёт на часы - заставляет систему хранить все версии, которые существовали на её старте. Vacuum не может их убрать: вдруг эта транзакция на них посмотрит.

В итоге одна забытая транзакция в углу способна раздуть таблицы по всей базе: мусор копится, потому что его не дают убрать. Мы вернёмся к этому подробно в части про vacuum и горизонт транзакции. Пока запомни связь: долгая транзакция - это удерживаемый мусор, и BEGIN без своевременного COMMIT обходится дороже, чем кажется.