產(chǎn)生過在一個或多個數(shù)據(jù)存儲中的數(shù)據(jù)預(yù)填充的觀點時，數(shù)據(jù)被格式化以不利于所需的查詢操作的一種方式。這種模式可以幫助支持高效的查詢和提取數(shù)據(jù)，并提高應(yīng)用程序的性能。

背景和問題

何時存儲數(shù)據(jù)時，優(yōu)先級為開發(fā)者和數(shù)據(jù)管理員經(jīng)常集中在如何將數(shù)據(jù)存儲，而不是它是如何讀出。所選擇的存儲格式通常是密切相關(guān)的數(shù)據(jù)，用于管理數(shù)據(jù)的大小和數(shù)據(jù)的完整性，并且在使用的那種存儲的要求的格式。例如，使用的 NoSQL 文獻商店時，該數(shù)據(jù)通常被表示為一系列的聚集體，其每一個包含了所有的信息，該實體。

然而，這可能對查詢產(chǎn)生負(fù)面影響。當(dāng)查詢需要從一些實體，如訂單的幾個客戶沒有所有的順序的信息的匯總的數(shù)據(jù)的一個子集，它必須提取所有的相關(guān)實體的數(shù)據(jù)，以獲得所需的信息。

解決方案

以支持高效的查詢，一個常見的解決方案是生成，預(yù)先，即物化數(shù)據(jù)中最適合于所要求的結(jié)果集的格式的圖。其中源數(shù)據(jù)不是一個格式適合于查詢，在那里產(chǎn)生一個合適的查詢中的實體化視圖模式描述產(chǎn)生數(shù)據(jù)的預(yù)先填充的觀點在環(huán)境中是困難的，或者其中的查詢性能差，由于該數(shù)據(jù)或該性質(zhì)數(shù)據(jù)存儲區(qū)。

這些實例化視圖，其中只包含一個查詢所需的數(shù)據(jù)，以便應(yīng)用程序能夠快速獲得他們需要的信息。除了連接表或組合的數(shù)據(jù)實體，物化視圖可以包括計算列或數(shù)據(jù)項的指定作為查詢的一部分的當(dāng)前值，組合值或?qū)?shù)據(jù)項執(zhí)行的轉(zhuǎn)換的結(jié)果，和值。物化視圖甚至可以就某一個單一的查詢優(yōu)化。

關(guān)鍵的一點是，一個實體化視圖，它包含的數(shù)據(jù)完全是一次性的，因為它可以完全從源數(shù)據(jù)存儲重建。實例化視圖是不能直接更新的應(yīng)用程序，因此它實際上是一個專門的緩存。

何時該視圖更改源數(shù)據(jù)，視圖必須被更新以包括新的信息。這可以在適當(dāng)?shù)娜粘套詣影l(fā)生，或在系統(tǒng)檢測到變化到原始數(shù)據(jù)的時候。在其他情況下，可能需要手動重新生成視圖。

圖1示出如何實體化視圖圖案可能被使用的例子。

http://wiki.jikexueyuan.com/project/cloud-design-patterns/images/mvm.png" alt="" />

圖1 - 實體化視圖模式

問題和注意事項

在決定如何實現(xiàn)這個模式時，請考慮以下幾點：

• 考慮如何以及何時該視圖將被更新。理想的情況下，將被再生響應(yīng)于一個事件，指示改變到所述源數(shù)據(jù)，盡管在某些情況下，這可能導(dǎo)致過度的開銷，如果源數(shù)據(jù)發(fā)生急劇的變化?；蛘?，考慮使用計劃任務(wù)，外部觸發(fā)或手動操作來啟動該視圖的再生。
• 在某些系統(tǒng)中，使用事件采購圖案保持僅修改的數(shù)據(jù)的事件存儲區(qū)時，例如，實體化視圖可能是必要的。通過檢查所有事件，以確定當(dāng)前狀態(tài)預(yù)先填充的觀點可以得到從事件存儲信息的唯一方式。在使用事件采購時比其它情況下，有必要測量的優(yōu)點是物化視圖可以提供。物化視圖往往是專門針對一個或少數(shù)的查詢。如果許多查詢必須被使用，維護實例化視圖可能會導(dǎo)致不可接受的存儲容量的要求和存儲成本。
• 生成的視圖時，和更新視圖時，如果這發(fā)生在一個日程表考慮數(shù)據(jù)一致性的影響。如果源數(shù)據(jù)發(fā)生了變化時，生成的視圖時的點，在該視圖中的數(shù)據(jù)的復(fù)制可能會與原來的數(shù)據(jù)完全一致。
• 考慮在那里你將存儲的視圖。認(rèn)為不必位于同一商店或分區(qū)的原始數(shù)據(jù)。它可能是從幾個不同的分區(qū)合并的一個子集。
• 如果視圖是短暫的，僅僅是用來通過反映該數(shù)據(jù)的當(dāng)前狀態(tài)來提高查詢性能，或提高擴展性，它可被存儲在高速緩存中或者在一個較不可靠的位置。它可以的，如果失去了重建。
• 當(dāng)定義一個實體化視圖中，在數(shù)據(jù)項或列的基礎(chǔ)上計算的或現(xiàn)有的數(shù)據(jù)項的轉(zhuǎn)換的視圖，在查詢傳遞的值，或者對這些值，其中，這是適當(dāng)?shù)慕M合發(fā)揮其最大價值。
• 凡存儲機制支持它，考慮索引實體化視圖，以進一步提高性能。大多數(shù)關(guān)系型數(shù)據(jù)庫支持索引的意見，因為這樣做是基于Apache Hadoop的大數(shù)據(jù)解決方案。

何時使用這個模式

這種模式非常適合于：

• 創(chuàng)建實例化視圖以上數(shù)據(jù)是難以直接查詢，或者查詢必須以提取存儲在歸一化，半結(jié)構(gòu)化或非結(jié)構(gòu)化的方式數(shù)據(jù)非常復(fù)雜。
• 創(chuàng)建臨時視圖，可以顯著提高查詢性能，或可直接充當(dāng)UI源視圖或數(shù)據(jù)傳輸對象（DTO 的），進行報告，或進行顯示。
• 支持偶爾連接或斷開連接的情況，其中連接到數(shù)據(jù)存儲并不總是可用的。該視圖可能在這種情況下被本地緩存。
• 簡化查詢和在不需要源數(shù)據(jù)格式的知識的方式曝光數(shù)據(jù)用于實驗。例如，通過在一個或多個數(shù)據(jù)庫，或在 NoSQL 的存儲的一個或多個結(jié)構(gòu)域結(jié)合不同的表，然后格式化的數(shù)據(jù)，以滿足它的最終用途。
• 提供訪問源數(shù)據(jù)的特定子集，出于安全或隱私原因，不應(yīng)該是一般訪問，公開進行修改，或者完全暴露給用戶。
• 使用基于他們的個人能力不同的數(shù)據(jù)存儲在彌合脫節(jié)。例如，通過使用云存儲中是有效率的用于寫入作為基準(zhǔn)數(shù)據(jù)存儲，并能提供良好的查詢和讀取性能保持實例化視圖的關(guān)系數(shù)據(jù)庫。

這種模式可能不適合于下列情況：

• 源數(shù)據(jù)簡單，便于查詢。
• 源數(shù)據(jù)非常迅速的變化，或者可以在不使用視圖來訪問。中創(chuàng)建視圖處理開銷可能會避免在這些情況下。
• 一致性是一個高優(yōu)先級。的意見可能并不總是與原始數(shù)據(jù)完全一致。

例子

圖2示出了使用實體化視圖模式的一個例子。在訂單，訂單項數(shù)據(jù)，并在微軟的Azure存儲帳戶單獨的分區(qū)表的客戶相結(jié)合，生成包含在電子類別中的每個產(chǎn)品銷售總額的視圖，客戶是誰的采購數(shù)量的計數(shù)在一起每個項目。

http://wiki.jikexueyuan.com/project/cloud-design-patterns/images/mvm1.png" alt="" />

圖2 - 使用實體化視圖模式產(chǎn)生銷售的總結(jié)

創(chuàng)建這個實例化視圖需要復(fù)雜的查詢。然而，通過將查詢結(jié)果作為實體化視圖，用戶可以輕松獲得的結(jié)果和直接使用它們，或?qū)⑵浼{入另一個查詢。觀點很可能在一個報告系統(tǒng)或儀表板中使用，所以可以更新計劃的基礎(chǔ)上，如每周一次。

注意： 雖然這個例子使用的 Azure 表存儲，許多關(guān)系數(shù)據(jù)庫管理系統(tǒng)還提供了實例化視圖的原生支持。