MongoDB
上周五在北京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：使用正确的姿势连接分片集群
MongoDB
