實例化視圖

實例化視圖（MV）是物理保存的查詢結果（聚合/投影），可以定期或連續更新，並可用於快速讀取。從本質上講，這些數據是「預先計算的」數據，具有受控的新鮮度和閱讀成本。

• 穩定閱讀潛伏期（p95/p99）。
• 卸載「熱」OLTP表。
• 提供可預測的SLA，用於分析，API和feach（指南，計數器，目錄）。

1）何時使用MV（以及何時不使用）

• 經常重復的重請求（join/agg/windows）,並允許更新延遲。
• CQRS/產品投影：行車記錄，目錄，排名列表，計數器。
• 多區域閱讀：結果的「本地」副本。

• 沒有補償邏輯的「每個條目」的超嚴格相關性→ 更好的索引/OLTP+緩存/流媒體。
• → MV寫入時的復雜事務不變量不會取代事務。

2） MV vs緩存vs投影

緩存：「響應副本」，由TTL/應用程序級殘疾人管理；沒有方案。
MV：「數據副本」，由DBMS/引擎控制；有方案、索引、refresh事務性。
投影（event sourcing/CQRS）：從事件計算；通常實現為表+增量升級（即本質上是「手動MV」）。

3）升級方法

3.1批次REFRESH（定期）

調度程序（cron/skeduler）：「REFRESH MATERIALIZED VIEW……」。
優點：簡單，可預見，便宜。缺點：窗戶陳舊。

3.2增量refresh

三角洲按鑰匙/時間窗口，upsert's in MV。
更改來源：CDC（Debezium，邏輯復制），流媒體（Kafka/Flink/Spark），觸發器。
優點：小延遲和成本。缺點：更復雜的代碼和一致性。

3.3連續（streaming MV）

在柱子/流媒體ICE中：實例化流/表（ClickHouse/Kafka，Flink SQL，Materialize，BigQuery MV）。
優點：秒及以下。缺點：需要流媒體和清晰的鑰匙/水印。

4）一致性和「新鮮」

MV的強一致性發生在「原子」refresh（新版本的讀取開關）中。
更常見的是-受限制的staleness：「不超過Δ t/窗口」。在API/UX合同中傳播此信息。
對於付款/嚴格的不變式，將CP內核保持在OLTP中，將MV用作讀平面。

5）建模和電路

使MV的目的狹窄：一個任務-一個MV。
存儲臨時密鑰（event_time/watermark）和業務密鑰（tenant_id、entity_id)。
常見過濾器/排序索引；柱狀DBMS-用於單元/掃描。
按日期/tenant/地區進行分期交易，以進行快速反思和回避。

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 c）。

9）多特南特和地區

MV中的「tenant_id」鍵是必需的。
Fairness：按租戶分列的refresh/流配額；在夜間散步大型MV。
居住地：MV與主要數據生活在同一地區；跨區域-僅聚合。

10）可觀察性

• `freshness_age_ms` (p50/p95/p99), `refresh_latency_ms`, `rows_processed/s`, `refresh_errors`.
• MV/批量大小，存儲成本。
• 對於流媒體：連接器脫落，「水」（watermark），長期活動份額。

• Теги: `mv_name`, `tenant_id`, `partition`, `refresh_id`, `delta_size`.
• 基於原因的「重新計票」和fails報告（schema mismatch，timeout）。

11）測試和混亂

Correctness：比較下擺上的MV vs來源；校驗金額。
新鮮裝載：記錄負載+SLO保修新鮮度。
計劃演變：添加/重命名字段，CDC連接器的「下降」。
後期/訂單：事件中繼,水印更改。
等效性：重新交付三角洲/蹦床。

12）重建和成本

僅存儲所需的窗口（例如90天）；存檔舊批次。
定期真空化/merj（按引擎）。
將MV減少到特定的API/頁面,避免「通用怪物」。

13）安全性和合規性

繼承源訪問策略（RLS/ACL）-不要比源表更廣泛地分發MV。
在構建MV時偽裝PII，特別是對於分析/邏輯。
refresh/redrive審核。

14）典型錯誤

「每個人的一個巨大的MV」 →昂貴的refresh和弱的絕緣。
沒有索引/批次→ p99跳躍，refresh扼殺群集。
在可以增量的地方完全重新計票而不是三角洲。
API/UX中未聲明的新鮮度→用戶對「過時」數據的主張。
忽視schema evolution/CDC錯誤→失去一致性。
嘗試用事務代替MV：MV是關於閱讀，不是關於嚴格的寫操作。

15）快速食譜

Dashboard產品：MV每分鐘/每小時垃圾箱，refresh定時處理+VIP點播，p95新鮮度≤ 60秒。
目錄/搜索：CDC的增量投影（upsert），過濾器索引，lag ≤ 5-15 s。
Fin報告：帶有原子式「REFRESH CONCURRENTLY」的捆綁式MV，校驗和在響應中「as_of」。
全球SaaS：區域MV，跨區域異步聚合。

16）售前支票清單

• SLA定義為新鮮度（Δt/p95）,它反映在API/UX中。
• 選擇模式：batch refresh/增量/streaming；描述來源（CDC/事件）。
• MV是按任務設計的，有索引和批次，存儲僅限於窗口。
• 通過測試確認了upsert/聚合物的冪等性；處理late/out-of-order。
• 可觀察性：新鮮/滯後度量，Alerta，Tracing refresh。
• 花花公子：重新計票，連接器故障後重新分區，計劃演變。
• 訪問和PII與原件匹配；已啟用審計。
• 控制成本：重建,壓縮,refresh窗口時間。
• 文檔：MV中的「真相」是衍生層，業務期望。

二.結論

實例化表示是閱讀速度和相關性之間的工程權衡。通過清晰的SLA，正確的電路，增量更新和正常的遙測，MV將繁重的查詢轉換為可預測的毫秒-而無需犧牲可靠性和成本控制。