Как читать сведения, пока их меняют, и зачем сохранять старые версии строк. Объясняем многоверсионность, уборку ненужных версий и её отличие от резервной копии.
Исправление не обязательно сразу стирает прежнее значение
В системе одновременно работают читатель и редактор. Первый собирает сведения для отчёта, второй исправляет запись. Если бы любое исправление немедленно уничтожало прежнее состояние, согласовать эти действия было бы сложнее. Один из подходов — сохранять версии и определять, какая из них подходит конкретному чтению.
Такой подход называют многоверсионностью, или MVCC — управлением одновременным доступом через несколько версий. Нас здесь интересует устройство версий и их жизненный цикл. Вопрос о том, какие изменения видны при повторном чтении в разных режимах, относится к отдельной теме уровней изоляции. Различать эти вопросы полезно: правило видимости и способ хранения связаны, но не совпадают.
Что означает видимый снимок
PostgreSQL описывает чтение как работу со снимком данных, согласованным с определённым моментом. Это не обязательно отдельная копия всей базы. Система определяет видимость версий с учётом выполняющихся и завершённых транзакций — связанных групп изменений.
Представим карточку заявки с исправляемым адресом. Для одного допустимого чтения ещё подходит прежняя версия, а другое позже может получить уже подтверждённую новую. Это условная иллюстрация выбора версий. Она не задаёт один режим для всех запросов и не обещает, что любой читатель немедленно увидит последнее нажатие кнопки. Для каждого сценария важно знать действующие правила чтения.
Старая версия некоторое время нужна
В руководстве PostgreSQL по обслуживанию объясняется, что изменение или удаление строки не сразу убирает её старую версию. Её нельзя удалять, пока она ещё потенциально видна другим транзакциям. Когда версия больше никому не нужна, занимаемое ею место можно подготовить для повторного использования.
В условной картотеке это похоже на сохранение прежнего листа, пока кто-то имеет право закончить работу с ним. Однако база не обязана хранить все прежние листы бесконечно. По завершении нужных чтений наступает этап уборки. Поэтому само наличие многоверсионности не означает, что пользователь сможет открыть произвольную запись за любой прошлый день.
Почему после изменения размер не обязан уменьшаться
В PostgreSQL обычное обслуживание удаляет уже ненужные версии и освобождает место для повторного использования внутри таблицы. Это не всегда приводит к немедленному уменьшению файла на диске. В документации различаются повторное использование пространства и отдельные операции, которые могут физически уплотнять данные.
Для читателя отчёта отсюда следует полезное ограничение: по одному размеру файла нельзя определить, остались ли в нём доступные старые бизнес-записи. Если таблица активно меняется, инженеру нужно оценивать обслуживание и продолжающиеся транзакции. Самостоятельно удалять файлы базы ради освобождения места нельзя. Нужен разбор специалистом с учётом того, какие версии ещё могут понадобиться работающей системе.
Многоверсионность не отменяет все ожидания
Обычное чтение и изменение данных могут меньше мешать друг другу благодаря выбору версий. Но это не означает, что в базе вообще нет блокировок. PostgreSQL отдельно описывает блокировки таблиц и строк. Два участника, меняющие одну запись, всё ещё могут зависеть от действий друг друга, а изменение структуры таблицы — требовать особых условий.
Поэтому при жалобе «база ждёт» недостаточно ответить «у нас есть MVCC». Сначала нужно выяснить, что именно выполнялось: чтение, изменение записи или обслуживание структуры. Механизм решает определённую часть задачи согласования. Он не превращает все виды работы с данными в независимые действия и не устраняет необходимость наблюдать за ожиданиями.
Чем версии отличаются от резервной копии
Предлагаемая проверка понимания проста: представьте ошибочно изменённый адрес, обнаруженный через неделю. Наличие MVCC ещё не даёт основания обещать его восстановление. Для такой задачи нужны отдельно предусмотренные способы сохранения и восстановления истории. Версии для текущей согласованной работы могут к этому моменту уже не требоваться системе.
При обсуждении устройства базы полезно задать три вопроса: для каких чтений сохраняются версии, когда они становятся ненужными и как обслуживается занимаемое ими место. Отдельно спросите о восстановлении после ошибки. Это разные требования. Понимание жизненного цикла версии помогает не путать согласованное чтение, постоянный журнал изменений и резервное копирование — даже если все три механизма связаны с прошлым состоянием данных.
Следующий шаг
Программа «SQL инженер» подойдёт для последовательного знакомства с работой баз данных. Изучая одновременные изменения, полезно связывать смысл транзакции с тем, какую версию получает читатель и как система обслуживает её хранение.
