mongodb写入性能优化 mongodb性能瓶颈

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

MongoDB 数据库级锁

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

库级粒度锁，这意味着当 MongoDB 一个写锁处于占用状态时，其它的读写操作都得干等。

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

• MongoDB 没有完整事务支持，操作原子性只到单个 document 级别，所以通常操作粒度比较小；
• MongoDB 锁实际占用时间是内存数据计算和变更时间，通常很快；
• MongoDB 锁有一种临时放弃机制，当出现需要等待慢速 IO 读写数据时，可以先临时放弃，等 IO 完成之后再重新获取锁。

通常不出问题不等于没有问题，如果数据操作不当，依然会导致长时间占用写锁，比如下面提到的前台建索引操作，当出现这种情况的时候，整个数据库就处于完全阻塞状态，无法进行任何读写操作，情况十分严重。

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

建索引导致数据库阻塞

坑爹指数：3星

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

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

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

而应该使用

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.MongoDB 锁机制详解 * 2.MongoDB 建立索引操作文档

*****************************************************************************************************

我们项目组，使用mongodb已经2年多了，目前的版本是：2.2.1 。针对使用中遇到的问题，谈点我自己的感受吧，既然这个帖子基调已定 ：），所以好处就不用废话了，就谈点注意事项而已。

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

为了在开发环境下统计耗时的查询，我monkey了 Moped 的代码，这样可以很容易的查看哪些比较耗时的查询。代码如下：

# encoding: utf-8
module Moped

  # Represents a client to a node in a server cluster.
  #
  # @api private
  class Node

        if Rails.env == 'development'

            @@time_consuming_msg = []

            alias_method :log_operations_old, :log_operations

            def log_operations(logger, ops, duration_ms)
                log_operations_old(logger,ops,duration_ms)
                time = duration_ms.round(2)
                if time > 30.0  # > 50ms
                    #p '='*100
                    t_s = "%.4fms" % duration_ms
                    @@time_consuming_msg << {msg: "#{ops.first.log_inspect} (#{t_s})", time: time}
                end

            end

            def self.print_consuming_time_stat_info(logger)
                if @@time_consuming_msg.size > 0
                    log = MongoidColoredLogger::LoggerDecorator.new(logger)
                    log.warn "\n"
                    log.warn "\e[33m#{'*'*100}\e[0m"
                    log.warn "\e[31m#{' '*32}Query consuming time -- Top ranking list\e[0m\n"
                    @@time_consuming_msg.sort{|x,y| x[:time] <=> y[:time] }.each do |msg|
                        log.warn msg[:msg]
                    end
                    log.warn "\e[33m#{'*'*100}\e[0m\n"
                    @@time_consuming_msg = []
                end
            end

        end
    end

end

以上如果有问题的地方，还请多多指教。