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

2016-06-01 13:18 1189浏览原创

MongoDB

mongodb的首席解决方案架构师asya kamsky 最近发表了一篇文章，概括了大规模运行mongodb需要知道的10件事。

MongoDB也需要DevOps。MongoDB是一个数据库。和任何其他的数据存储一样，它也需要容量计划、调整、监控和维护。不要因为它很容易安装、入门，同时与关系型数据库相比能够更加自然地满足开发人员的范例就认为MongoDB不需要适当的照顾和喂养。开发时它能在小样本数据集上超快地运行并不意味着你就不需要良好的模式、索引策略以及产品环境所需要的正确的硬件资源了。但是如果你准备的很好，并且理解最佳实践，那么运营大型MongoDB集群就会变得很无聊，而不是令人非常头痛。
成功的MongoDB用户会监控所有的事情，同时会做好增长的准备。在任何数据库系统中跟踪当前的容量以及容量计划都是基本的实践，MongoDB也是如此。你需要知道集群现在能够支撑多少工作，最高使用率时它会处理哪些需求。如果你没有注意到服务器上增长的负载，那么最终会遇到没有足够容量的错误。监控MongoDB可以使用MongoDB管理服务（MMS），通过查看操作计数器（opscounters）图表可视化自己的操作：
你可能并不希望系统随着使用量的增长出现性能扩展障碍。根据大量用户的部署经验，性能瓶颈通常是（按顺序）：
- 应用程序访问模式没有使用最优的模式设计
- 索引不佳或者缺失索引，抑或有太多不必要的索引
- 磁盘较慢/磁盘IOPS不足
- 索引没有足够的RAM
事实证明，在真正的大型部署实践中对性能影响最大的是模式设计与应用程序需求的契合程度。而缺少索引、索引错误或者索引太多则是影响性能的第二大因素。在模式设计非常完美，索引也最优的情况下，磁盘IO吞吐能力就成了下一个限制因素，尤其是写吞吐量。RAM不足会引发很多页错误，同时也会增加磁盘IO的压力。
很多成功的MongoDB用户使用单复制集。太早分片可能是过早优化，并不是每个MongoDB部署都需要分片。分片处理非常特殊的需求，不能不加思索地认为它就是解决“数据库很慢”的最佳方案。如果你的协调模式非常差劲或者有错误索引，那么分片并不能解决问题，相反的你最终会得到一些差劲的协调和差劲的执行碎片。当单台机器或者复制集上的某种特殊资源成为瓶颈，同时基于成本的考虑无法添加更多这种资源的时候才适合分片。你可能需要更多的磁盘IO吞吐量，或者更多的内存，或者更多的存储，再或者更多的并发，这种情况下分片才是有意义的。
即使没有将整个数据库放在内存中，MongoDB依然能够取得非常好的性能。对于MongoDB常见的一个误解是：为了获得更好的性能需要将整个数据库放在内存中。这可能是最错误的一件事情，因为这依赖于集群正在处理的负载的类型。有一些标志和指标能够告诉你：相对于你放到数据库上的负载类型你所拥有的内存数量是否充足。正如你所看到的，随着数据库大小的增长，能够放到内存中的相关部分将会受限于可用物理内存的大小。如果内存的数量不能满足性能需求，那么你将会看到页面错误，随着页面错误率的上升，opcounters最终会低于期望值。
必须将数据写刷新到磁盘。如果磁盘利用率达到了100%，那么处理更多写操作的速度比起现在得不到丝毫的提升。可以通过MMS中的“Background flush average”图表查看将数据文件中的脏页刷新到磁盘花费了多长时间。通过这种趋势你会发现，随着写操作的增长，刷新将花费更多的时间。这种问题可以通过使用更快的磁盘解决，将工作拆分到更多的分片上，或者调整应用程序使之减少写数据的总量。你应该记住：写入的所有内容都会被刷新到磁盘两次——立即刷新到日志同时周期性地刷新到数据文件。将这两种操作分离到不同的物理设备上将会消除它们对可用磁盘IO带宽的竞争。
复制 != 备份。所有人都清楚备份的重要性。但是为什么备份这么重要呢？想必是因为当某些影响所有复制集节点的灾难性事件发生的时候我们可以恢复数据。复制并不是备份的原因是：它并不能让你避免人为错误——例如某些人突然删除了产品数据，或者部署了错误版本的应用程序代码以致于搞乱了部分或者所有数据。必须要有一个能够让我们从这种场景中恢复数据的备份。通过文件系统快照、mongodump或者MMS备份练习数据恢复。第一次从备份恢复产品数据的操作不应该发生在真正的“数据紧急事件”发生的时候。
复制集的健康不仅仅是复制延迟。“复制延迟”仅仅是复制集健康状况的指标之一。关注复制操作日志（oplog）窗口和监控复制延迟一样重要。它表示的是基于现在的写流量完全“滚动”oplog所要花费的时间。换句话说，它指的是将一个复制节点拿下来以后依然能够重新加入集合而不必对所有数据进行重新同步的时间。随着时间的推移，复制操作日志窗口将会随着写负载的变化而浮动。流量高峰时窗口会缩短。这在容量计划中是非常重要的，你需要为最繁忙的数据吸收时间做好准备。下面是MMS中的一个并行视图，它展示了整个复制集的复制操作日志窗口。
MongoDB并不清楚数据需要什么样的安全级别。和其他数据库一样，你应该遵循最小特权原则。必须自己配置数据库的安全。不要让所有人都能访问你的数据。打开MongoDB自己本身的安全机制是非常重要的，但是这样也锁定了从任何地方对集群的访问，除非你确实认为自己的客户端进程可以在那里运行。只修改MongoDB进程的默认端口并不能保证安全。
没必要修改引擎里面的东西。除非文档或者MongoDB支持告诉你做一些非常特殊的事情，否则你没有必要直接修改系统集合、本地、管理或者配置数据库。你可以借助于管理命令和shell执行所需的操作，如果数据库并不能按照期望运行，或者某些地方发生了错误，那么成功的钥匙并不是试图通过直接操作内部的“bits”强制它运行。你需要熟悉的唯一一个“特殊的”、由系统产生的集合是分析器集合，定期地分析你的查询是确保事情按照期望运行的一个非常好的方式。