同步模式

云原生數據倉庫 AnalyticDB PostgreSQL 版的實時物化視圖的同步模式采用的是STATEMENT一致性。即當基表的某條語句執行成功時，實時物化視圖中的數據將會同步更新。STATEMENT實時物化視圖可以實現當對基表的更新語句執行成功時，對應的物化視圖的數據已經完成更新，更新邏輯如下。

• 數據庫內核將先對基表執行更新，再對物化視圖執行更新。當基表更新失敗時，物化視圖中的數據不會發生變化。

• 如果對物化視圖更新失敗，則基表的更新也將失敗，基表數據將不會有任何變化，同時對基表執行的語句將返回失敗。

如果使用顯式事務（例如BEGIN+COMMIT），當基表的更新語句執行成功后，物化視圖中的數據更新同樣在這個事務中：

• 如果云原生數據倉庫 AnalyticDB 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 PostgreSQL 版對構建實時物化視圖所使用的查詢語句有所限制，您只能創建包含如下查詢語句的實時物化視圖。

• 查詢語句可以包含大部分的過濾和投影操作，以及大部分的Postgres內置函數和UDF函數。

• 查詢語句可以包含大部分的聚合函數和窗口函數。

• 如果查詢語句包含JOIN，支持使用INNER JOIN和OUTER JOIN語句。

• 如果查詢語句包含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 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;

使用示例

1. 創建基表。

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

2. 創建實時物化視圖。

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

3. 向基表插入數據。

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

4. 查看基表。

   SELECT * FROM test;

   查詢結果如下。

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

5. 查看物化視圖。

   SELECT * FROM mv;

   物化視圖已經修改成功，查詢結果如下：

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