云计算设计模式(十四)——实体化视图模式

简介: 云计算设计模式(十四)——实体化视图模式 产生过在一个或多个数据存储中的数据预填充的观点时,数据被格式化以不利于所需的查询操作的一种方式。这种模式可以帮助支持高效的查询和提取数据,并提高应用程序的性能。

云计算设计模式(十四)——实体化视图模式


产生一个或多个数据存储中的数据预填充的观点时,数据被格式化以不利于所需的查询操作的一种方式。这种模式可以帮助支持高效的查询和提取数据并提高应用程序的性能

背景和问题


何时存储数据时,优先级为开发者和数据管理员经常集中在如何将数据存储,而不是它是如何读出。所选择的存储格式通常是密切相关的数据用于管理数据的大小和数据的完整性,并且使用的那种存储要求的格式。例如,使用的NoSQL文献商店,该数据通常被表示为一系列的聚集体,其每一个包含了所有信息,该实体

然而,这可能对查询产生负面影响。当查询需要一些实体,如订单几个客户没有所有顺序的信息的汇总数据的一个子集,它必须提取所有的相关实体数据,以获得所需的信息。

解决方案


以支持高效的查询,一个常见的解决方案是生成预先,即物化数据最适合所要求的结果的格式的图。其中源数据不是一个格式适合于查询,在那里产生一个合适的查询中的实体化视图模式描述产生数据预先填充的观点环境中是困难的,或者其中的查询性能差,由于该数据性质数据存储区。

这些实例化视图其中只包含一个查询所需的数据以便应用程序能够快速获得他们需要的信息除了连接表组合的数据实体,物化视图可以包括计算列数据项的指定作为查询的一部分的当前值组合值或数据项执行的转换的结果,和值。物化视图甚至可以就某一个单一的查询优化。

关键的一点是,一个实体化视图,它包含的数据完全是一次性的,因为它可以完全从源数据存储重建。实例化视图不能直接更新的应用程序,因此它实际上是一个专门的缓存。

何时该视图更改源数据,视图必须被更新以包括新的信息这可以在适当的日程自动发生在系统检测到变化到原始数据的时候其他情况下,可能需要手动重新生成视图

图1示出如何实体化视图图案可能被使用的例子

图1  - 实体化视图模式

问题和注意事项


在决定如何实现这个模式时,请考虑以下几点
•考虑如何以及何时该视图将被更新理想的情况下,将被再生响应于一个事件,指示改变到所述数据,尽管在某些情况下,这可能导致过度的开销,如果源数据发生急剧的变化或者,考虑使用计划任务外部触发手动操作来启动该视图再生。
在某些系统中使用事件采购图案保持修改的数据事件存储区,例如,实体化视图可能是必要的通过检查所有事件,以确定当前状态预先填充的观点可以得到事件存储信息的唯一方式。使用事件采购其它情况下,有必要测量的优点是物化视图可以提供物化视图往往是专门针对一个少数的查询如果许多查询必须被使用,维护实例化视图可能会导致不可接受的存储容量的要求和存储成本
生成视图和更新视图,如果这发生在一个日程表考虑数据一致性的影响。如果源数据发生了变化,生成视图该视图中的数据的复制可能会与原来的数据完全一致。
•考虑在那里你将存储视图。认为不必位于同一商店或分区的原始数据它可能是几个不同的分区合并的一个子集。
如果视图短暂的,仅仅是用来通过反映该数据的当前状态来提高查询性能提高扩展性,可被存储在高速缓存中或者一个较不可靠的位置可以的,如果失去了重建。
当定义一个实体化视图中,在数据项或列的基础上计算的或现有的数据项的转换视图在查询传递的值或者对这些值,其中,这是适当的组合发挥其最大价值
存储机制支持它考虑索引实体化视图,以进一步提高性能。大多数关系型数据库支持索引意见因为这样做是基于Apache Hadoop的大数据解决方案

何时使用这个模式


这种模式非常适合于
•创建实例化视图以上数据是难以直接查询,或者查询必须以提取存储在归一化半结构化或非结构化的方式数据非常复杂
•创建临时视图,可以显着提高查询性能可直接充当UI源视图或数据传输对象DTO的进行报告进行显示。
支持偶尔连接断开连接的情况,其中连接到数据存储并不总是可用的该视图可能这种情况下被本地缓存
•简化查询和不需要源数据格式知识的方式曝光数据用于实验例如,通过一个或多个数据库NoSQL的存储的一个或多个结构域结合不同的表,然后格式化数据,以满足它的最终用途
提供访问源数据的特定子集,出于安全隐私原因不应该是一般访问,公开进行修改或者完全暴露给用户。
使用基于他们的个人能力不同的数据存储弥合脱节例如通过使用存储中是有效率的用于写入作为基准数据存储,能提供良好的查询读取性能保持实例化视图的关系数据库。

这种模式可能不适合下列情况
•源数据简单,便于查询
•源数据非常迅速的变化,或者可以在不使用视图来访问。创建视图处理开销可能会避免在这些情况下
一致性是一个高优先级的意见可能并不总是与原始数据完全一致。

例子


图2示出了使用实体化视图模式的一个例子。在订单订单项数据并在微软的Azure存储帐户单独的分区的客户相结合,生成包含电子类别中的每个产品销售总额的视图客户是谁的采购数量的计数在一起每个项目

图2 - 使用实体化视图模式产生销售的总结


创建这个实例化视图需要复杂的查询。然而,通过将查询结果作为实体化视图用户可以轻松获得的结果和直接使用它们,或将其纳入另一个查询观点很可能在一个报告系统或仪表板中使用,所以可以更新计划的基础上,如每周一次

注意:

虽然这个例子使用的Azure表存储许多关系数据库管理系统还提供了实例化视图的原生支持

本文翻译自MSDN:http://msdn.microsoft.com/en-us/library/dn589782.aspx

目录
打赏
0
0
0
0
20
分享
相关文章
设计模式:工厂方法模式(Factory Method)
工厂方法模式是一种创建型设计模式,通过将对象的创建延迟到子类实现解耦。其核心是抽象工厂声明工厂方法返回抽象产品,具体工厂重写该方法返回具体产品实例。适用于动态扩展产品类型、复杂创建逻辑和框架设计等场景,如日志记录器、数据库连接池等。优点包括符合开闭原则、解耦客户端与具体产品;缺点是可能增加类数量和复杂度。典型应用如Java集合框架、Spring BeanFactory等。
「全网最细 + 实战源码案例」设计模式——生成器模式
生成器模式(Builder Pattern)是一种创建型设计模式,用于分步骤构建复杂对象。它允许用户通过控制对象构造的过程,定制对象的组成部分,而无需直接实例化细节。该模式特别适合构建具有多种配置的复杂对象。其结构包括抽象建造者、具体建造者、指挥者和产品角色。适用于需要创建复杂对象且对象由多个部分组成、构造过程需对外隐藏或分离表示与构造的场景。优点在于更好的控制、代码复用和解耦性;缺点是增加复杂性和不适合简单对象。实现时需定义建造者接口、具体建造者类、指挥者类及产品类。链式调用是常见应用方式之一。
59 12
|
2月前
|
「全网最细 + 实战源码案例」设计模式——模式扩展(配置工厂)
该设计通过配置文件和反射机制动态选择具体工厂,减少硬编码依赖,提升系统灵活性和扩展性。配置文件解耦、反射创建对象,新增产品族无需修改客户端代码。示例中,`CoffeeFactory`类加载配置文件并使用反射生成咖啡对象,客户端调用时只需指定名称即可获取对应产品实例。
90 40
「全网最细 + 实战源码案例」设计模式——工厂方法模式
简单工厂模式是一种创建型设计模式,通过一个工厂类根据传入参数创建不同类型的产品对象,也称“静态工厂方法”模式。其结构包括工厂类、产品接口和具体产品类。适用于创建对象种类较少且调用者无需关心创建细节的场景。优点是封装性强、代码复用性好;缺点是扩展性差,增加新产品时需修改工厂类代码,违反开闭原则。
56 15
「全网最细 + 实战源码案例」设计模式——简单工厂模式
简单工厂模式是一种创建型设计模式,通过工厂类根据传入参数创建不同类型的对象,也称“静态工厂方法”模式。其结构包括工厂类、产品接口和具体产品类。优点是封装性强、代码复用性好;缺点是扩展性差,增加新产品时需修改工厂类代码,违反开闭原则。适用于对象种类较少且调用者无需关心创建细节的场景。
64 19
前端必须掌握的设计模式——模板模式
模板模式(Template Pattern)是一种行为型设计模式,父类定义固定流程和步骤顺序,子类通过继承并重写特定方法实现具体步骤。适用于具有固定结构或流程的场景,如组装汽车、包装礼物等。举例来说,公司年会节目征集时,蜘蛛侠定义了歌曲的四个步骤:前奏、主歌、副歌、结尾。金刚狼和绿巨人根据此模板设计各自的表演内容。通过抽象类定义通用逻辑,子类实现个性化行为,从而减少重复代码。模板模式还支持钩子方法,允许跳过某些步骤,增加灵活性。
158 11
2024.11|云计算行业的商业模式创新方法及实践
截至2024年,全球云计算行业迈入全新阶段,从IaaS到大规模AI模型平台,技术与商业模式不断创新。本文分析全球最新技术进展,探讨云计算商业模式创新策略与实践,解析云服务厂商如何通过技术革新实现价值最大化,推动企业数字化与智能化转型。重点讨论AI与云计算的深度融合、边缘计算与去中心化发展、平台化与生态系统建设,以及数据安全与绿色云计算等关键议题。
227 30
Kotlin教程笔记(51) - 改良设计模式 - 构建者模式
Kotlin教程笔记(51) - 改良设计模式 - 构建者模式
68 1
Kotlin教程笔记(51) - 改良设计模式 - 构建者模式
Kotlin教程笔记(51) - 改良设计模式 - 构建者模式
AI助理

你好,我是AI助理

可以解答问题、推荐解决方案等