具體化檢視

  • 發行項

具體化檢視會對來源資料表或另一個具體化檢視公開「彙總」查詢。

具體化檢視一律會傳回彙總查詢的最新結果 (一律是全新的)。 查詢具體化檢視的效能高於直接對來源資料表執行彙總。

注意

為何使用具體化檢視？

藉由投資資源 (數據記憶體，背景 CPU 循環) 來具體化常用匯總檢視，即可獲得下列優點：

  • 效能改善：查詢具體化檢視的效能通常優於查詢相同彙總函數的來源資料表。

  • 時效性：具體化檢視查詢一律會傳回最新結果，並且不受最後一次執行具體化的時間影響。 此查詢會合併檢視的具體化組件與來源資料表中尚未具體化的記錄 (delta 組件)，並且一律提供最新結果。

  • 降低成本：查詢具體化檢視所使用的叢集資源會少於對來源資料表進行彙總所使用的資源。 如果只需要彙總，則可以減少來源資料表的保留原則。 此設定可減少來源資料表的熱快取成本。

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

具體化檢視的運作方式

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

  • 具體化部分 - 保存源數據表匯總記錄的數據表，已經處理過。 此資料表一律會將每個彙總的群組依據組合保留單一記錄。
  • 差異 - 來源資料表中尚未處理的新擷取記錄。

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

具體化檢視查詢

有兩種方法可以查詢具體化檢視：

  • 查詢整個檢視：當您依名稱來查詢具體化檢視時 (與查詢資料表類似)，具體化檢視查詢會「合併」檢視的具體化組件與來源資料表中尚未具體化的記錄 (delta)。

    • 查詢具體化檢視一律會根據擷取至源數據表的所有記錄傳回最新的結果。 如需具體化檢視中「具體化」與「非具體化」組件的詳細資訊，請參閱具體化檢視的運作方式。
    • 此選項可能無法以最佳方式執行，因為它需要在查詢期間具體化 delta 部分。 在此情況下，效能取決於檢視存留期以及查詢中所套用的篩選。 具體化檢視查詢最佳化工具小節所含的方法可能可以改善查詢整個檢視時的查詢效能。

  • 只查詢具體化組件：另一種查詢檢視的方法是使用 materialized_view() 函數。 此選項支援只查詢檢視的具體化組件，同時指定使用者可容忍的延遲上限。

    • 此選項無法保證可傳回最新記錄，但其效能應該一律會高於查詢整個檢視的效能。
    • 此函數適用於您願意犧牲一些效能時效性的案例，例如針對遙測儀表板。

提示

具體化部分的查詢一律會比查詢整個檢視更好。 適用於您的使用案例時，請一律使用 materialized_view() 函數。

  • 具體化檢視會參與跨叢集或跨資料庫查詢，但不會併入萬用字元聯集或搜尋。

    • 下列範例全 都包含 名稱的具體 ViewName化檢視：
    cluster('cluster1').database('db').ViewName
cluster('cluster1').database('*').ViewName
database('*').ViewName
database('DB*').ViewName
database('*').materialized_view('ViewName')
database('DB*').materialized_view('ViewName')
    • 下列範例 不包含 具體化檢視中的記錄：
    cluster('cluster1').database('db').*
database('*').View*
search in (*)
search *

具體化檢視查詢最佳化工具

查詢整個檢視時，會在查詢期間合併具體化組件與 delta。 這包括彙總 delta，以及將其與具體化組件聯結。

  • 如果查詢包含具體化檢視查詢索引鍵的群組篩選，查詢整個檢視會執行得更好。 在 .create materialized-view 效能提示小節中，根據您的查詢模式來查看更多有關如何建立具體化檢視的提示。
  • 查詢優化器會選擇預期可改善查詢效能的摘要/聯結策略。 例如，是否隨機播放查詢的決策是以 delta 組件的記錄數目為基礎。 下列用戶端要求屬性可讓您控制套用的最佳化。 您可以使用具體化檢視查詢來測試這些屬性，並評估其對查詢效能的影響。
用戶端要求屬性名稱 類型 Description
materialized_view_query_optimization_costbased_enabled bool 如果設定為 false，則會在具體化檢視查詢中停用總結/聯結最佳化。 使用預設策略。 預設為 true。
materialized_view_shuffle dynamic 強制隨機執行具體化檢視查詢，並選擇性地提供作為隨機執行依據的特定索引鍵。 請參閱下面的範例。

範例

  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

效能考量

可能影響具體化檢視健康情況的主要因素為：

  • 叢集資源：與叢集上執行的任何其他程序相同，具體化檢視會使用叢集的資源 (CPU、記憶體)。 如果叢集已超載，則在其中新增具體化檢視可能會導致叢集的效能降低。 使用叢集健康情況計量來監視叢集的健康情況。 最佳化的自動調整目前不會將具體化檢視健康情況列為自動調整規則的考量。

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

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

  • 叢集中的具體化檢視數目：上述考量適用於叢集中所定義的每個個別具體化檢視。 每個檢視都會取用自己的資源，而且許多檢視會彼此競爭可用的資源。 雖然叢集中的具體化檢視數目沒有硬式編碼限制，但是定義太多數目時，叢集可能無法處理所有具體化檢視。 如果叢集中有多個具體化檢視，則可以調整容量原則。 增加原則中的 ClusterMinimumConcurrentOperations 值，以同時執行更多具體化檢視。

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

具體化檢視對具體化檢視

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

提示

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

相關內容