具體化檢視

適用於： ✅Microsoft網狀架構✅Azure 數據總管

具體化檢視會在源數據表或另一個具體化檢視上公開匯總查詢。

具體化檢視一律會傳回匯總查詢的最新結果（一律為最新）。 查詢具體化檢視 比直接在源數據表上執行匯總更有效能。

注意

• 若要決定具體化檢視是否適合您，請檢閱具體化檢視 使用案例。
• 具體化檢視有一些 限制。 使用此功能之前，請先 檢閱效能考慮。
• 請考慮在適當時使用 更新原則 。 如需詳細資訊，請參閱 具體化檢視與更新原則。
• 根據監視具體化檢視中 的建議，監視具體化檢視的健康情況。

為什麼要使用具體化檢視？

藉由投資資源（數據記憶體、背景 CPU 週期）來具體化常用匯總檢視，您會獲得下列優點：

• 效能改善： 查詢具體化檢視通常比查詢源數據表以取得相同聚合函數的效能更好。

• 新鮮度： 具體化檢視查詢一律會傳回最新的結果，與上次進行具體化的時間無關。 查詢結合了檢視的具體化部分與源數據表中尚未具體化的記錄（部分 delta ），一律提供最新的結果。

• 成本降低：查詢具體化檢視會耗用比對源數據表執行匯總更少的資源。 只要需要匯總，就可以減少源數據表的保留原則。 此設定可降低源數據表的經常性快取成本。

如需範例使用案例，請參閱 具體化檢視使用案例。

具體化檢視的運作方式

具體化檢視是由兩個元件所組成：

• 具體化元件 - 保存源數據表匯總記錄的數據表，已處理。 此數據表一律會根據匯總的群組組合保留單一記錄。
• 差異 - 尚未處理之源數據表中新擷取的記錄。

查詢具體化檢視會結合具體化元件與差異部分，提供匯總查詢的最新結果。 離線具體化程式會從 差異 擷取新記錄到具體化數據表，並更新現有的記錄。 如果差異與具體化部分之間的交集很大，而且許多記錄都需要更新，這可能會對具體化程式產生負面影響。 請參閱 監視具體化檢視 ，以瞭解如何針對這類情況進行疑難解答。

具體化檢視查詢

有 2 種方式可以查詢具體化檢視：

• 查詢整個檢視：當您依其名稱查詢具體化檢視時，類似於查詢數據表，具體化檢視查詢 會 結合檢視的具體化部分與源數據表中尚未具體化的記錄（或 delta）。

  • 根據擷取至源數據表的所有記錄，查詢具體化檢視一律會傳回最新的結果。 如需具體化檢視中具體化與非具體化元件的詳細資訊，請參閱具體化檢視的運作方式。
  • 這個選項可能無法執行得最好，因為它需要在查詢期間具體化 delta 元件。 在此情況下，效能取決於檢視的存留期和查詢中套用的篩選條件。 具體化檢視查詢優化器區段包含在查詢整個檢視時改善查詢效能的可能方式。

• 僅查詢具體化部分：查詢檢視的另一種方式是使用 函 materialized_view() 式。 此選項僅支持查詢檢視的具體化部分，同時指定用戶願意容許的最大延遲。

  • 此選項不保證會傳回最新的記錄，但一律比查詢整個檢視更有效能。
  • 此函式適用於您願意為效能犧牲一些新鮮度的情況，例如遙測儀錶板。

提示

具體化元件的查詢一律會比查詢整個檢視更好。 當您的使用案例適用時，請一律使用 函 materialized_view() 式。

• 具體化檢視會參與跨 Eventhouse 或跨資料庫查詢，但不包含在通配符聯集或搜尋中。

  • 下列範例全 都包含 名稱 ViewName的具體化檢視：

  cluster("<serviceURL>").database('db').ViewName
  cluster("<serviceURL>").database('*').ViewName
  database('*').ViewName
  database('DB*').ViewName
  database('*').materialized_view('ViewName')
  database('DB*').materialized_view('ViewName')
  

  • 下列範例不包含具體化檢視中的記錄：

  cluster("<serviceURL>").database('db').*
  database('*').View*
  search in (*)
  search * 
  

具體化檢視查詢優化器

查詢整個檢視時，具體化元件會在查詢期間與 delta 結合。 這包括匯總 delta ，並將它與具體化元件聯結。

• 如果查詢包含具體化檢視查詢索引鍵的群組篩選，則查詢整個檢視的執行效能會更好。 如需有關如何根據查詢模式建立具體化檢視的更多秘訣，請參閱 .create materialized-view 效能秘訣 一節。
• 查詢優化器會選擇可改善查詢效能的摘要/聯結策略。 例如，是否 要隨機隨機 查詢的決定是以部分記錄 delta 數目為基礎。 下列 用戶端要求屬性 提供對所套用優化的某些控制權。 您可以使用具體化檢視查詢來測試這些屬性，並評估它們對查詢效能的影響。

用戶端要求屬性名稱	類型	描述
materialized_view_query_optimization_costbased_enabled	bool	如果設定為 false，則會停用具體化檢視查詢中的摘要/聯結優化。 使用預設策略。 預設值為 true。
materialized_view_shuffle	dynamic	強制隨機顯示具體化檢視查詢，且 （選擇性地） 提供要隨機顯示的特定索引鍵。 請參閱 下列範例 。

ingestion_time() 具體化檢視內容中的函式

ingestion_time（） 函式會在查詢整個檢視時，在具體化檢視的內容中使用時，傳回 Null 值。 查詢檢視的具體化部分時，傳回值取決於具體化檢視的類型：

• 在包含單arg_max()take_any()arg_min()//一匯總的具體化檢視中，等於ingestion_time()ingestion_time()源數據表中對應記錄的 。
• 在所有其他具體化檢視中，的值 ingestion_time() 大約是具體化的時間（請參閱 具體化檢視的運作方式）。

範例

1. 查詢整個檢視。 來源資料表中最新的記錄包括：

   ViewName
   

2. 只查詢檢視的具體化部分，不論上次具體化的時間為何。

   materialized_view("ViewName")
   

3. 查詢整個檢視，並提供「提示」以使用 shuffle 策略。 來源資料表中最新的記錄包括：

   • 範例 #1：根據 Id 數據行隨機顯示 （類似於使用 hint.shufflekey=Id）：

   set materialized_view_shuffle = dynamic([{"Name" : "ViewName", "Keys" : [ "Id" ] }]);
   ViewName
   

   • 範例 #2：根據所有索引鍵隨機顯示 （類似於使用 hint.strategy=shuffle）：

   set materialized_view_shuffle = dynamic([{"Name" : "ViewName" }]);
   ViewName
   

效能考量

會影響具體化檢視健康情況的主要參與者包括：

• 與具體化數據重疊： 在具體化期間，自上次具體化之後，所有擷取至源數據表的新記錄都會處理並具體化到檢視中。 新記錄與已具體化記錄之間的交集愈高，具體化檢視的效能就越差。 如果更新的記錄數目（例如，在檢視中 arg_max ）是源數據表的一小部分，具體化檢視效果最好。 如果每個具體化週期中必須更新所有或大部分具體化檢視記錄，具體化檢視可能無法正常執行。

• 擷取速率： 具體化檢視之源數據表中的數據量或擷取速率沒有硬式編碼限制。 不過，具體化檢視的建議擷取速率不超過 1-2GB/秒。較高的擷取率可能仍然表現良好。 效能取決於資料庫大小、可用的資源，以及與現有數據的交集量。

• 具體化檢視定義：具體化檢視定義必須根據最佳查詢效能的查詢最佳做法來定義。 如需詳細資訊，請參閱 建立命令效能秘訣。

具體化檢視對具體化檢視

如果來源具體化檢視是重複數據刪除檢視，則可以在另一個具體化檢視上建立具體化檢視。 具體來說，來源具體化檢視的匯總必須是 take_any(*) 重複數據刪除源記錄。 第二個具體化檢視可以使用任何 支援的聚合函數。 如需如何透過具體化檢視建立具體化檢視的特定資訊，請參閱 .create materialized-view 命令。

提示

查詢透過另一個具體化檢視所定義的具體化檢視時，建議只使用 materialized_view() 函式查詢具體化元件。 當這兩個檢視未完全具體化時，查詢整個檢視並不高效能。 如需詳細資訊，請參閱 具體化檢視查詢。

相關內容

• 具體化檢視原則
• 具體化檢視限制和已知問題
• 具體化檢視使用案例
• 監視具體化檢視
• .create materialized view
• .alter materialized-view
• {.disable | .enable} materialized-view