Materialized View模式

Materialized-View模式是在要求數據格式不利於查詢操作的情況下，根據多個數據倉庫的數據生成預生成的視圖的一種模式。這種模式可以幫助支持高效的查詢和數據提取，提高應用程序的性能。

問題

在存儲數據時，開發人員和數據管理員考慮的第一優先級通常集中在如何存儲數據，而不是如何讀取數據。所選擇的存儲格式通常與數據的格式、管理數據大小和數據完整性的要求，以及存儲的類型密切相關。例如，使用NoSQL存儲文檔時，數據通常被表示爲多個元素的聚合結構，其中包含了所有的實體的信息。

然而，這可能會對查詢產生負面影響。當一個查詢需要從多個實體的數據獲取他們的子集的時候，如需要一些客戶的訂單摘要信息，但是不需要所有的訂單細節，查詢仍然需要提取相關實體的所有數據，才能獲得所需的信息。

解決方法

爲了支持高效的查詢，常見的解決方法是提前生成所需要的數據格式的結果集。Materialized-View模式描述了在那種源數據格式不適用於查詢的數據格式，或是生成合適的查詢比較困難，或是查詢性能低下的的環境中，生成在預填充的視圖。

這些Materialized視圖只包含查詢所需的數據，允許應用程序快速獲取所需信息。除了Join表或組合數據實體外，Materialized視圖還可以計算列或數據項的當前值、數據項的值組合或執行轉換的結果，以及指定爲查詢的一部分的值等等。一個Materialized視圖甚至可以僅針對一個查詢進行優化。

Materialized視圖的關鍵就在於它所包含的數據完全是自由使用的，因爲它可以完全從源數據存儲重建。一個Materialized視圖永遠不會被應用程序直接更新，所以它實際上是一種特殊的緩存。

當視圖的源數據更改時，視圖必須更新以包含新信息。更新操作可以通過定時任務來調度，或當系統檢測到原始數據的變化時觸發。在其他情況下，可能需要手動重新生成視圖。

圖1.Materialized-View模式

問題和實現Materialized-View模式需要考慮的問題

在決定如何實現這個模式時，考慮以下幾點：

• 考慮如何以及何時更新視圖。理想情況下，每次生源數據發生修改的時候，都會有事件來重新生成Materialized視圖。但是在某些情況下，如果源數據迅速變化,可能會導致過多的開銷。也可以考慮使用定時任務、外部觸發器或手動操作來啓動視圖的再生。
• 在某些系統中，如使用Event-Sourcing模式來維護僅修改數據的事件的存儲時，可能需要Materialized視圖。通過檢查所有事件來確定當前的狀態來預填充視圖，可能是事件存儲中獲取信息的唯一途徑。在其他情況下，使用Event-Sourcing時，有必要權衡Materialized-View的優點。Materialized視圖往往是專門針對一個或少數查詢。如果必須使用許多查詢，維護物化視圖可能會導致不可接受的存儲容量要求和存儲成本。
• 當使用定時任務更新視圖時，需要考慮數據一致性的影響。如果源數據在生成視圖時發生更改，則視圖中的數據的副本可能與原始數據不完全一致。
• 考慮存儲視圖的地方。該視圖不必位於與原始數據相同的存儲區或分區中。它可以是從幾個不同的分區合併的子集。
• 如果視圖是短暫的，僅用於通過反映數據的當前狀態來提高查詢性能，或者提高可擴展性的情況下，可以將視圖存儲在高速緩存或者不可靠存儲上。就算視圖丟失也可以根據數據源進行重建。
• 在定義Materialized視圖時，通過將數據項或列添加到基於現有數據項的計算或轉換、在查詢中傳遞的值或在此適當的值的組合上，將數據項或列添加到視圖中，從而最大化其值。
• 如果存儲機制支持Materialized視圖，可以考慮給Materialized視圖加索引以進一步最大化性能。大多數關係數據庫支持索引視圖，如基於Apache Hadoop的大數據解決方案。

何時使用Materialized View模式

Materialized-View模式非常適合以下的一些場景：

• 在需求數據難以直接查詢，或者查詢必須非常複雜，以便以標準化、半結構化或非結構化方式存儲數據的時候，可以考慮創建Materialized視圖來優化。
• 當創建臨時視圖，可以極大地提高查詢性能，或可直接作爲源視圖或數據傳輸對象（DTOs）的用戶界面、報告，或顯示的時候，也可以使用Materialized-View模式。
• 需要支持偶爾連接或斷開連接的情況，或者數據存儲並不總是可用的情況。在這種情況下，可以使用本地所緩存的視圖數據。
• 在需要簡化查詢，並且不需要了解全部數據細節的時候，可以考慮使用Materialized-View模式。例如，通過Join不同的表中的一個或多個數據庫，或一個或多個域的NoSQL存儲，然後格式化數據以適應其最終用途。
• 需要提供對源數據的特定子集的訪問，出於安全或隱私原因，一般不可訪問、修改或讓數據完全暴露於用戶。
• 很多情況下需要根據不同數據倉庫的特性來選擇數據存儲，需要開發者對不同的數據存儲進行橋接的時候使用Materialized-View模式十分合適。例如，通過使用作爲參考數據存儲的高效的雲存儲，以及提供良好查詢和讀取性能的關係數據庫來保存Materialized視圖。

Materialized-View模式在如下場景不適合:

• 源數據很簡單或者很容易請求的情況下。
• 源數據變化非常快，或者可以在不使用視圖的情況下訪問的時候。在這些情況下，創建視圖的處理開銷可能是可以避免的。
• 一致性是高優先級需求的情況下，使用Materialized-View並不合適。視圖並不總是與原始數據完全一致的。

使用舉例

圖2展示了一個使用Materialized-View模式的例子。在Windows Azure存儲賬戶中，Order，OrderItem以及Customer表中不同分區的數據組合了一個視圖，生成了一個包含了每種電子產品總銷量的數據，同時包含了購買的客戶的數量。

圖2.使用Materialized-View模式生成銷售摘要

創建滿足這樣需求的視圖需要複雜的查詢。然而，通過將查詢結果顯示爲Materialized視圖，用戶可以很容易地得到結果並直接使用它們或將它們合併到另一個查詢中。該視圖可能被用於報表系統或儀表板，還可以在預定的基礎上如每週更新。

雖然這個例子利用Windows Azure表存儲，許多關係型數據庫管理系統也對Materialized視圖提供了本地支持。

相關的其它模式

在考慮實現Materialized-View模式的時候，也可以參考如下其它模式：

• Data Consistency Primer.在使用Materialized-View模式的時候，一個重要的需要考慮的問題就是一致性的問題。隨着數據的變化，可能無法實時修改Materialized視圖所展示的數據的，只能考慮最終一致性的方式。Data Consistency Primer總結了很多關於保證分佈式數據一致性的內容，也同時描述了不同的一致性模型的實現代價。
• CQRS模式.在CQRS模式中，所有的更新操作都是以事件的方式執行的，開發者可以通過以響應事件的方式來更新Materialized視圖。
• Event-Sourcing模式. 開發者可以配合CQRS模式和Event-Sourcing模式一起使用來更新Materialized視圖中的數據。當Materialized視圖所使用的數據源中的數據發生了更新時，系統可以發起事件，並將事件存儲到事件存儲倉庫中。
• Index-Table Pattern.在Materialized視圖中的數據通常來說是通過主鍵來組織的，但是請求很多時候可能通過視圖的其它域來進行檢索。開發者可以使用Index-Table模式來爲那些不支持二級索引的數據倉庫創建二級索引。