具體化檢視模式

當數據不適合針對必要的查詢作業格式化時，針對一或多個數據存放區中的數據產生預先填入的檢視。 這有助於支援有效率的查詢和數據擷取，並改善應用程式效能。

內容和問題

儲存數據時，開發人員和數據管理員的優先順序通常著重於數據的儲存方式，而不是數據的讀取方式。 選擇的儲存格式通常與數據格式、管理數據大小和數據完整性的需求，以及使用中的存放區類型密切相關。 例如，使用 NoSQL 檔存放區時，數據通常會以一系列的匯總表示，每個匯總都包含該實體的所有資訊。

不過，這可能會對查詢產生負面影響。 當查詢只需要某些實體的數據子集時，例如沒有所有訂單詳細數據的數個客戶的訂單摘要，它必須擷取相關實體的所有數據，才能取得所需的資訊。

解決方案

為了支援有效率的查詢，常見的解決方案是預先產生一個檢視，以適合所需結果集的格式具體化數據。 具體化檢視模式描述在源數據不是適合查詢格式的環境中產生預先填入的數據檢視，其中產生適當的查詢很困難，或查詢效能不佳，因為數據或數據存放區的性質。

這些具體化檢視只包含查詢所需的數據，可讓應用程式快速取得所需的資訊。 除了聯結數據表或合併數據實體之外，具體化檢視還可以包含計算結果列或數據項的目前值、結合值或對數據項執行轉換的結果，以及指定為查詢一部分的值。 具體化檢視甚至可以只針對單一查詢進行優化。

關鍵點是具體化檢視及其包含的數據是完全可處置的，因為它可以從源數據存放區完全重建。 具體化檢視永遠不會由應用程式直接更新，因此它是特製化的快取。

當檢視的源數據變更時，必須更新檢視以包含新的資訊。 您可以將此排程為自動發生，或當系統偵測到原始數據的變更時。 在某些情況下，可能需要手動重新產生檢視。 此圖顯示如何使用具體化檢視模式的範例。

問題和考量

當您決定如何實作此模式時，請考慮下列幾點：

檢視的更新方式和時機。 在理想情況下，它會重新產生以回應指出源數據變更的事件，但如果源數據快速變更，這可能會導致過多的額外負荷。 或者，請考慮使用排程的工作、外部觸發程式或手動動作來重新產生檢視。

在某些系統中，例如使用事件來源模式只維護修改數據之事件的存放區時，需要具體化檢視。 藉由檢查所有事件來判斷目前狀態，預先填入檢視可能是從事件存放區取得資訊的唯一方法。 如果您未使用事件來源，則必須考慮具體化檢視是否有用。 具體化檢視通常特別針對一個或少數查詢量身打造。 如果使用許多查詢，具體化檢視可能會導致無法接受的儲存容量需求和記憶體成本。

請考慮在產生檢視時對數據一致性的影響，以及在排程上發生此情況時更新檢視時。 如果源數據在產生檢視時變更，則檢視中的數據複本不會與原始數據完全一致。

請考慮您將儲存檢視的位置。 檢視不一定位於與原始數據相同的存放區或分割區中。 它可以是結合幾個不同數據分割的子集。

如果遺失，可以重建檢視。 因此，如果檢視是暫時性的，而且只能藉由反映數據的目前狀態來改善查詢效能，或改善延展性，它可以儲存在快取或較不可靠的位置。

定義具體化檢視時，請根據現有數據項的計算或轉換、在查詢中傳遞的值，或適當時根據這些值的組合，加入數據項或數據行，以最大化其值。

儲存機制支援的位置，請考慮編製具體化檢視的索引，以進一步提升效能。 大部分的關係資料庫都支援針對檢視編製索引，根據 Apache Hadoop 的巨量數據解決方案也一樣。

使用此模式的時機

當下列情況時，此模式很有用：

• 針對難以直接查詢的數據建立具體化檢視，或查詢必須非常複雜，才能擷取以正規化、半結構化或非結構化方式儲存的數據。
• 建立可大幅改善查詢效能的暫存檢視，或直接作為UI的來源檢視或數據傳輸物件、報告或顯示。
• 支持偶爾連線或中斷連線的案例，而數據存放區的連線不一定可供使用。 在此情況下，可以在本機快取檢視。
• 以不需要瞭解源數據格式的方式簡化查詢並公開數據以進行實驗。 例如，藉由聯結一或多個資料庫中的不同數據表，或 NoSQL 存放區中的一或多個網域，然後將數據格式化以符合其最終用途。
• 提供源數據特定子集的存取權，基於安全性或隱私權考慮，不應一般存取、開放修改或完全公開給使用者。
• 橋接不同的數據存放區，以利用其個別功能。 例如，使用能有效率寫入為參考數據存放區的雲端存放區，以及提供良好查詢和讀取效能的關係資料庫來保存具體化檢視。
• 使用微服務時，建議您將其保持鬆散結合，包括其數據記憶體。 因此，具體化檢視可協助您合併服務中的數據。 如果您的微服務架構或特定案例中不適合具體化檢視，請考慮有妥善定義的界限，使其符合 網域驅動設計 （DDD）， 並在要求時匯總其數據。

此模式在下列情況下並無用處：

• 源數據簡單且容易查詢。
• 源數據會非常快速地變更，或不需要使用檢視即可存取。 在這些情況下，您應該避免建立檢視的處理額外負荷。
• 一致性是高優先順序。 檢視可能不一定與原始數據完全一致。

工作負載設計

架構設計人員應該評估具體化檢視模式如何用於其工作負載的設計，以解決 Azure 良好架構架構支柱中涵蓋的目標和原則。 例如：

如同任何設計決策，請考慮對其他可能以此模式導入之目標的任何取捨。

範例

下圖顯示使用具體化檢視模式來產生銷售摘要的範例。 Azure 記憶體帳戶中個別分割區中 Order、OrderItem 和 Customer 資料表中的數據會合併成一個檢視，其中包含電子類別中每個產品的總銷售值，以及購買每個專案的客戶數目計數。

建立此具體化檢視需要複雜的查詢。 不過，藉由將查詢結果公開為具體化檢視，使用者可以輕鬆地取得結果，並直接使用這些結果，或將它們併入另一個查詢中。 檢視可能會用於報表系統或儀錶板，而且可以依排程更新，例如每周更新。

雖然此範例使用 Azure 數據表記憶體，但許多關係資料庫管理系統也提供具體化檢視的原生支援。

下一步

• 數據一致性入門。 具體化檢視中的摘要信息必須維持，以便反映基礎數據值。 隨著數據值變更，即時更新摘要數據可能並不實用，而您必須採用最終一致的方法。 摘要說明維護分散式數據一致性的相關問題，並描述不同一致性模型的優點和取捨。

相關資源

實作此模式時，下列模式也可能相關：

• 命令和查詢責任隔離 （CQRS） 模式。 使用 來更新具體化檢視中的資訊，方法是響應基礎數據值變更時所發生的事件。
• 事件來源模式。 與 CQRS 模式搭配使用，以在具體化檢視中維護資訊。 當具體化檢視的數據值已變更時，系統可以引發描述這些變更的事件，並將其儲存在事件存放區中。
• 索引數據表模式。 具體化檢視中的數據通常是由主鍵組織，但查詢可能需要藉由檢查其他欄位中的數據，從這個檢視擷取資訊。 用於針對不支援原生次要索引的數據存放區，針對數據集建立次要索引。