Data engineering
Materialized views: тест на припоминание
Припоминание сильнее перечитывания. Для каждого промпта проговорите или запишите полный ответ по памяти, прежде чем открыть модельный — именно усилие припоминания закрепляет компромиссы к моменту, когда вы окажетесь на дизайн-ревью.
Восстановите ключевые механизмы юнита — что даёт materialized view, лестницу refresh, скрытые издержки CONCURRENTLY, incremental maintenance, streaming MV и режим отказа со staleness — не подглядывая в урок.
- 01Что на самом деле даёт materialized view по сравнению с обычным view и какое одно решение становится главным, когда он у вас есть?
- 02Сравните обычный REFRESH MATERIALIZED VIEW и REFRESH ... CONCURRENTLY, включая требования и издержки CONCURRENTLY.
- 03Что такое incremental view maintenance, как pg_ivm реализует его в Postgres и когда он окупается, а когда вредит?
- 04Как streaming materialized views (ClickHouse, Materialize) меняют модель и какой подвох должен усвоить senior для каждого?
- 05Коллега предлагает materialized view с ночным refresh, чтобы ускорить медленный отчёт. Какие три риска вы поднимаете до одобрения?
- 06Упорядочьте решения, которые senior принимает, берясь за materialized view, и скажите, почему ответственность идёт последней, но важнее всего.
Если вы смогли восстановить каждый ответ по памяти, вы держите хребет юнита: materialized view обменивает свежесть на скорость чтения, поэтому refresh — единственное значимое решение; обычный refresh блокирует чтения блокировкой ACCESS EXCLUSIVE, тогда как CONCURRENTLY избегает этого ценой уникального индекса, более медленных diff-ов и ожидания старых транзакций; pg_ivm даёт почти нулевой staleness, но облагает каждую запись, поэтому подходит только для read-heavy таблиц с малой записью; streaming MV убирают refresh-задачу, но добавляют систему и модель согласованности; а сквозной режим отказа везде один — неотслеживаемый refresh отдаёт устаревшие данные, пока всё выглядит зелёным — поэтому владейте refresh, ограничивайте окно staleness и алертите на него.