MongoDB 进阶模式设计

内容导读

互联网集市收集整理的这篇技术教程文章主要介绍了MongoDB 进阶模式设计，小编现在分享给大家，供广大互联网技能从业者学习和参考。文章包含8386字，纯文字阅读大概需要12分钟。

内容图文

虽然MongoDB的模型和关系型截然不同，但是关系型数据库的一些必不可少的功能如动态查询、二级索引、聚合等在MongoDB中也有非常完善的支持。 
这里我介绍一下文档模型的优点：

• 读写效率高-由于文档模型把相关数据集中在一块，在普通机械盘上读数据的时候不用花太多时间去定位磁头，因此在IO性能上有先天独厚的优势；
• 可扩展能力强-关系型数据库很难做分布式的原因就是多节点海量数据关联有巨大的性能问题。如果不考虑关联，数据分区分库，水平扩展就比较简单；
• 动态模式-文档模型支持可变的数据模式，不要求每个文档都具有完全相同的结构。对很多异构数据场景支持非常好；
• 模型自然-文档模型最接近于我们熟悉的对象模型。从内存到存储，无需经过ORM的双向转换，性能上和理解上都很自然易懂。

那么我们如何考虑MongoDB 文档模式设计的基本策略呢？

• 其实很简单，我们一般建议的是先考虑内嵌， 直接按照你的对象模型来设计你的数据模型。如果你的对象模型数量不多，关系不是很复杂，那么恭喜你，可能直接一种对象对应一个集合就可以了。
• 内嵌是文档模型的特色，可以充分利用MongoDB的富文档功能来享受我们刚才谈到的一些文档模型的性能和扩展性等特性。一般的一对一、一对多关系，比如说一个人多个地址多个电话等等都可以放在一个文档里用内嵌来完成。
• 但是有一些时候，使用引用则难以避免。比如说， 一个明星的博客可能有几十万或者几百万的回复，这个时候如果把comments放到一个数组里，可能会超出16M的限制。这个时候你可以考虑使用引用的方 式，在主表里存储一个id值，指向另一个表中的 id 值。使用引用要注意的就是：从性能上讲，一般我们可能需要两次以上才能把需要的数据取回来。更加重要的是：需要把数据存放到两个集合里，但是目前为止 MongoDB并不支持跨表的事务性，所以对于强事务的应用场景要谨慎使用。

很多时候我们并不能很好地回答自己的问题，包括刚才的内嵌还是引用的问题。那么这个时候有必要了解一下，MongoDB模式设计的终极原则。 MongoDB的模式设计和关系型大不相同，我们说MongoDB是为应用程序设计的，而不是为了存储优化的。如果可以达到最高性能的话，我们甚至可以做 一些反范式的东西。 接下来我们来看几个比较具体的设计案例，了解一下MongoDB的模式设计思路：

我这里准备了4个比较经典的MongoDB案例，从CMS 内容管理到电商，社交到物联网。 由于时间原因我就从第二个开始。

在电商方面MongoDB的应用场景其实蛮多，比如说，大名鼎鼎的京东用mongo来存储过亿的商品信息，另外有一家著名的境外电商从头到尾用的都是 MongoDB，包括订单管理等。这里我们就来看一下购物车这个场景。购物车的特点就是单个购物车数据项不会太大，一般来说不会超过100项目。双十一的 时候淘宝的购物车里最多就只能放99件商品。在这里我要谢谢我的太太，是她让我知道了这个限制。另外一点就是购物车的数据可能需要过期删除。

我们说文档模型在这种场景会是个很好的选择：

大家看一下下面的参考数据模型，第一点注意我们可以使用MongoDB的TTL 索引来自动清理过期数据。TTL索引可以建立在任意一个时间字段上，在建立索引的时候可以指定文档在过多少时间后会被自动清理掉。 第二个大家注意的是什 么呢？在这里我们把商品的一些主要信息放到购物车里了，比如说 name,price, quantity，为什么？ 读一次所有信息都拿到了：价格、数量等等，不需要再去查另一张表。这是一种比较常见的优化手段，用冗余的方式来提供读取性能。

接下来我们看一下使用这种模式的时候如何进行一些购物车的操作。比如说，如果我们想要往购物车里增加一个价值2元的面包，我们可以用下面的update语句。注意$push的用法。$push 类似于javascript的操作符，意思是往数组尾部增加一个元素。
如果需要更新购物车中某个产品的数量，你可以用update语句直接操作数组的某一个元素。在这里我们需要做的是更新item 4567的数量为5。 注意 items.$.quanity的使用，这里的$ 表示在查询条件里匹配上的数组元素的序数。

如果需要统计一下在购物车内某个商品的总数，可以使用MongoDB的聚合功能。聚合运算在MongoDB里面是对数据输入源进行一系列的运算。在这里我们做的就是几个步骤是：

1. $match: 在所有购物车中过滤掉其他商品，只选出id是8910的商品
2. $unwind: 把items 数组展开，每个数组元素变成一个文档
3. $group: 用聚合运算 $sum 把每一件商品的数量相加获得总和

下面我们来看一个社交网络的例子。社交app最关键的一些场景就是维护朋友关系以及朋友圈或微博墙等。

对于关系描述，使用文档模型的内嵌数组特性，我们可以很容易地把我关注的用户（following）和关注我的用户表示出来。下例表示TJ我的关注的用户 是mandy和bert，而oscar和mandy则在关注我。这种模式是文档模型中最经典的。但是有一个潜在问题就是如果TJ我是一个明星，他们关注我 的人可能有千万。一个千万级的数组会有两个问题：1） 有可能超出一个文档最大16M的硬性限制  2） MongoDB数组太大会严重影响性能。

怎么办？我们可以建立一个专门的集合来描述关注关系。这里就是一个内嵌和引用的经典选择。我们希望用内嵌，但是如果数组维度太大，就需要考虑用另外一个集合的方式来表示一对多的关系（用户 1–N 关注者）
另外一个要注意的是 关注数，我们在显示关注和粉丝数量的时候，不希望去跑一次count 查询再显示。因为count操作一般来说会比较占资源。通常的做法可以再用户对象里面加两个字段，一个是关注数一个是粉丝数。每次有人关注或者关注别人时候就更新一下。

下面我们来看看比较有趣的微博墙，或者微信朋友圈的实现有什么考量。

在实现微博墙的时候，有两种方式可以考虑： 扇出读 或者是 扇出写。

扇出读、扇出写的说法是基于社交网络的海量用户、海量数据的应用特征。这些大量的数据往往分布在各个分片服务器上。扇出读是一种比较常规的做法，就是当你 需要去获得所有你关注用户的最新更新的时候，你就去到每一个你关注用户的数据区，把最新的一些数据取回来。因为需要去到不同的分片服务器去取，所以叫做扇 出读。大家可以想象，这种扇出读的效率不会太高，基本上是最慢的那个服务器的响应时间决定了总体的响应时间。 当然，这种方式是比较简单的，不需要特殊处理。

扇出写，我称之为土豪玩法。具体来说就是当发布的时候，一条数据会写多次，直接写到每一个关注你的粉丝的墙上。这样做的好处是当你的粉丝读他自己的微博墙 的时候，他只需要去一个地方就可以把所有最新的更新连续取回来。由于一个用户的数据可一般可以存储在同一台服务器上的同一个区域，通过这种方式可以实现快 速的读取微博墙数据。 代价当然也是很明显： 你的写入需求会被放大几十几百倍，存储也是相应的扩大几十几百倍。这个绝对不是关系型数据库的玩法，但是在MongoD 模式设计，这个很正常。只要保证性能，什么事情都做得出来。

下面这个例子，首先是mandy在发消息的时候会写（push）到我的墙上（timeline）来。如果mandy有50个关注者，那么这个写就会有50次，每个关注者一次。

第二条语句就是我打开微博的时候，一条语句，一个地方就可以找到所有我朋友发的状态更新。注意：这里还使用了bucket，这是另外一个控制文档内 数组元素个数的有效方法。比如说我们定义bucket 大小是1000的话，超过1000 就把新的数据插入到下一个文档并对bucket 序数递增。

好了，最后我们来看一下物联网的应用场景：

各位还有多少人仍然记得MH370，去年在印度洋消失的客机？在该事故之后，许多人都在疑惑：在当今的技术水平下，为什么我们不能跟踪如此庞大的一个东西？

让我们来看看如果要监控飞机数据有什么样的挑战。飞机上面的数据源众多，光收集位置信息，就需要多个系统协作完成， 如ADS-C， EUROCONTROL等等。此外，收集的数据也是各种各样：位置是2D、速度是数值、引擎参数则是多维度的。
另一个挑战就是海量数据。一个三小时的航班，每分钟采集一次，少说点，每次100条数据，那就是每秒1万8千个数据点。按每天100，000航班，一天的 数据算下来有18亿条，1.8TB 左右的数据， 21,000 的QPS。 从哪个角度来看，这都是个经典的大数据问题。

这个问题在关系型数据库解决的话，比较幼稚的方法就是设计一个超宽的表。所有需要采集的每一个值就是一个列。这种设计的问题比较明显：

1. 容易造成空白浪费，不是每一条记录都包含所有字段值
2. 可能会经常需要改数据库模式。对于海量数据，改一次模式代价巨大。

另一种改良方案是用EAV 设计模式。就是采用一个主表和一个属性值表。在属性值表里存放所有的参数键值对。这样做的好处自然是灵活性：增加新的参数时无需修改模式。但是问题同样存 在：用来存储值的那列 METRIC_VALUE的字节大小必须定义成所有值的最大值 才可以放下所有的参数值。这个可能带来空间浪费，但是更严重的问题是：将不太可能在此字段上建索引，进而影响一些场景的使用。 
下面我们来看看文档模型怎么做： 这里对于location 、speed 等不同数据类型的字段，在文档模型下可以直接支持。下面的两个文档，第一个文档和第二个文档可以同属一个集合，但是可以有完全不同的字段。 MongoDB对异构数据的支持在这样的场景下有得天独厚的优势。如果我们希望对某一个metric如location建立索引，我们也可以使用 mongoDB的稀疏索引 (Sparse Index)仅对有location字段的文档建索引，在不造成索引空间浪费的前提下提高检索效率。当需要增加新的字段的时候，也不需要对模式做任何修 改，可以直接就在应用中的JSON模型里添加需要的字段（elevation)。

在IOT这个场景里，我们可以使用一个叫做分桶的设计方式来进行几十倍的性能增长。 具体来说就是把采集的数据按小时为一个桶，把每小时的数据聚合 到一个文档里。如下面所示，每分钟的值用子文档的一个字段来表示。这样做的好处就是大量减少文档的数量，相应的索引数量也会减少，总体写入IO将会大幅度 降低并得到性能提升。

使用这种方式我们还可以把一些统计需要的数值，如每小时的平均值预先就作为一个字段存进去，需要的时候不用现场计算，只要从文档里读出来即可。

小结一下，冗余、扇出写、分桶，这些都是mongodb 的一些常用优化手段。 大家可以看到，通过减少额外查询或者关联的需求，通过使用冗余、额外存储的非常规方式，我们希望做到的是性能上的最高提升。

MongoDB 进阶模式设计

MongoDB 进阶模式设计

标签：

本文系统来源：http://www.cnblogs.com/taozi32/p/5070799.html

内容总结

以上是互联网集市为您收集整理的MongoDB 进阶模式设计全部内容，希望文章能够帮你解决MongoDB 进阶模式设计所遇到的程序开发问题。 如果觉得互联网集市技术教程内容还不错，欢迎将互联网集市网站推荐给程序员好友。

内容备注

版权声明：本文内容由互联网用户自发贡献，该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 gblab@vip.qq.com 举报，一经查实，本站将立刻删除。

内容手机端