一般意义上的NoSQL最佳实践mongodb
已有不少文章对NoSQL选型方面进行过讨论。在选择一个数据库产品时，一般可能须要考虑如下因素：读写吞吐量、持久化、一致性以及延迟等。在Nathan Hurst的文章《Visual Guide to NoSQL Systems》中对这些方面都作了详尽的介绍。数据库
数据库的选择是个大问题，本文不打算就这方面深刻介绍，但但愿读者可以本身去了解这方面的知识。一旦开发者了解得足够多，最后的结论永远都只有一个：没有任何一个数据库可以知足全部的应用场景。本文内容是基于选择MongoDB做为数据库存储上来讲的。Engine Yard在这方面提出了以下四点建议。网络
全面测试。测试必定要使用切合实际场景的数据，而且须要尽可能模拟业务场景的数据操做状况。不然，开发者会发如今上线后的实际场景下，可能致使一些性能瓶颈甚至发现总体架构上的设计缺陷。所以，尽量使用实际场景的操做使用来进行测试，而后收集足够的测试数据。架构
千万别觉得在关系型数据库上的使用方法能够被直接移植。MongoDB并不支持一些关系型数据库的功能，因此开发者最好先搞清楚MongoDB支持哪些功能。为了得到更好的性能，开发者最好多看10gen官方建议的文档设计和操做方法。另外，在使用MongoDB前，建议开发者作好对整个架构进行重构以适用新的存储模型的准备。为了更好地理解数据迁移的代价，建议阅读《The cost ofMigration》一文。并发
明确数据须要的一致性和可靠性。对MongoDB来讲，可靠性再也不过分地依赖将数据写入到磁盘的操做，更多的是经过将数据同步到其余节点的方式解决可靠性问题。毫不建议开发者在真实环境中使用没有备份的节点单独工做。这一点很重要，因此建议开发者了解其中的缘由。ide
明确你对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都创建了合做关系。开发者能够在合做者页面找到更多这方面的信息。ui
保持版本更新。保持版本更新很重要，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日志来提升节点的可用性。强烈建议在部署时开启journaling日志。注意数据文件的存放位置。在使用时，请确认你的数据文件处于一个持久化存储中（好比/data/mongodb目录）。也可使用非持久化的设备进行数据文件存储，不过你最好当心再当心，由于这可能会对你的集群架构形成影响。推荐使用EBS进行MongoDB的数据文件存储。热数据最好能放在内存中。可以保持热数据（以及索引数据）一直放在内存中，这一点很是重要，它将对整个集群的性能形成影响。若是经过监控发现page fault的数量增长，那么极可能就是热数据量超出了可用内存大小。当热数据量超出了可用内存量时，一般有两种解决方法：增长内存和数据分片。建议先增长内存，再考虑经过数据分片的方式解决。
压力过大升级配置。若是机器负载达到65%，那么应该考虑升级机器配置。在平常使用中，最好保持负载低于65%。同时这也对数据恢复和纵向扩展有影响。当须要升级配置时，AWS建议按下面的顺序来作：Large、Extra Large、High Memory 4XL。而在更高配置的机器上，网络延迟也会更小。
分片需谨慎。分片策略会受数据访问特色的影响，因此在进行数据分片前，最好先理清楚数据的访问特色，并想明白是否确实须要分片。分片字段对性能的影响很是大，因此选择一个好的分片字段是很是重要的。Config节点对整个集群的健康运行是相当重要的，因此一旦你选择使用分片机制，就必定要保证有3个Config节点。永远不要删除Config节点的数据，要确保频繁地对这些数据进行平常备份。若是可能，经过域名来指定节点的地址，好比在/etc/hosts文件中指定相应的本地域名，这能让你在集群配置上更灵活。Config节点的压力很小，但还需运行在64位机器上。千万不要把3个Config节点都放在同一台机器上！
另外，若是你要部署一个分片集群，那么能够向Engine Yard专家服务预定咨询服务。
使用Mongo MMS图形化监控服务。若是你尚未完善的MongoDB监控，能够尝试Mongo MMS。Mongo MMS是10gen官方发布的一个监控服务，能够将集群的各项健康指标以图形化的方式汇总展现。