mongodb应用场景：
MongoDB属于内存型数据库，在需要读性能要求很高的项目中有着比较不错的表现。
可做前段缓存服务器、缓冲数据存储区，同样也可以作为应用系统的存储服务器，例如微博、论坛等应用系统，也可以作为图片存储服务器（分布式）；
在数据写方面，Mongo也支持比较高的写速率（当然这取决于硬件设备）。这比一般使用硬盘存储介质的关系数据库的存储效率要高很多。
但是，非关系数据库会造成大量冗余数据，如果前期的系统设计很粗糙，后期的数据维护将会相当困难。
限制：
实践：
总是使用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日志来提高节点的可用性。强烈建议在部署时开启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官方发布的一个监控服务，可以将集群的各项健康指标以图形化的方式汇总展示。
