大规模运行MongoDB应该知道的10件事

MongoDB的首席解决方案架构师Asya Kamsky 最近发表了一篇文章，归纳了大规模运行MongoDB须要知道的10件事。

1. MongoDB也须要DevOps。MongoDB是一个数据库。和任何其余的数据存储同样，它也须要容量计划、调整、监控和维护。不要由于它很容易安装、入门，同时与关系型数据库相比可以更加天然地知足开发人员的范例就认为MongoDB不须要适当的照顾和喂养。开发时它能在小样本数据集上超快地运行并不意味着你就不须要良好的模式、索引策略以及产品环境所须要的正确的硬件资源了。可是若是你准备的很好，而且理解最佳实践，那么运营大型MongoDB集群就会变得很无聊，而不是使人很是头痛。

2. 成功的MongoDB用户会监控全部的事情，同时会作好增加的准备。在任何数据库系统中跟踪当前的容量以及容量计划都是基本的实践，MongoDB也是如此。你须要知道集群如今可以支撑多少工做，最高使用率时它会处理哪些需求。若是你没有注意到服务器上增加的负载，那么最终会遇到没有足够容量的错误。监控MongoDB可使用MongoDB管理服务（MMS），经过查看操做计数器（opscounters）图表可视化本身的操做：

3. 你可能并不但愿系统随着使用量的增加出现性能扩展障碍。 根据大量用户的部署经验，性能瓶颈一般是（按顺序）：

   事实证实，在真正的大型部署实践中对性能影响最大的是模式设计与应用程序需求的契合程度。而缺乏索引、索引错误或者索引太多则是影响性能的第二大因素。在模式设计很是完美，索引也最优的状况下，磁盘IO吞吐能力就成了下一个限制因素，尤为是写吞吐量。RAM不足会引起不少页错误，同时也会增长磁盘IO的压力。

• 应用程序访问模式没有使用最优的模式设计

• 索引不佳或者缺失索引，抑或有太多没必要要的索引

• 磁盘较慢/磁盘IOPS不足

• 索引没有足够的RAM

4. 不少成功的MongoDB用户使用单复制集。太早分片多是过早优化，并非每一个MongoDB部署都须要分片。分片处理很是特殊的需求，不能不加思索地认为它就是解决“数据库很慢”的最佳方案。若是你的协调模式很是差劲或者有错误索引，那么分片并不能解决问题，相反的你最终会获得一些差劲的协调和差劲的执行碎片。当单台机器或者复制集上的某种特殊资源成为瓶颈，同时基于成本的考虑没法添加更多这种资源的时候才适合分片。你可能须要更多的磁盘IO吞吐量，或者更多的内存，或者更多的存储，再或者更多的并发，这种状况下分片才是有意义的。

5. 即便没有将整个数据库放在内存中，MongoDB依然可以取得很是好的性能。对于MongoDB常见的一个误解是：为了得到更好的性能须要将整个数据库放在内存中。这多是最错误的一件事情，由于这依赖于集群正在处理的负载的类型。有一些标志和指标可以告诉你：相对于你放到数据库上的负载类型你所拥有的内存数量是否充足。正如你所看到的，随着数据库大小的增加，可以放到内存中的相关部分将会受限于可用物理内存的大小。若是内存的数量不能知足性能需求，那么你将会看到页面错误，随着页面错误率的上升，opcounters最终会低于指望值。

6. 必须将数据写刷新到磁盘。若是磁盘利用率达到了100%，那么处理更多写操做的速度比起如今得不到丝毫的提高。能够经过MMS中的“Background flush average”图表查看将数据文件中的脏页刷新到磁盘花费了多长时间。经过这种趋势你会发现，随着写操做的增加，刷新将花费更多的时间。这种问题能够经过使用更快的磁盘解决，将工做拆分到更多的分片上，或者调整应用程序使之减小写数据的总量。你应该记住：写入的全部内容都会被刷新到磁盘两次——当即刷新到日志同时周期性地刷新到数据文件。将这两种操做分离到不一样的物理设备上将会消除它们对可用磁盘IO带宽的竞争。 
   

7. 复制 != 备份。全部人都清楚备份的重要性。可是为何备份这么重要呢？ 想必是由于当某些影响全部复制集节点的灾难性事件发生的时候咱们能够恢复数据。复制并非备份的缘由是：它并不能让你避免人为错误——例如某些人忽然删除了产品数据，或者部署了错误版本的应用程序代码以至于搞乱了部分或者全部数据。必需要有一个可以让咱们从这种场景中恢复数据的备份。经过文件系统快照、mongodump或者MMS备份练习数据恢复。第一次从备份恢复产品数据的操做不该该发生在真正的“数据紧急事件”发生的时候。

8. 复制集的健康不只仅是复制延迟。“复制延迟”仅仅是复制集健康情况的指标之一。关注复制操做日志（oplog）窗口和监控复制延迟同样重要。它表示的是基于如今的写流量彻底“滚动”oplog所要花费的时间。换句话说，它指的是将一个复制节点拿下来之后依然可以从新加入集合而没必要对全部数据进行从新同步的时间。随着时间的推移，复制操做日志窗口将会随着写负载的变化而浮动。流量高峰时窗口会缩短。这在容量计划中是很是重要的，你须要为最繁忙的数据吸取时间作好准备。下面是MMS中的一个并行视图，它展现了整个复制集的复制操做日志窗口。

9. MongoDB并不清楚数据须要什么样的安全级别。和其余数据库同样，你应该遵循最小特权原则。必须本身配置数据库的安全。不要让全部人都能访问你的数据。打开MongoDB本身自己的安全机制是很是重要的，可是这样也锁定了从任何地方对集群的访问，除非你确实认为本身的客户端进程能够在那里运行。只修改MongoDB进程的默认端口并不能保证安全。

10. 不必修改引擎里面的东西。 除非文档或者MongoDB支持告诉你作一些很是特殊的事情，不然你没有必要直接修改系统集合、本地、管理或者配置数据库。你能够借助于管理命令和shell执行所需的操做，若是数据库并不能按照指望运行，或者某些地方发生了错误，那么成功的钥匙并非试图经过直接操做内部的“bits”强制它运行。你须要熟悉的惟一一个“特殊的”、由系统产生的集合是分析器集合，按期地分析你的查询是确保事情按照指望运行的一个很是好的方式。

---

感谢程显峰对本文的审校。