mongodb 性能提升的6个步骤
第一步. 做监测工作
专门整理了一下我用到的监控命令和工具，
见于 : https://my.oschina.net/340StarObserver/blog/793897
第二步. 优化文档的结构
当面临性能问题的时候，首先考虑的是优化文档结构和优化索引，其次才是系统调优和硬件优化
在设计文档的结构的时候，一定要非常清除你需要解决的最重要的问题是什么
mongodb并不是万能的许愿机，很多时候为了让你的最主要的业务流畅，你只能做出权衡
下面提出两个原则 :
1. 文档结构并不取决于数据的内容，而是取决于数据的访问方式
即，不要面向数据去设计数据库，而是面向应用去设计数据库
2. 无计可施时，割肉全身，善用冗余来提高查询效率
下面举两个案例
两个案例均来自imooc上面的MongoDB2014北京大会，链接为 http://www.imooc.com/learn/255
案例一
存储电商的产品，每个文档形如 :
{
_id : 一个很长的字符串（全局唯一）,
china : { 该产品的中文描述的具体的一些属性 },
english : { 该产品的英文描述的具体的一些属性 },
japan : { 该产品的日文描述的具体的一些属性 },
...还有其他十几个语系
}
原始的索引是 { _id : 1 }
原始的查询语句是 db.products.find( { _id : xxx }, { china : 1 } )
比如这里是一个中国人来查询xxx这件商品的具体信息
乍看之下这个设计确实没问题啊，为什么会很慢 ?
经过查日志发现，缺页中断太多，诶 ? 这关缺页中断什么事 ?
原因如下 :
1. 首先，mongodb在查询的时候，不管你有没有指定是否只返回某些字段，它都会把整个文档查出来放到内存中
2. 只不过在mongodb客户端（mongo-shell或者应用程序）看来，它只拿其中的china字段（当然_id是必拿的）
3. 所以，就算你只需要china字段，实际上内存中是存在着这个商品的全部信息
4. 假设总共20个语系，即内存的使用率只有 5%
5. 换句话说，内存原可以放20个商品，结果放了5个就满了，那当查询其余15个商品时，缺页中断率不高才怪
解决方案 :
拆分文档，拆分后的结构形如 :
{
_id : 原来的_id 连接上 语系,
detail : { 该产品的在该语系下的详细描述 }
}
索引不变，现在的查询语句变为 db.products.find({ _id : xxxchina })
这样一来，mongodb查出来的就是我要用的，内存使用率提高了20倍，缺页中断大大减少
案例二
社交圈中的动态，涉及两种文档，一是用户文档，二是动态文档。简单表示如下 :
用户文档 :
{
_id : 用户id,
friends : [ 朋友1的id, 朋友2的id, ... ]
}
用户文档的索引 { _id : 1 }
动态文档 :
{
creator : 发布者的id,
time : 发布的时间戳,
content : 动态的内容
}
动态文档的索引 { creator : 1, time : -1 }
要查出我的所有朋友最近的几条动态，需要做联合查询，而且是带in的联合查询，慢是正常的
解决方案 :
在每发布一条动态的时候，顺带加上当前我的所有朋友，修改后的动态文档的结构 :
{
creator : 发布者的id,
time : 发布的时间戳,
friends : [ 此时的朋友1的id, 此时的朋友2的id, ... ],
content : 动态的内容
}
另外为这个文档增加索引 { friends : 1, time : -1 }
现在的查询语句就不是联合查询了，会快很多
但是这个解决方案很奇葩是么，搞这么大的冗余，多浪费磁盘啊，而且一致性的维护怎么做？
但是，需要牢记的是，你的目标是啥？你需要解决的最大的问题是啥？
如果你的应用，容忍一定程度的不一致性，比如社交圈这种，肯定是要优先照顾读的性能，通过冗余来提高读性能是很常见的
你可能会有疑问 ：
案例一是因为要查的信息占整个文档的比例太小，所以内存利用率不高导致缺页中断频繁
照这个道理，案例二中增加了很大的冗余信息，不是也会导致频繁的缺页中断吗，为什么案例二就可以用冗余呢
此两者不是很矛盾吗？
我一开始也有这个疑惑，但是我要说的是，你会这么想，是不自觉地犯了根据数据内容来设计数据库的老病
具体分析一下 :
案例一存储的是电商商品的信息，所有人都可能会去查询一些热门商品的信息
也就是说，商品信息存在热数据，而且是被所有人都可能访问的热数据
所以，在这种应用场景下，为了让热数据使用率更高，当然要提高内存利用率，即减少缺页中断的次数
既然要提高内存的利用率，就要使得用户查的信息占整个文档的比例尽可能大
这样一来，才能让固定的内存去装的下更多数量的文档
所以，需要把一个商品的文档按照语系来切分成不同的文档
这样一来，那些罕见语系的商品信息基本不会占用内存，内存中都是热门商品的常用语系的信息
案例二存储的是不同用户发表的动态信息
第一，不同人的动态是不同的。第二，而且一般查的时候是翻页来查的
这两个原因就决定了这种数据是不存在热数据的概念的
所以，绝大多数情况，都是不可避免的缺页中断，都是去磁盘上查
既然无法使用热数据，既然不可避免地查磁盘，那就只能让查磁盘更快这条路了
所以，使用冗余是合适的
对比分析了这两个案例，以及你可能出现的疑惑，相信你有了更深刻的认识
再次强调 :
不要面向数据去设计数据库，而是要面向应用去设计数据库
第三步. 优化索引
和一般的sql索引很类似，不做太多阐述，这边我只提一个之前没有注意到的降序索引
例如消息文档 :
{
myid : 我的id,
who : 谁给我发的消息,
time : 消息的时间戳,
content : 消息的内容
}
消息文档的索引 { myid : 1, time : -1 }
这样的索引，可以很快地找出与我相关的最近几条消息，实现按时间降序分页查询
如果用{ myid : 1, time : 1 }索引的话 :
还需要排序，我不知道mongodb内部会不会做什么优化，但是用降序索引肯定是确保效率的
另外，当你有多种索引方案备选时，建议通过explain来看看谁更好
第四步. 优化内存
首先，提两个概念
概念一. 内存映射
mongodb采用内存映射的方式来进行内存和磁盘上的数据调度
其实内存映射是操作系统自带的，并不是mongodb自己实现的
当你访问的数据在内存中的时候，mongodb能够很快地把数据拿给你
当你访问的数据不在内存时，会触发缺页中断，告诉操作系统把xx号页面调入内存，然后再读内存
概念二. 工作集
工作集 = 索引 + 内存中的热数据
如何查索引的大小？
在mongo shell中，切换到你的某个库，通过 db.stats() 来查看
其中的 indexSize 便是该库的所有索引占的字节数
如何查内存中的热数据的大小？
在mongo shell中，切换到admin库，通过 db.serverStatus() 来查看
该命令会返回最近15分钟内的运行情况
如果只需要查热数据的大小，可以通过 db.serverStatus()['extra_info']，我的mongo版本是3.2.4
其中的 heap_usage_bytes 便是内存中的热数据占的字节数
为了让mongodb尽量少的发生缺页中断，应该让内存大于工作集的大小
这便是选用内存大小的根据
如果单机确实无法满足的话，就只能通过分片了
因为很多时候工作集确实很大，甚至索引的大小就超过了实际数据的大小
但是在分片的每台主机上，选用内存的依据还是工作集
第五步. 优化IO
对于不同的数据，采用不同的存储介质
数据文件用SSD来存储
mongodb绝大多数情况下，都是随机读写
相同情况下，SSD随机读写的效率是HDD的几十倍
日志文件用HDD来存储
对于顺序读写来说，SSD和HDD的效率相差不大
设置合理的预读值
什么是预读值？
在请求磁盘上的数据的时候，操作系统并不是只返回一个页面，而是把接下来的好几个页面都调入内存中
而mongodb绝大多数是随机读写，如果预读值太大（默认是256），会导致缺页中断比较多
此时就需要调小预读值，一般设置为32比较合适
例如 :
通过 sudo blockdev --report 来查看系统各存储设备的预读值
通过 sudo blockdev --setra 32 /dev/sda5 来设置/dev/sda5这个分区的预读值是32K
关闭数据库文件的atime
禁止系统对文件的访问时间更新会有效提高文件读取的性能
比如你的mongodb的数据在 /mydata 下面，文件系统是 ext4
可以在 /etc/fstab 这个文件中添加一行 /dev/xvdb /mydata ext4 noatime 0 0
修改完后，重新挂载 sudo mount -o remount /mydata
第六步. 分片集群
我专门写了一篇关于mongodb的分片片键的博客
[地址是](http://my.oschina.net/340StarObserver/blog/688232)
第七步. 其他建议
1. 开启 releaseConnectionsAfterResponse 参数
db.runCommand({ setParameter : 1, releaseConnectionsAfterResponse : true })
855
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
