MongoDB 那些坑

内容导读

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

内容图文

而应该使用

db.posts.ensureIndex({user_id: 1}, {background: 1})

不合理使用嵌入 embed document

坑爹指数：5星

embed document 是 MongoDB 相比关系数据库差异明显的一个地方，可以在某一个 document 中嵌入其它子 document，这样可以在父子 document 保持在单一 collection 中，检索修改比较方便。

比如薄荷的应用情景中有一个 Group document，用户申请加入 Group 建模为 GroupRequest document，我们最初的时候使用 embed 方式把 GroupRequest 放置到 Group 中。
Ruby 代码如下所示（使用了 Mongoid ORM）:

class Group
  include Mongoid::Document
  ...
  embeds_many :group_requests
  ...
end

class GroupRequest
  include Mongoid::Document
  ...
  embedded_in :group
  ...
end

这个使用方式让我们掉到坑里了，差点就爬不出来，它导致有接近两周的时间系统问题，高峰时段常有几分钟的系统卡顿，最严重一次甚至引起 MongoDB 宕机。

仔细分析后，发现某些活跃的 Group 的 group_requests 增加（当有新申请时）和更改（当通过或拒绝用户申请时）异常频繁，而这些操作经常长时间占用写锁，导致整个数据库阻塞。原因是当有增加 group_request 操作时，Group 预分配的空间不够，需要重新分配空间（内存和硬盘都需要），耗时较长，另外 Group 上建的索引很多，移动 Group 位置导致大量索引更新操作也很耗时，综合起来引起了长时间占用锁问题。

解决问题的方法，说起来也简单，就是把 embed 关联更改成的普通外键关联，就是类似关系数据库的做法，这样 group_request 增加或修改都只发生在 GroupRequest 上，简单快速，避免长时间占用写锁问题。当关联对象的数据不固定或者经常发生变化时，一定要避免使用 embed 关联，不然会死的很惨。

不合理使用 Array 字段

坑爹指数：4星

MongoDB 的 Array 字段是比较独特的一个特性，它可以在单个 document 里存储一些简单的一对多关系。

薄荷有一个应用情景使用遇到严重的性能问题，直接上代码如下所示：

class User
  include Mongoid::Document
  ...
  field :follower_user_ids, type: Array, default: []
  ...
end

User 中通过一个 Array 类型字段 follower_user_ids 保存用户关注的人的 id，用户关注的人从 10个到 3000 个不等，变化是比较频繁的，和上面 embed 引发的问题类似，频繁的 follower_user_ids 增加修改操作导致大量长时间数据库写锁，从而引发 MongoDB 数据库性能急剧下降。

解决问题的方法：我们把 follower_user_ids 转移到了内存数据库 redis 中，避免了频繁更改 MongoDB 中的 User, 从而彻底解决问题。如果不使用 redis，也可以建立一个 UserFollower 集合，使用外键形式关联。

先列举上面几个坑吧，都是害人不浅的陷阱，使用 MongoDB 过程一定要多加注意，避免掉到坑里。

针对使用中遇到的问题，谈点我自己的感受吧，就谈点注意事项而已。

1. 一定要合理创建索引， 有很多人都被宣传片迷惑，认为mongo的读取速度本身就应该很快，所以从mysql转过来后，就连创建索引都忘了，当表(collection) 很大时，不创建索引是非常影响性能的。 创建索引很简单，如果你不想使用shell那么麻烦，直接在model里面声明就是了：index({ xxx: 1 }, { unique: true, background: true })；然后运行一个rake命令：rake db:mongoid:create_indexes 就ok了，这个命令不会重复创建的。

2. 大表查询时，只返回你想要的列，楼主讲了很多write的性能问题，可能是场景不同的原因，我们大量遇到了查询的性能问题；这一点就不用多说了吧，其他关系型数据库也有这种问题。 特别是单collection字段数据量比较大时，非常容易引起性能问题，在rails里面也很简单，查询时加上only就是了。比如 User.where(xxx).only(:f1,:f2) 。

3. 尽量一次返回所有需要的数据，避免GET_MORE，避免游标操作，当用户进行查询迭代时，mongo会首先返回一个数据块供你迭代，当你迭代的数据超过这个数据块时，mongoid 发起 GET_MORE 命令移动游标获取下一个数据块，而就是这个移动游标的操作就非常慢，特别是你返回的列比较多的时候，性能非常低。每次返回的数据块的大小是由batchSize控制的，可以通过修改它的默认值进行控制。

4. 尽量避免在model里面使用Array类型的字段，原因楼主已经说了，不过我们遇到的还是查询的问题，因为你使用了Array，查询时，你不可避免的会使用 ##in## 操作，in操作无法利用索引，这个在关系型数据库里面也是存在的，大表操作一定要避免。

5. 不要在和数据库直接相关的model里面使用继承， 什么意思呢？就是 modelB < model A ,而他们都是mongo里面的 document，为什么不能这样？ 因为mongoid的内部实现其实只会创建一张表就是documentA, 然后在 documentA 里面用一个 _type 字段来标识 documentB，这样当你查询 modelB 时，内部会生成一个查询到 documentA 的语句，那个查询就是用的 _type in [xxxx] 类似这样的语句，你看又是 in 操作。如果这种情况你是在后期才发现的，你真是回天无术，想死的心都有：）。

6. 事务，还是事务，mongodb不支持事务，所以你一定要考虑清楚，权衡利弊。我们有些功能就必须使用事务，没办法，我想到一个非常丑陋的方法，记录每个创建和更新的model，它的id和更新数据，如果一旦有异常，我就撤销更新和创建，真的是非常麻烦。想想看在一个支持事务的关系型数据库里面，这些是非常简单的。

7. 主从备份还不是很成熟，这一点，估计是我研究的不深入的原因，我仍然认为主从备份不是很成熟，有些时候简直就是提心吊胆，如果有经验的同学在这里，可以多多讨论。

MongoDB 那些坑

标签：建模   关系型数据库   2.4.1   经验   环境   集合   更新   ilo   shel   

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

内容总结

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

内容备注

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

内容手机端