MongoDB性能调优(最佳实践).docVIP

MongoDB最佳实践 将MongoDB加入到我们的服务支持列表中，是整个团队年初工作计划中的首要任务。但我们感觉如果先添加一项对NoSQL存储的支持，而不是先升级已支持的关系型数据库，可能对用户不太好，毕竟目前的用户都使用关系型数据库。 所以我们决定将引入MongoDB这项工作放到升级MySQL和PostgreSQL之后来做。到目前为止，MySQL 5.5的Beta版已在进行中，而PostgreSQL的9.1 Beta版也将进入流程，因此我们打算在2012年第一季度中应用这两个版本。 由于我们对MongoDB的关注，我们选择性地为几名使用MongoDB的用户提供了技术支持。在这个过程中，我们了解到了很多可能出现问题的地方。所以想借此文与大家分享Engine Yard眼中的MongoDB最佳实践。 如果你的MongoDB是定制化安装的，我们强烈建议你将自己的设置与本文讲到的内容进行对比，并进行必要的设置修改。 通常意义上的NoSQL最佳实践 已有很多文章对NoSQL选型方面进行过讨论。在选择一个数据库产品时，通常可能需要考虑以下因素：读写吞吐量、持久化、一致性以及延迟等。在Nathan Hurst的文章《Visual Guide to NoSQL Systems》中对这些方面都做了详尽的介绍。 数据库的选择是个大问题，本文不打算就这方面深入介绍，但希望读者能够自己去了解这方面的知识。一旦开发者了解得足够多，最后的结论永远都只有一 个：没有任何一个数据库能够满足所有的应用场景。本文内容是基于选择MongoDB作为数据库存储上来说的。Engine Yard在这方面提出了如下四点建议。 全面测试。测试一定要使用切合实际场景的数据，并且需要尽量模拟业务场景的数据操作情况。否则，开发者会发现在上线后的实际场景下，可能导致一些性能瓶颈甚至发现整体架构上的设计缺陷。因此，尽可能使用实际场景的操作使用来进行测试，然后收集足够的测试数据。 千万别以为在关系型数据库上的使用方法可以被直接移植。MongoDB并不支持一些关系型数据库的功能，所以开发者最好先搞清楚MongoDB支持 哪些功能。为了获得更好的性能，开发者最好多看10gen官方建议的文档设计和操作方法。另外，在使用MongoDB前，建议开发者做好对整个架构进行重 构以适用新的存储模型的准备。为了更好地理解数据迁移的代价，建议阅读《The cost ofMigration》一文。 明确数据需要的一致性和可靠性。对MongoDB来说，可靠性不再过度地依赖将数据写入到磁盘的操作，更多的是通过将数据同步到其他节点的方式解决可靠性问题。绝不建议开发者在真实环境中使用没有备份的节点单独工作。这一点很重要，所以建议开发者了解其中的原因。 明确你对EBS的期望。如果你是Engine Yard云平台的用户（AWS EC2），那么应该知道，EBS的性能不太稳定。所以在测试时，你最好收集足够多的EBS设备吞吐数据以做考量。Engine Yard本身并没有对用户在EBS性能上做限制。 MongoDB最佳实践 以下是我们将MongoDB引入到服务支持列表过程中所遵循的原则。 总是使用Replica Sets。Replica Sets通过自动failover机制提供MongoDB的高可用性。在应用中，如primary机器出现故障，那么某一台secondary机器就会通 过选举成为新的primary，整个集群仍然能够提供正常服务。我们的服务不会支持无同步机制的MongoDB布置方案。如果在开发者自己的环境中同步机 制的代价过高，我们建议其使用一些云存储服务。Engine Yard目前已经与MongoHQ和MongoLab都建立了合作关系。开发者可以在合作者页面找到更多这方面的信息。 保持版本更新。保持版本更新很重要，10gen在每个版本中都会修复一些问题，使MongoDB的运行更出色。比如在2.0.x版本 中，MongoDB的存储性能和并发性能就有极大提高，同时还包括索引优化、Bug修复以及compaction命令等一系列改进，以便开发者更方便地扩 展其集群。如果你还在使用1.6.3版本，那就快升级吧。 不要在32位系统上使用MongoDB。在32位机器上，MongoDB只能存储约2.5GB的数据。因为MongoDB在内部实现上是通过内存映 射的方式来提高性能的，所以在32位机器上其内存地址本身就限制了数据容量。在Engine Yard云服务中使用MongoDB，请使用Large instance来部署MongoDB。在实际产品中，我们也只支持64位的MongoDB。 默认开启journaling日志。MongoDB支持在写操作前记录journaling日志来提高节点的可用性。强烈建议在部署时开启 journ