持續性 materialized view
本文將概略說明持續性具體化檢視區塊，以及常見的用途。閱讀本頁之前，請先熟悉 Bigtable 總覽。
在 Bigtable 中，持續性具體化檢視區塊是持續執行的 SQL 查詢的預先計算結果，由系統全面管理，並會逐步更新持續性具體化檢視區塊。SQL 查詢可包含基礎 Bigtable 資料表的匯總和轉換。使用持續性具體化檢視畫面可提升效能和效率。
持續性具體化檢視表中的資料包括：
- 從來源資料表中的資料衍生而來的匯總或轉換值
- 定義分組鍵的未匯總值
持續性具體化檢視區塊可讓您在擷取資料時預先匯總資料。此外，持續具體化檢視區塊的結構也與來源資料表不同，會以經過最佳化的結構呈現來源資料表資料，以便查詢與來源資料表查詢不同的查閱模式。
以下是 Bigtable 中持續性 materialized view 的主要特徵：
- 免維護：系統會在背景預先計算持續性 materialized view。來源資料表中的資料變更 (包括更新和刪除) 會在背景自動傳播至連續具體化檢視區塊，使用者無需採取任何動作。
- SQL 開發模式：持續性具體化檢視區塊以 GoogleSQL 為基礎，用於 Bigtable 查詢，包括 SQL 函式、篩選器和彙整。
- 與垃圾收集作業同步：持續具體化的檢視區塊會與來源資料表的垃圾收集政策保持同步，並在資料表資料過期或刪除時自動更新。
- 讀取和寫入延遲時間不受影響：如果執行個體的叢集佈建充足或使用自動調整功能，持續具體化檢視表對來源資料表的效能影響極小。
- 最終一致性：系統會在背景計算持續性 materialized view。持續性具體化檢視表的更新作業可能會延遲，但持續性具體化結果一律會隨著時間保持一致。
您用來定義連續具體化檢視區塊的資料列鍵、資料欄限定詞和資料欄值，會視為服務資料。因此，請勿使用含有私密資訊的資料列索引鍵、資料欄限定詞或資料欄值，建立連續具體化檢視區塊。如要瞭解服務資料的處理方式，請參閱Google Cloud 隱私權聲明。
您可以使用 Google Cloud CLI、 Google Cloud 控制台中的 Bigtable Studio 查詢編輯器，或是適用於 Java 和 Go 的 Bigtable 用戶端程式庫，建立持續具體化檢視區塊。
您可以使用下列項目從持續性具體化檢視區塊讀取資料：
- Bigtable Studio 查詢編輯器
- 支援 SQL 查詢的 Bigtable 用戶端程式庫
ReadRows使用適用於 Java 和 Go 的 Bigtable 用戶端程式庫呼叫 API
詳情請參閱「從連續具體化檢視區塊讀取資料」。
持續性具體化檢視表的使用時機
您可以透過持續性具體化檢視區塊，使用 SQL 定義 Bigtable 資料的新表示法。建立完成後，系統會持續自動將來源資料表中的資料，重組為 SQL 查詢定義的格式，並持續具體化檢視區塊。這樣一來，您就不必在讀取資料後查詢資料表並轉換或匯總資料，而是可以查詢持續具體化檢視區塊。
在下列情況下，持續性具體化檢視區塊可提升查詢效能：
- 資料預先匯總：您可以使用連續具體化檢視，匯總各列的傳入資料。這項功能可讓您快速擷取摘要和匯總資料，例如資訊主頁的指標。
- 自動化 Lambda 和 Kappa 架構：如果應用程式需要混合使用即時串流管道資料和包含歷來資料的批次管道資料，請使用持續具體化檢視區塊。這些檢視畫面會隨著時間更新，反映基礎資料的變化，讓您一覽所有資料來源，不必使用額外的串流處理工具或自訂 ETL 工作。
- 次要存取模式：持續性 materialized view 會建立資料的替代表示法。您可以針對查詢最佳化這個表示法，使用與查詢來源資料表時不同的查閱模式。如要進一步瞭解這些模式，請參閱「建立全域次要索引」。
如要比較持續性 materialized view 與其他類型的 Bigtable 檢視區塊，請參閱「資料表和檢視區塊」。
使用計數器的時機
預先匯總資料的另一種方式，是使用匯總儲存格建立分散式計數器。
寫入匯總儲存格的內容可立即從寫入的叢集讀取。系統會在寫入資料後處理持續具體化檢視區塊，最終會與來源資料表保持一致。
請改用計數器，而非持續性 materialized view，以執行下列操作：
- 不需要篩選器，也不需要跨資料列的匯總
- 如果需要立即從寫入資料的叢集讀取資料
如要執行下列操作，請使用持續性 materialized view：
- 針對匯總查詢產生不同的金鑰
- 查看匯總資料中反映的基礎資料表變更
- 自動合併多個資料列的資料
針對下列用途，請同時使用計數器和持續性具體化檢視區塊：
- 在匯總儲存格中擷取最新指標，但保留這些指標的歷來匯總資料
- 在持續性具體化檢視中合併指標
資源佈建和效能
持續性 materialized view 的處理作業會以低優先順序的背景工作進行。因此，只要叢集大小適當，對應用程式效能和來源資料表的讀取/寫入延遲時間影響極小。
為確保連續具體化檢視中的資料保持最新狀態，建議為包含連續具體化檢視的執行個體啟用叢集的自動調度資源功能。自動調度機制會自動新增足夠的節點來處理處理負擔，並在不再需要時移除節點。這有助於確保在執行持續執行的 SQL 查詢時，有足夠的運算容量。自動調度資源功能也能確保您有足夠的節點，可處理持續具體化檢視區塊的儲存空間需求。
持續性具體化檢視表會計入每個執行個體 1,000 個資料表的限制。
儲存空間
Bigtable 會為每個持續性具體化檢視表儲存下列項目：
- 持續性 materialized view 中的資料
- 中繼儲存空間
與任何 Bigtable 資料表一樣，持續具體化檢視區塊會存在於包含該檢視區塊的執行個體中所有叢集。執行個體中的叢集必須有足夠的節點，才能儲存來源資料表和任何以該資料表為基礎的連續具體化檢視區塊。自動調度資源功能可讓叢集隨著儲存空間需求變化，擴大或縮減大小。
即使持續性具體化檢視區的儲存空間與來源資料表不同，仍須在與來源資料表相同的執行個體中建立。
持續性 materialized view 儲存空間
持續性 materialized view 包含以該檢視表為基礎的 SQL 查詢所產生的資料。也就是說，其中包含 SQL 查詢中匯總子句定義的匯總值，以及定義分組鍵的未匯總值。
中繼儲存空間
為支援持續具體化檢視區塊與來源資料表的同步作業，Bigtable 會使用中繼儲存空間來儲存資料副本，以便逐步更新持續具體化檢視區塊。
中繼儲存空間中的資料量，大致等於在來源資料表中掃描的資料量，目的是產生定義連續具體化檢視區塊的 SQL 查詢結果。舉例來說，如果查詢會匯總整個資料表的資料，Bigtable 會在中間儲存空間中保留相當於整個資料表的資料。根據特定資料列索引鍵範圍或資料欄查詢建立的連續具體化檢視區塊，只會在中間儲存空間保留這些資料列或資料欄。
中繼儲存空間會在持續性 materialized view 的生命週期內保留，以有效支援 view 的增量更新，並將來源資料表中的刪除作業傳播至持續性 materialized view。您無法讀取中繼儲存空間中的資料。如要深入瞭解中繼儲存空間用量，請參閱「持續性 materialized view 指標」。
複製
如果執行個體使用複製功能，系統不會以複製資料表的方式複製持續性具體化檢視區塊。執行個體中的每個叢集會使用自己的來源資料表副本，獨立處理連續具體化檢視區塊。舉例來說，這表示寫入叢集 A 來源資料表的資料會複製到叢集 B 的資料表，然後複製到叢集 B 的連續具體化檢視表。
費用
使用持續性具體化檢視區塊時，不會產生資源費用。不過，建立及同步處理連續具體化檢視區需要處理和儲存作業，因此會以標準費率計費。建立持續性具體化檢視區塊後，您會發現下列項目有所增加：
- 儲存空間：系統會針對您在連續具體化檢視區塊中儲存的資料和中繼儲存空間收費。詳情請參閱「儲存空間」。
- 運算 - 持續同步處理來源資料表和持續具體化的檢視區塊需要 CPU 處理作業，叢集可能需要更多節點來處理額外的背景工作。
同時，您可能會發現來源資料表上的某些處理作業減少，例如不再對資料執行範圍掃描，以執行重複的運算和其他效率較低的查詢。您可能也不需要執行管道工作 (例如 Dataflow 或 Spark)，即可匯總來源資料並寫回 Bigtable。
如要進一步瞭解定價，請參閱 Bigtable 定價。如需有助於監控持續具體化檢視表用量的指標，請參閱「指標」。
指標
持續性 materialized view 會向 Cloud Logging 報告多項重要指標，可用於監控持續性 materialized view。
| 指標 | 說明 |
|---|---|
materialized_view/max_delay |
持續性具體化檢視表的處理延遲上限 |
materialized_view/storage |
以位元組為單位，顯示用於連續具體化檢視儲存空間的資料量 |
materialized_view/intermediate_storage |
連續具體化檢視的中間處理程序使用的資料量 (以位元組為單位) |
table/materialized_view_intermediate_storage |
這個資料表上定義的連續具體化檢視區間處理所用的資料量 |
materialized_view/user_errors |
持續具體化檢視表的使用者資料錯誤數。 使用者錯誤會導致資料無法傳播至檢視區塊。 |
materialized_view/system_errors |
系統針對持續性具體化檢視表發生的錯誤數 |
您也可以使用許多 Bigtable 資料表指標來監控連續具體化檢視區塊，只要以連續具體化檢視區塊 ID 取代資料表 ID 即可。具體來說，持續具體化檢視畫面會納入 CPU 指標的細目，協助您瞭解其影響。使用 Data API 的 ReadRows 方法讀取連續具體化檢視區塊時，系統會產生 Bigtable 指標，包括每秒要求數、延遲時間和輸送量。詳情請參閱「指標」。
如要開始使用 Cloud Logging，請參閱「查詢和查看記錄檔總覽」一文。
限制
- 每個資料表只能建立一個連續具體化檢視區塊。
- 建立檢視區塊時，如果未指定
_key，來源資料表中的所選欄就不得為NULL。詳情請參閱GROUP BY子句定義的資料列鍵。 - 您無法修改定義持續性具體化檢視區塊的 SQL 查詢。您必須刪除連續具體化檢視區塊，並建立新的檢視區塊來反映變更。
- 您無法建立其他持續性具體化檢視表或邏輯檢視表的持續性具體化檢視表。
- 您無法為連續具體化檢視區塊設定垃圾收集政策。所有資料保留作業都受來源資料表的垃圾收集政策控管，而來源的垃圾收集作業會自動反映在連續具體化檢視區塊中。