MongoDB中的一些坑（最好不要用）(mongodb bi)

编辑：rootadmin

推荐整理分享MongoDB中的一些坑（最好不要用）(mongodb bi)，希望有所帮助，仅作参考，欢迎阅读内容。

文章相关热门搜索词:mongodb的语句,mongodb的常用命令,mongodb $nin,mongodb @indexed,mongodb bi,mongodb用法,mongodb $ne,mongodb的语句,内容如对您有帮助，希望把文章链接给更多的朋友！

MongoDB 是目前炙手可热的 NoSQL 文档型数据库，它提供的一些特性很棒：如自动 failover 机制，自动 sharding，无模式 schemaless，大部分情况下性能也很棒。但是薄荷在深入使用 MongoDB 过程中，遇到了不少问题，下面总结几个我们遇到的坑。特别申明：我们目前用的 MongoDB 版本是 2.4.，曾经升级到 MongoDB 2.6.0 版本，问题依然存在，又回退到 2.4. 版本。

MongoDB 数据库级锁

坑爹指数：5星（最高5星）

MongoDB的锁机制和一般关系数据库如 MySQL（InnoDB）, Oracle 有很大的差异，InnoDB 和 Oracle 能提供行级粒度锁，而 MongoDB 只能提供库级粒度锁，这意味着当 MongoDB 一个写锁处于占用状态时，其它的读写操作都得干等。

初看起来库级锁在大并发环境下有严重的问题，但是 MongoDB 依然能够保持大并发量和高性能，这是因为 MongoDB 的锁粒度虽然很粗放，但是在锁处理机制和关系数据库锁有很大差异，主要表现在：

MongoDB 没有完整事务支持，操作原子性只到单个 document 级别，所以通常操作粒度比较小；MongoDB 锁实际占用时间是内存数据计算和变更时间，通常很快；MongoDB 锁有一种临时放弃机制，当出现需要等待慢速 IO 读写数据时，可以先临时放弃，等 IO 完成之后再重新获取锁。通常不出问题不等于没有问题，如果数据操作不当，依然会导致长时间占用写锁，比如下面提到的前台建索引操作，当出现这种情况的时候，整个数据库就处于完全阻塞状态，无法进行任何读写操作，情况十分严重。

解决问题的方法，尽量避免长时间占用写锁操作，如果有一些集合操作实在难以避免，可以考虑把这个集合放到一个单独的 MongoDB 库里，因为 MongoDB 不同库锁是相互隔离的，分离集合可以避免某一个集合操作引发全局阻塞问题。

建索引导致数据库阻塞

坑爹指数：3星

上面提到了 MongoDB 库级锁的问题，建索引就是一个容易引起长时间写锁的问题，MongoDB 在前台建索引时需要占用一个写锁（而且不会临时放弃），如果集合的数据量很大，建索引通常要花比较长时间，特别容易引起问题。

解决的方法很简单，MongoDB 提供了两种建索引的访问，一种是 background 方式，不需要长时间占用写锁，另一种是非 background 方式，需要长时间占用锁。使用 background 方式就可以解决问题。例如，为超大表 posts 建立索引，千万不用使用

而应该使用

不合理使用嵌入 embed document

坑爹指数：5星

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

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

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

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

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

不合理使用 Array 字段

坑爹指数：4星

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

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

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

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

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

MongoDB中创建索引需要注意的事项上周在ruby-china上发了帖子《MongoDB那些坑》，反映相当热烈，许多回复很有见地，其中一位童鞋深入的提到MongoDB建索引方法的问题，引发我更深入的了

Windows下MongoDB配置用户权限实例 MongoDB默认设置为无权限访问限制注：研究成果基于Windows平台在部署mongodb成功后，进入控制台：输入命令：mongoduseadmin，你会发现该DB下包含了一个system

Mongodb数据库的备份与恢复操作实例写在前面本文已经假设你已经安装好了Mongodb(2.6)，并且已经开启了auth。用户首先我们添加备份和恢复数据所需的用户，这个用户需要有readWrite和userAdmin

标签: mongodb bi

本文链接地址:https://www.jiuchutong.com/biancheng/312735.html 转载请保留说明！

上一篇：给MongoDB添加用户权限方法分享(mongodb添加数据)

下一篇：MongoDB中创建索引需要注意的事项(mongodb索引存储方式)