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模式来为那些不支持二级索引的数据仓库建立二级索引。