即時物化視圖 - AnalyticDB

AnalyticDB for PostgreSQL提供了即時物化視圖功能，相較於普通（非即時）物化視圖，即時物化視圖無需手動調用重新整理命令，即可實現資料更新時自動同步重新整理物化視圖。

AnalyticDB for PostgreSQL中，即時物化視圖採用增量方式進行資料更新。即當基表的資料變化時，即時物化視圖會根據基表的更新進行增量的資料更新。基於此特性，可利用即時物化視圖進行類似即時ETL的資料處理任務。此外，還可以基於即時物化視圖再建立即時物化視圖，當基表發生變化時，相關級聯的即時物化視圖也會自動更新。如此可實現構建資料分析的即時ETL處理鏈路。

AnalyticDB for PostgreSQL的即時物化視圖當前支援同步模式和非同步模式。

在同步模式下，即時物化視圖採用的是STATEMENT（語句）層級的自動更新，即當基表的更新語句（INSERT、COPY、UPDATE、DELETE）執行成功的同時，構建於基表的物化視圖會即時更新，保證資料的強一致性。如果即時物化視圖的更新未完成，寫入事務也無法提交。
在非同步模式下，對基表先執行寫入操作，操作結束後可以正常提交事務，而後即時物化視圖的累加式更新會在後台由資料庫核心自動調度。通常，系統負載正常情況下可以在秒級完成資料更新。

普通物化視圖的詳細資料，請參見物化視圖管理。

同步模式

AnalyticDB for PostgreSQL的即時物化視圖的同步模式採用的是STATEMENT一致性。即當基表的某條語句執行成功時，即時物化視圖中的資料將會同步更新。STATEMENT即時物化視圖可以實現當對基表的更新語句執行成功時，對應的物化視圖的資料已經完成更新，更新邏輯如下。

資料庫核心將先對基表執行更新，再對物化視圖執行更新。當基表更新失敗時，物化視圖中的資料不會發生變化。
如果對物化視圖更新失敗，則基表的更新也將失敗，基表資料將不會有任何變化，同時對基表執行的語句將返回失敗。

如果使用明確交易（例如BEGIN+COMMIT），當基表的更新語句執行成功後，物化視圖中的資料更新同樣在這個事務中：

如果AnalyticDB for PostgreSQL中隔離等級為READ-COMMITTED，當事務未提交時，物化視圖中的更新對其他事務將不可見。
如果交易回復，基表和物化視圖都會進行相應的復原。

版本限制

在以下版本中，即時物化視圖將預設使用同步模式。

核心版本為v7.0.6.9（不含）以下的AnalyticDB PostgreSQL 7.0版執行個體。
核心版本為v6.6.2.5（不含）以下的AnalyticDB PostgreSQL 6.0版執行個體。

如需切換即時物化視圖預設模式，請提交工單。

非同步模式

在非同步模式下，基表寫入操作先完成，並可以正常提交事務，此時即時物化視圖中的資料不會立即更新。在事務提交後，由資料庫核心在後台自動調度即時物化視圖的資料累加式更新，並發的寫入事務會由資料庫自行處理。在即時物化視圖更新的過程中可能進行攢批更新等操作，資料庫核心對所有並發基表的寫入操作，以最終資料一致性的目的更新即時物化視圖。因此，即使是非同步模式下的並發寫入，資料庫核心也會保證即時物化視圖中的資料與基表的資料最終是一致的。由於系統負載正常時即時物化視圖的更新通常可以在秒級完成，因此非同步模式能滿足大部分即時數倉情境的需求。

版本限制

在以下版本中，新建立的即時物化視圖將預設使用非同步模式。

核心版本為v7.0.6.9及以上的AnalyticDB PostgreSQL 7.0版執行個體。
核心版本為v6.6.2.5及以上的AnalyticDB PostgreSQL 6.0版執行個體。

如需切換即時物化視圖預設模式，請提交工單。

使用限制

AnalyticDB for PostgreSQL對構建即時物化視圖所使用的查詢語句有所限制，您只能建立包含如下查詢語句的即時物化視圖。

查詢語句可以包含大部分的過濾和投影操作，以及大部分的Postgres內建函數和UDF函數。
查詢語句可以包含大部分的彙總函式和視窗函數。
如果查詢語句包含JOIN，支援使用INNER JOIN和OUTER JOIN（LEFT、RIGHT、FULL）語句。
如果查詢語句包含OUTER JOIN，JOIN條件僅支援AND串連，不支援OR串連，不支援等值條件的左右列來自同一張表。
僅支援簡單查詢、FROM子查詢及UNION ALL查詢語句，不支援CTE和其他類型子查詢等複雜查詢語句。

當您在基表上建立了即時物化視圖，對基表執行的DDL將受到限制，限制如下。

對基表執行TRUNCATE命令時，即時物化視圖不會同步變化，需要手動重新整理物化視圖或重建物化視圖。
只有指定了CASCADE選項，才能對基表執行DROP TABLE命令。
對基表執行ALTER TABLE命令無法刪除或修改物化視圖引用的欄位。

使用情境

建議您在具有如下特徵的情境使用即時物化視圖。

基於即時物化視圖的累加式更新及嵌套級聯能力，可以方便地構建即時ETL處理鏈路，且無需額外的調度系統處理依賴關係。既可在上遊原始基表上建立即時物化視圖，還可以基於即時物化視圖再建立下遊級聯的即時物化視圖，以產出即時ETL的處理結果，例如比較典型的即時寬表，即時彙總等，用於加速查詢分析。
基於即時物化視圖可以大幅加速查詢結果的速度。尤其針對查詢結果相對於對基表僅包含少量的行或列，或者擷取查詢結果需要經過大量的計算處理的情境，包括：
- 具有很高過濾性的過濾條件。
- 高度集中的彙總函式等情境。
- 半結構化資料分析。
- 需要很長時間才能計算完成的彙總操作。
視圖的基表中包含很大的全量資料，增量資料的更新量遠小於全量資料。

即時物化視圖適用於所有適合使用普通物化視圖的情境。與普通物化視圖相比，即時物化視圖具有高度的資料一致性，當基表發生改變時，即時物化視圖將以較低的效能消耗（增量）發生改變，而普通物化視圖如果每次基表發生改變，都需要手動執行全量重新整理操作才能保證資料的一致性，大部分時候效能消耗較大。所以當基表具有一定程度的更改，甚至需要流式匯入更新時，相較於普通物化視圖，即時物化視圖具有很大優勢。

即時物化視圖代價

即時物化視圖類似即時維護的索引，在對查詢效能進行大幅度最佳化的同時，對高效能寫入有一定影響。影響即時物化視圖寫入效能的幾個關鍵因素：

構建即時物化視圖查詢語句的複雜度和級聯的層數。單表和簡單JOIN的單層即時物化視圖可以在不同配置的執行個體上支援每秒數萬到數十萬行的寫入。複雜JOIN及多層嵌套情境的寫入會佔用更多的執行個體計算資源，同時寫入效能相應成比例降低。
包含JOIN的即時物化視圖可能存在寫入放大的情況。例如，當某張10億資料量的事實表JOIN一張1萬資料量的維度資料表的即時物化視圖中，10億級的事實大表通常可以獲得很高的寫入效能，而1萬資料量的較小維度資料表的資料變化由於增量計算時對結果集的影響存在放大，寫入效能會成比例（寫入放大的比例）降低。
AnalyticDB for PostgreSQL執行個體的規模和資源。即時物化視圖進行增量計算和寫入過程中會使用執行個體資源，執行個體的規模和資源對即時物化視圖寫入效率會產生影響。當即時寫入的效能不滿足業務需求時，可以考慮增加計算資源以擷取更好的寫入效能。

建立/刪除即時物化視圖

使用CREATE INCREMENTAL MATERIALIZED VIEW命令建立一個名為mv即時物化視圖，樣本如下。
```
CREATE INCREMENTAL MATERIALIZED VIEW mv AS SELECT * FROM base WHERE id > 40;
```
使用DROP MATERIALIZED VIEW命令刪除物化視圖mv，樣本如下。
```
DROP MATERIALIZED VIEW mv;
```

使用樣本

建立基表。

CREATE TABLE test (a int, b int) USING HEAP DISTRIBUTED BY (a);

建立即時物化視圖。

CREATE INCREMENTAL MATERIALIZED VIEW mv AS SELECT * FROM TEST WHERE b > 40 DISTRIBUTED BY (a);

向基表插入資料。

INSERT INTO test VALUES (1, 30), (2, 40), (3, 50), (4, 60);

查看基表。

SELECT * FROM test;

查詢結果如下。

 a | b
---+----
 1 | 30
 2 | 40
 3 | 50
 4 | 60
(4 rows)

查看物化視圖。
```
SELECT * FROM mv;
```
物化視圖已經修改成功，查詢結果如下：
```
 a | b
---+----
 3 | 50
 4 | 60
(2 rows)
```