MongoDB的首席解决方案架构师Asya Kamsky 最近发表了一篇文章，概括了大规模运行MongoDB需要知道的10件事。 1、MongoDB也需要DevOps。 MongoDB是一个数据库。和任何其他的数据存储一样，它也需要容量计划、调整、监控和维护。不要因为它很容易安装、入门，同时与关系型数据库相比能够更加自然地满足开发人员的范例就认为MongoDB不需要适当的照顾和喂养。开发时它能在小样本数据集上超快地运行并不意味着你就不需要良好的模式、索引策略以及产品环境所需要的正确的硬件资源了。但是如果你准备的很好，并且理解最佳实践，那么运营大型MongoDB集群就会变得很无聊，而不是令人非常头痛。 2、成功的MongoDB用户会监控所有的事情，同时会做好增长的准备。 在任何数据库系统中跟踪当前的容量以及容量计划都是基本的实践，MongoDB也是如此。你需要知道集群现在能够支撑多少工作，最高使用率时它会处理哪些需求。如果你没有注意到服务器上增长的负载，那么最终会遇到没有足够容量的错误。监控MongoDB可以使用MongoDB管理服务（MMS），通过查看操作计数器（opscounters）图表可视化自己的操作：
3、你可能并不希望系统随着使用量的增长出现性能扩展障碍。 根据大量用户的部署经验，性能瓶颈通常是（按顺序）：
事实证明，在真正的大型部署实践中对性能影响最大的是模式设计与应用程序需求的契合程度。而缺少索引、索引错误或者索引太多则是影响性能的第二大因素。在模式设计非常完美，索引也最优的情况下，磁盘IO吞吐能力就成了下一个限制因素，尤其是写吞吐量。RAM不足会引发很多页错误，同时也会增加磁盘IO的压力。 4、很多成功的MongoDB用户使用单复制集。 太早分片可能是过早优化，并不是每个MongoDB部署都需要分片。分片处理非常特殊的需求，不能不加思索地认为它就是解决“数据库很慢”的最佳方案。如果你的协调模式非常差劲或者有错误索引，那么分片并不能解决问题，相反的你最终会得到一些差劲的协调和差劲的执行碎片。当单台机器或者复制集上的某种特殊资源成为瓶颈，同时基于成本的考虑无法添加更多这种资源的时候才适合分片。你可能需要更多的磁盘IO吞吐量，或者更多的内存，或者更多的存储，再或者更多的并发，这种情况下分片才是有意义的。 5、即使没有将整个数据库放在内存中，MongoDB依然能够取得非常好的性能。 对于MongoDB常见的一个误解是：为了获得更好的性能需要将整个数据库放在内存中。这可能是最错误的一件事情，因为这依赖于集群正在处理的负载的类型。有一些标志和指标能够告诉你：相对于你放到数据库上的负载类型你所拥有的内存数量是否充足。正如你所看到的，随着数据库大小的增长，能够放到内存中的相关部分将会受限于可用物理内存的大小。如果内存的数量不能满足性能需求，那么你将会看到页面错误，随着页面错误率的上升，opcounters最终会低于期望值。
|
