Материализованные представления: меняем устаревание и место на диске на скорость чтения

Обычное представление vs материализованное

За десять минут ты поймёшь, почему молчаливое падение refresh опаснее медленного запроса — и как сделать это видимым раньше, чем заметят в финансах.

Обычное представление (view) — это сохранённый запрос, имя для SELECT. Каждое чтение заново выполняет полный запрос по живым базовым таблицам, поэтому оно всегда свежее и ничего не хранит. Материализованное представление выполняет запрос один раз, пишет результат на диск как настоящее отношение и отдаёт чтения из этой хранимой копии. Чтение становится дешёвым сканом таблицы или поиском по индексу вместо 14-секундного join-а с агрегацией. В этом вся ценность: ты платишь за место и вычисления заранее, один раз, чтобы многие чтения стали дешёвыми.

Цена — корректность. Обычное представление не может устареть. Материализованное устаревает в тот же миг, как меняется базовая строка после последнего refresh, и остаётся неверным, пока не сделаешь refresh снова. Поэтому вопрос перестаёт быть «view или materialized view» и становится единственным, который важен: как и как часто ты делаешь refresh — и какое окно устаревания терпит потребитель?

Полный refresh: просто, корректно — и блокировка, которую ты почувствуешь

Когда впервые берёшь материализованное представление, команда refresh выглядит тривиально — одна строка в cron. Что удивляет инженеров — это то, что она удерживает заблокированным, пока работает.

Дефолт в Postgres — REFRESH MATERIALIZED VIEW mv. Он заново выполняет определяющий запрос с нуля, пересчитывая каждую строку. Это предельно просто и всегда сходится к верному ответу — и берёт блокировку ACCESS EXCLUSIVE на всё время. Пока эта блокировка держится, каждое чтение представления блокируется. Сделай refresh тяжёлого агрегата, который идёт 90 секунд, и ты только что сделал дашборд недоступным на 90 секунд — ровно тогда, когда кто-то его загружает.

Запасной выход — REFRESH MATERIALIZED VIEW CONCURRENTLY. Он строит новый результат в фоне и подменяет его построчными диффами, поэтому читатели продолжают видеть старую версию до завершения подмены — без блокирующей чтения блокировки. Но у него жёсткие требования и цена, которую сеньор обязан знать: ему нужен хотя бы один UNIQUE-индекс на представлении (только имена столбцов, без выражений, без WHERE), он обычно медленнее обычного refresh, потому что вычисляет дельту относительно существующих строк, и одновременно может идти только один refresh на представление. Он также ждёт, пока завершатся текущие транзакции, прежде чем стартовать, поэтому долгий отчётный запрос может бесконечно стопорить refresh.

Инкрементальный refresh: платишь за запись, а не за чтение

А что если держать представление свежим дешевле, не платя полную стоимость запроса каждый раз? Именно этот вопрос решает инкрементальное сопровождение — и почему оно звучит идеально, пока не смотришь, что происходит с путём записи.

Полный refresh пересчитывает всё, даже если изменилась одна строка. Инкрементальное сопровождение представления (IVM — Incremental View Maintenance) вместо этого вычисляет только дельту — строки, затронутые недавними записями, — и применяет её к хранимому представлению. Стоимость переезжает из «дорогой периодический пересчёт» в «небольшая стоимость на каждую запись в базовую таблицу».

В чистом Postgres нет нативного инкрементального refresh — это каждый раз удивляет людей. Пробел закрывает расширение pg_ivm: create_immv() наполняет настоящую таблицу и ставит AFTER-триггеры на каждую базовую таблицу запроса. С этого момента каждый INSERT/UPDATE/DELETE запускает триггер, который вычисляет и применяет дельту внутри той же транзакции. Выигрыш — почти нулевое устаревание на выбранных представлениях. Цена ровно зеркальна полному refresh: каждая запись в базовую таблицу теперь чуть медленнее, сопровождение держит блокировки, которые душат пропускную способность записи, и есть ограничения SQL на то, что может содержать представление. Правило большого пальца от самого проекта: IVM окупается, когда базовая таблица читается много и меняется редко; при высоком темпе записи накладные расходы на каждую запись доминируют, и лучше делать запланированный полный refresh.

Потоковые материализованные представления: сопровождаются, а не обновляются

Вне Postgres другая модель убирает решение о refresh целиком: представление сопровождается непрерывно по мере прихода данных. Инкрементальное MV в ClickHouse ведёт себя как AFTER INSERT-триггер на самой левой исходной таблице — каждый вставленный блок строк трансформируется и пишется в целевую таблицу в момент вставки, читая только новые строки из RAM, а не с диска. Подвох, который сеньор обязан усвоить: оно видит только вставляемый блок. Оно не обрабатывает данные, существовавшие до создания представления (для этого нужен POPULATE), а агрегация группирует строки только внутри одного блока вставки — раскинь группу по двум блокам, и они не сольются, если только целевой движок (например, AggregatingMergeTree) не сведёт их при слиянии.

Специализированные потоковые базы идут дальше. Materialize компилирует SQL в differential dataflow (из Naiad от Microsoft Research), который работает с изменениями как с кортежами (data, time, diff) и делает работу пропорционально размеру изменения, а не размеру набора данных, — сопровождая сложные join-ы и агрегации с миллисекундной задержкой и строгой сериализуемостью. Концептуальный сдвиг: нет задачи «refresh», которую надо планировать, мониторить или которая может молча упасть. Представление по построению всегда согласовано со своими входами. Ты меняешь операционную нагрузку refresh на новую систему в эксплуатации и другую модель согласованности — eventually-consistent чтения в некоторых конфигурациях могут удивить пользователей, ждущих read-your-writes.