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