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模式來爲那些不支持二級索引的數據倉庫建立二級索引。