mongodb 性能提升的6个步骤
2016-08-19 00:00
381 查看
摘要: 1. 监测mongodb
2. 优化文档结构
3. 优化索引
4. 优化内存
5. 优化IO
6. 分片集群
设置合理的预读值
关闭数据库文件的atime
2. 优化文档结构
3. 优化索引
4. 优化内存
5. 优化IO
6. 分片集群
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 })
相关文章推荐
- MongoDB创建表步骤,Mongo常用的数据库操作命令,查询,添加,更新,删除_MongoDB 性能监测
- mongodb 提升性能
- 云MongoDB优化让LBS服务性能提升十倍
- Atitit 提升开发进度大方法--高频功能与步骤的优化 类似性能优化
- 如何对 MongoDB 进行性能优化(五个简单步骤)
- MongoDB性能优化五个简单步骤
- Atitit 提升开发进度大方法--高频功能与步骤的优化 类似性能优化
- windows7系统开启AHCI模式提升硬盘性能具体步骤
- MongoDB MapReduce 性能提升20倍的优化宝典
- 云 MongoDB 优化让 LBS 服务性能提升十倍
- CQRS框架Axon 2提供了对MongoDB的支持及性能提升
- 云 MongoDB 优化让 LBS 服务性能提升十倍
- MongoDB 性能优化五个简单步骤
- MongoDB MapReduce 性能提升20倍的优化宝典
- MongoDB 性能优化五个简单步骤
- MongoDB 性能优化五个简单步骤
- MongoDB创建表步骤,Mongo常用的数据库操作命令,查询,添加,更新,删除_MongoDB 性能监测
- MongoDB MapReduce 性能提升20倍的优化宝典
- 提升MongoDB性能的方法
- MongoDB创建表步骤,Mongo常用的数据库操作命令,查询,添加,更新,删除_MongoDB 性能监测