上周五在北京DTCC分享了「32 Tips to Boost MongoDB Performance」,本文是分享的PPT以及重要内容的注解。
注解:本次分享主要「自底向上」的介绍提升 MongoDB 服务性能需要注意的问题,从硬件、操作系统、服务端一直到应用端,前面3个层次的建议主要面向DBA及运维人员,而最上层的应用开发建议主要面向开发者。
注解:了解一个数据库性能时,我们可能会从硬件、软件提供商、或技术同行那里获取到一些数据,但性能数据跟硬件配置、测试方法、环境、请求类型、数据集等都有很大的关联,在自己的环境里表现如何,建议通过benchmark实测一下,目前常用的mongoDB benchmark有 YCSB 以及 sysbench。
注解: 硬件选型方面,在不差钱的前提下肯定是越牛逼越好;对于大部分数据库应用来说,瓶颈可能最先出现在IO上,所以从机械硬盘到SSD的硬件提升通常是效果最明显的。
注解:数据库随机访问的模式较多,建议关闭THP、NUMA、readahead等特性,不排除这些特性可能在某些特定场景上能有性能提升,如果要开启请一定先做下对比测试。
注解:wiredtiger引擎在锁粒度、数据压缩上的支持远超mmapv1,从mmapv1升级到wiredtiger引擎,通常会带来存储成本的降低,以及性能的提升。
注解:生产环境建议一定使用3节点的MongoDB复制集,如果是写(尤其是更新、删除)密集型的应用,可以考虑讲oplog设置更大点(默认为磁盘空间5%)。
注解:mongoDB sharding 能实现数据库的水平扩展,但其相比复制集运维管理上更加复杂,建议只有在真正需要(扩展写入能力、扩展存储容量、降低当个分片故障时的影响)的时候才考虑使用sharding。
注解:选择shard key时,主要考虑key的「离散度」以及「频率」,离散度越高越好,能更好的分散数据;频率越低越好,避免出现热点;实际选择时,要结合查询需求来确定,最满足业务需求的才是最好的。
注解:sharding默认会自动在shard间进行数据迁移,如果迁移对线上访问有性能冲击,可以设置迁移窗口期,比如只在凌晨「1:00 – 6:00」来做数据迁移。
注解:慢请求对定位性能问题非常有帮助,建议线上业务都开启,并设置合理的阈值,默认为100ms。
注解:监控对任何线上业务都必不可少,监控的信息能让你充分了解线上服务的运行状态。
注解:很多场景下,数据备份是最后一根救命稻草,有备无患,建议数据库一定做好备份。
注解: MongoDB Driver:使用正确的姿势连接复制集
注解: MongoDB Driver:使用正确的姿势连接分片集群
评论前必须登录!
注册