Матеріалізовані уявлення

Матеріалізоване представлення (MV) - це фізично збережений результат запиту (агрегація/проекція), який періодично або безперервно оновлюється і доступний для швидких читань. По суті, це «попередньо пораховані» дані з контрольованою свіжістю і вартістю читання.

• Стабілізувати латентність читань (p95/p99).
• Розвантажити «гарячі» OLTP-таблиці.
• Дати передбачуваний SLA для аналітики, API і фіч (рекомендації, лічильники, каталоги).

1) Коли використовувати MV (і коли - ні)

• Часто повторювані важкі запити (join/agg/window) з допустимою затримкою оновлення.
• CQRS/продуктові проекції: дашборди, каталоги, ранжовані списки, лічильники.
• Мульти-регіональні читання: «локальні» копії підсумків.

• Надстрога актуальність «на кожен запис» без логіки компенсації → краще індекси/OLTP + кеш/стрімінг.
• Складні транзакційні інваріанти при записі → MV не замінює транзакції.

2) MV vs кеш vs проекція

Кеш: «копія відповіді», управляється TTL/інвалідацією на рівні додатку; немає схеми.
MV: «копія даних», управляється СУБД/рушієм; є схема, індекси, транзакційність refresh.
Проекція (event sourcing/CQRS): обчислюється з подій; часто реалізується як таблиця + інкрементальні апдейти (тобто по суті «ручний MV»).

3) Способи оновлення

3. 1 Пакетний REFRESH (періодичний)

Планувальник (cron/скедулер): `REFRESH MATERIALIZED VIEW …`.
Плюси: просто, передбачувано, дешево. Мінуси: вікна несвіжості.

3. 2 Інкрементальний refresh

Дельти по ключах/тимчасовому вікну, upsert'и в MV.
Джерело змін: CDC (Debezium, logical replication), стрімінг (Kafka/Flink/Spark), тригери.
Плюси: мала затримка і вартість. Мінуси: складніше код і консистентність.

3. 3 Безперервний (streaming MV)

У колонкових/стрімінгових ДВЗ: матеріалізовані потоки/таблиці (ClickHouse/Kafka, Flink SQL, Materialize, BigQuery MV).
Плюси: секунди і нижче. Мінуси: вимагає стрім-інфри і чітких ключів/водяних знаків.

4) Консистентність і «свіжість»

Сильна консистентність MV буває при «атомарному» refresh (read-switch на нову версію).
Частіше - bounded staleness: «не старше Δ t/вікна». Комунікуйте це в контрактах API/UX.
Для платежів/строгих інваріантів тримайте CP-ядро в OLTP, а MV використовуйте як read-plane.

5) Моделювання та схема

Робіть MV вузькою за призначенням: одне завдання - один MV.
Зберігайте тимчасові ключі (event_time/watermark) і бізнес-ключі (tenant_id, entity_id).
Індекси під часті фільтри/сортування; колонкові СУБД - під агрегати/скани.
Партіонування за датою/тенанту/регіону для швидкого refresh і ретенції.

6) Інкрементальні апдейти: патерн upsert-проекції

1. Приходить зміна (CDC/подія).
2. Вважаємо дельту для MV-рядка (recompute/merge).
3.'UPSERT'за ключем ('tenant _ id, entity_id, bucket').
4. Оновлюємо метадані свіжості.

Ідемпотентність обов'язкова: повтор дельти не повинен ламати підсумок.

7) Приклади (концептуально)

PostgreSQL (батчевий refresh)

sql
CREATE MATERIALIZED VIEW mv_sales AS
SELECT date_trunc('day', created_at) AS day,
tenant_id,
SUM(amount) AS revenue,
COUNT()  AS orders
FROM orders
GROUP BY 1,2;

-- Быстрые чтения
CREATE INDEX ON mv_sales (tenant_id, day);

-- Без блокировок чтения при обновлении
REFRESH MATERIALIZED VIEW CONCURRENTLY mv_sales;

ClickHouse (streaming MV из Kafka)

sql
CREATE TABLE events_kafka (..., ts DateTime, tenant_id String)
ENGINE = Kafka SETTINGS kafka_broker_list='...',
kafka_topic_list='events',
kafka_format='JSONEachRow';

CREATE MATERIALIZED VIEW mv_agg
ENGINE = AggregatingMergeTree()
PARTITION BY toDate(ts)
ORDER BY (tenant_id, toStartOfMinute(ts)) AS
SELECT tenant_id,
toStartOfMinute(ts) AS bucket,
sumState(amount) AS revenue_state
FROM events_kafka
GROUP BY tenant_id, bucket;

BigQuery MV (авто-оновлення)

sql
CREATE MATERIALIZED VIEW dataset.mv_top_products
AS SELECT product_id, SUM(amount) AS revenue
FROM dataset.orders
WHERE _PARTITIONDATE BETWEEN DATE_SUB(CURRENT_DATE(), INTERVAL 30 DAY) AND CURRENT_DATE()
GROUP BY product_id;

8) Свіжість в інтерфейсах/контрактах

Повертайте'X-Data-Freshness: <seconds> '/поле'as _ of'.
Для критичних екранів - «кнопка оновити» і бейдж «оновлено N з назад».
В API вказуйте SLO свіжості (напр., p95 ≤ 60 с).

9) Мульти-тенант і регіони

Ключ'tenant _ id'в MV - обов'язковий.
Fairness: квоти на refresh/стрім по орендарях; шедулінг великих MV вночі per tenant.
Residency: MV живе в тому ж регіоні, що і первинні дані; крос-регіон - тільки агрегати.

10) Спостережуваність

• `freshness_age_ms` (p50/p95/p99), `refresh_latency_ms`, `rows_processed/s`, `refresh_errors`.
• Розмір MV/партій, витрати зберігання.
• Для стрімінгу: лаг конектора, «вода» (watermark), частка late events.

• Теги: `mv_name`, `tenant_id`, `partition`, `refresh_id`, `delta_size`.
• Звіти про «перерахунки» і фейли з причин (schema mismatch, timeout).

11) Тестування і хаос

Correctness: порівняння MV vs джерела на підвиборках; контрольні суми.
Freshness under load: навантаження на запис + гарантія SLO свіжості.
Schema evolution: додавання/перейменування полів, «падіння» конектора CDC.
Late/Out-of-order: реплеї подій, зміна водяних знаків.
Ідемпотентність: повторна доставка дельт/батчів.

12) Ретеншн і вартість

Зберігайте тільки потрібні вікна (наприклад, 90 днів); старі партії архівуйте.
Регулярна вакуумізація/мердж (по движку).
Зведіть MV під конкретні API/сторінки, уникаючи «універсального монстра».

13) Безпека та відповідність

Наслідуйте політики доступу від джерела (RLS/ACL) - не роздавайте MV ширше, ніж таблиці-джерела.
Маскуйте PII при побудові MV, особливо для аналітики/логів.
Аудит refresh/редрайвів.

14) Типові помилки

«Один величезний MV на все» → дорогі refresh і слабка ізоляція.
Відсутність індексів/партій → p99 скаче, refresh душить кластер.
Повний перерахунок замість дельт там, де можна інкрементально.
Неоголошена свіжість в API/UX → претензії користувачів до «застарілих» даних.
Ігнорування schema evolution/CDC помилок → втрата узгодженості.
Спроба замінити MV транзакціями: MV - про читання, не про суворі операції запису.

15) Швидкі рецепти

Дашборд продукту: MV по хвилинним/годинним бакетам, refresh за розкладом + on-demand для VIP, p95 свіжості ≤ 60 с.
Каталог/пошук: інкрементальна проекція з CDC (upsert), індекси за фільтрами, lag ≤ 5-15 с.
Фін-звітність: пакетні MV з атомарним'REFRESH CONCURRENTLY', контрольні суми, «as_of» у відповідях.
Глобальний SaaS: регіональні MV, агрегація крос-регіонально асинхронно.

16) Чек-лист перед продом

• Визначений SLA свіжості (Δt/p95) і він відображений в API/UX.
• Вибрано режим: batch refresh/інкрементальний/streaming; описані джерела (CDC/події).
• MV спроектований «за завданням», є індекси і партії, зберігання обмежене вікном.
• Ідемпотентність upsert/агрегатів підтверджена тестами; обробка late/out-of-order.
• Спостережуваність: метрики свіжості/лага, алерти, трейсинг refresh.
• Плейбуки: перерахунок партії, редрайв після збою конектора, еволюція схеми.
• Доступ і PII відповідають вихідному; аудит включено.
• Вартість під контролем: ретеншн, компресія, час вікна refresh.
• Документація: що в MV «істина», що - похідний шар, очікування бізнесу.

Висновок

Матеріалізовані уявлення - це інженерний компроміс між швидкістю читань і актуальністю. При ясному SLA свіжості, коректній схемі, інкрементальному оновленні і нормальній телеметрії MV перетворюють важкі запити в передбачувані мілісекунди - без жертвування надійністю і контролем витрат.