四平市住房和畅想建设局网站,厦门网络推广外包多少钱,十大新媒体平台有哪些,专业网站建设哪里有简介
官方文章的地址是 Building with Patterns: A Summary#xff0c;其中汇总了 12 种设计模式及使用场景。 上述的图表列举了 12 种设计模式及应用场景#xff0c;主要是以下这些#xff1a;
近似值模式#xff08;Approximation Pattern#xff09;属性模式#xf…简介
官方文章的地址是 Building with Patterns: A Summary其中汇总了 12 种设计模式及使用场景。 上述的图表列举了 12 种设计模式及应用场景主要是以下这些
近似值模式Approximation Pattern属性模式Attribute Pattern桶模式Bucket Pattern计算模式Computed Pattern文档版本控制模式Document Versioning Pattern扩展引用模式Extended Peference Pattern异常值模式Outlier Pattern预分配模式Preallocated Pattern多态模式Polymorphic Pattern模式版本控制模式Schema Versioning Pattern子集模式Subset Pattern树型模式Tree and Graph Pattern
近似值模式
示例描述
淘宝在往年“双十一”都会有一个销售额大屏展示当销售额小于 1 亿时可能展示的是实际的数量当销售额超过 1 亿时单位立即变成以“亿”为单位对于展示的大屏而言”亿“以下的单位这个时候并不是很重要了。
对于上述的场景如果每次几十、几百都直接去更新数据库中的实际值则更新数据库会变得非常频繁对于数据库的压力是非常大的。
实际上并不需要每次都去更新数据库我们只需要将这个实际的精确值存储在内存中使用 1 亿作为一个阈值一旦超过这个阈值就精确值更新进数据库中。
对于精度不是首要考虑因素时那么就可以使用近似值模式尤其是消耗资源时间、内存、CPU 周期非常昂贵时效果会更佳。
近似值模式就是通过减少数据的写入频率从而降低了架构的复杂度和资源开销进而提升了整体的性能与效率。
优缺点
近似值模式的优点如下
由于是近似的数据不必时时刻刻写入数据库的写操作量级更小
近似值模式的缺点如下
存储的是近似的数据无法应对需要展示精确数据的场景此模式需要在应用层实现
属性模式
示例描述
属性模式运用到了 MongoDB 多键索引的概念支持对数组中的嵌套子文档中的某个属性进行索引。
假设现在有一个关于电影的集合其中文档中会包含标题、导演、制片人、演员、上映时间等等信息对于跨地区上映的电影有可能不同地区的上映时间是不一样的。
如下展示是一条电影的文档数据 {title: Star Wars,director: George Lucas,// 不同地区有不同的上映时间release_US: ISODate(1977-05-20T01:00:0001:00),release_France: ISODate(1977-10-19T01:00:0001:00),release_Italy: ISODate(1977-10-20T01:00:0001:00),release_UK: ISODate(1977-12-27T01:00:0001:00),}
为了支持对所有上映时间做一个快速搜索也许我们需要将所有的上映时间设置为单一索引这个时候索引的数量就会变得显而易见的多。
使用属性模式我们通过将这些上映时间信息移动到一个数组中然后再对这个数组建立一个多键索引索引以实现使用一个索引替代多个类似索引的功能。
如下是修改结构后的文档数据 {title: Star Wars,director: George Lucas,// 所有的地区的上映时间都放在同一个属性内部releaseList: [{region: US,date: ISODate(1977-05-20T01:00:0001:00)},{region: France,date: ISODate(1977-10-19T01:00:0001:00)},{region: Italy,date: ISODate(1977-10-20T01:00:0001:00)},{region: UK,date: ISODate(1977-12-27T01:00:0001:00)}]}
优缺点
属性模式的优点如下
需要更少的索引查询变得更容易编写而且通常更快
桶模式
示例描述
桶模式有点类似于水平分库常见的水平分库是将一个集合按照某一个规则分布到不同的数据库上桶模式是将一个集合中的文档按照某一个规则合并起来。
假设现在有一个需要记录用户日志的需求对于用户的每一个动作都需要将其更新到 MongoDB 当中并且是记录其动作、时间。
对于这样的日志数据来说如果将每一个动作都存储成一个文档则将会占用极大的存储空间和内存。
使用桶模式的解决办法就是将一段时间的日志数据存储成一个文档再将每一个动作日志的数据存储到子文档数据中。
当需要管理流式数据的时候如时间序列、实时分析或物联网应用程序桶模式就是一个很好的解决方案。
优缺点
桶模式的优点如下
减少了集合中的文档总数提高了索引性能可以通过预聚合简化数据的访问
计算模式
示例描述
对于大型数据集每一次计算都可能会占用极大的 CPU、磁盘、内存等相关资源甚至是影响到服务器上的其他计算。
而对于需要重复计算、读取比写入多的场景计算模式提供了一种优化的思路以便降低服务器资源的占用。
拿一个电影观看总人数的例子来说明假设现在页面上需要展示观看电影的实际总人数而且这个页面会有成千上万的人访问。
虽然我们可以对电影的每一次放映都记录起观看人数但是要获取总人数则需要拿出所有的放映场次的观看人数之后计算其总和这个计算就非常耗费资源和时间。
对于只有放映场次变化之后总人数才会更新的情况实际数据库读取的次数远远大于写入的次数。 在这个场景中计算模式的思路是每一次更新放映场次数据的时候将这个放映场次的人数汇总到一个文档当中这个文档直接面向用户的查询。
优缺点
计算模式的优点如下
对于频繁的计算可以减少 CPU 的负载查询变得更容易编写而且通常更快
计算模式的缺点如下
识别出需要使用此模式的的场景可能比较困难除非必要请勿过度使用此模式
文档版本控制模式
示例描述
文档版本控制模式在高度规范化的行业中非常有用这些行业会要求数据的特定时间点版本。
假设现在有一个博客系统其中有一个记录每次编辑博客文章历史的功能这样的功能就能应用文档版本控制模式。
假设我们将所有的文章历史都存储在同一个集合当中则需要考虑大部分与文章相关的功能都要过滤掉历史版本、版本越多则集合文档数量越多等等问题。
文档版本控制模式的想法是文档中需要记录一个文档的版本将最新的文档保存在一个 current 集合中而那些旧版本的文档保存在 history 集合中。
为了最大化利用文档版本控制模式的优势通常会假设数据访问模式尽量符合以下要求
每个文档不会有太多的修订版本需要做版本控制的文档不会太多大多数的查询都是基于文档的最新版本
优缺点
文档版本控制模式的优点如下
容易实现对现有系统的影响小在最新版本上进行请求时没有性能上的影响
文档版本控制模式的缺点如下
写操作的数量会翻倍请求需要被定位到正确的集合
扩展引用模式
示例描述
MongoDB 是一个不需要提前建模的 NoSQL当不同文档、不同集合之间存在关系的时候通常会有嵌入和引用两种方式。
嵌入就是将文档数据嵌入到引用此数据的文档中访问时直接访问这一次文档即可引用就是只在文档中引用另一个文档的标识访问时需要访问两次数据库才能拿到完整的数据。
扩展引用模式是指仅复制经常访问并且不经常更改的字段而不是复制所有的数据减少信息的连接以提高性能。 这张图的场景是客户和订单是 1 对 N 的关系通常查询订单列表的时候需要展示客户的一些信息我们就需要考虑是否将客户的信息冗余进订单信息中。
扩展引用模式认为客户的名称和地址是不常做更新的可以直接将这些信息冗余进订单表中以达到减少两个集合连接查询的要求。
优缺点
扩展引用模式的优点如下
当有大量的 JOIN 操作时可以提升性能读操作会更快并且可以减少 JOIN 操作的数量
扩展引用模式的缺点如下
修改冗余的这部分数据会比较复杂
异常值模式
示例描述
顾名思义异常值模式主要用以解决超出应用程序正常模式的少数异常查询情况。
假设你正在搭建一个出售图书的电子商务网站现在需要记录一本书都有哪些用户购买过一个常见的做法的是将购买的用户标识存储在图书文档中如下展示 {_id: ObjectId(6392cecd4dd9624424ad025d),title: 三国演义,author: 罗贯中,purchase_customers: [user0,user1,user3,// ...]}
对于上述的文档结构大部分情况下是适用的。但是对于销量特别高的图书极可能导致图书文档的大小超过 16MB 的限制。
使用异常值模式的方式是在图书文档中添加一个字段来将其标记为异常值超过一定大小的内容可以存储在另一个文档当中在应用程序中对异常文档做扩展查询处理减少异常文档对正常文档的影响。
优缺点
异常值模式的优点如下
防止整个应用被某些异常的文档或请求所影响请求会针对那些典型的用例进行优化而异常值仍将得到处理
异常值模式的缺点如下
通常会为特定的查询而进行定制因此一些临时产生的查询可能性能不太理想此模式的大部分工作是在应用程序代码中完成的
预分配模式
示例描述
在使用 MMAPv1 存储引擎时MongoDB 的一个常见优化是提前分配所需的内存以满足不断增长的文档未来会达到的大小。
MMAPv1 中不断增长的文档需要由服务端以相当昂贵的成本进行位置的迁移而 WiredTiger 的无锁机制lock-free和重写rewrite更新算法不需要这种处理。
一个相对应的例子就是直接存储一个二维数据可以做到预分配内存而存储二维数组转换后的稀疏数组则无法做到预分配内存。
因此在 MMAPv1 中更推荐使用预分配模式直接存储原始的二维数组。
优缺点
预分配模式的优点如下
当预先知道文档结构时可以简化设计
预分配模式的缺点如下
简单和性能之间的权衡
多态模式
示例描述
在面向对象中多态指的是为不同数据类型的实体提供统一的接口或使用一个单一的符号来表示多个不同的类型。
而 MongoDB 不强制要求集合的文档拥有特定的结构这里的多态模式指的是集合中的文档具有更多的相似性而不是差异性文档结构都类似但又不完全相同。
其一种实现方案是将文档分组在一起做查询而不是将其分散到多个集合中另一种实现方案是使用嵌入式子文档的模式汇总。
多态模式的一个典型用例是单一视图应用程序假设现在一家较大的公司收购了其他公司这些公司的业务都是类似的数据库都以类似的方式存储了数据。
这个时候就可以利用 MongoDB 和多态模式在短时间内构建好单一视图应用程序。
除了单一视图应用程序外多态模式的其他典型用例还有以下几种
内容管理移动应用程序产品目录
优缺点
多态模式的优点如下
实现简单查询可以在单个集合中运行
模式版本控制模式
示例描述
几乎每个数据库在其生命周期中的某个时刻都会产生变更一旦数据库中的数据模型发生变化通常需要停止应用程序迁移数据库以支持新模式然后重新启动。
这种停机更新会导致糟糕的用户体验而模式版本控制模式允许历史版本和当前版本的文档在集合中同时存在以此保障用户体验。
通过使用 schema_version 字段定义模式的版本并将其保存到数据库中每个新的模式版本都会增加 schema_version 字段的值。
在应用程序内部为每个模式版本创建相应的处理函数这样即可适应不同版本的数据。
优缺点
模式版本控制模式的优点如下
不需要停机时间模式迁移可控减少未来的技术债务
模式版本控制模式的缺点如下
在迁移过程中对相同的字段可能需要两个索引
子集模式
示例描述
MongoDB 将频繁访问的数据保存在 RAM 中当数据和索引的工作集超过分配的物理 RAM 时随着磁盘访问的发生以及数据从 RAM 中转出性能会开始下降。
为解决这个问题一个方案是向服务器添加更多的 RAM不过扩展会有上限而且非常昂贵或者考虑对集合进行分片但这会带来额外的成本和复杂性。
子集模式就解决了有大量数据的大文档没有被应用程序使用而导致的工作集超过 RAM 容量的问题比如说一个电商产品的评论可能有成千上万条但大部分情况下都只会访问最近 10 个评论。
其实现方法就是将一个存储大文档的集合拆分成多个子集每一个子集都能为单独的功能提供资源减少了工作集的总体大小。
优缺点
子集模式的优点如下
在总体上减小了工作集的大小缩短了最常用数据的磁盘访问时间
子集模式的缺点如下
必须管理子集请求附加的数据需要额外的数据库访问
树形模式
示例描述
对于 SQL 来说可以通过外链子结点或父结点的方式表示树形结构。
对于 MongoDB 而言比较方便的就是通过存储子结点数组的方式实现但是其缺点就是每次更新时都需要操作整个结构不合适做频繁更新比如说家谱。
因此当数据是分层结构并且经常被查询时树形模式是比较优的一个选择。并且可以通过给数组中的属性创建多键索引提高查询效率。
优缺点
树形模式的优点如下
通过避免多次 JOIN 操作提高了性能
树形模式的缺点如下
需要在应用程序中管理树结构的更新
