已经有很多关于 NoSQL 选择的文章了。影响你选择数据库的因素有：读/写操作的吞吐量，持久性，一致性，延迟性等等。Nathan Hurst 的文章“Visual Guide to NoSQL System” 很好的总结了这一点。
选择合适的NoSQL数据库并不是本文要讨论的内容，但是请你在使用NoSQL前做一些调查。没有一个数据库可以适合所有情况。这篇文章假设你选择了mongoDB。
NoSQL 通用的最佳实践
1. 彻底的测试
模拟你的生产环境，包括流量来进行测试。假如你的测试环境不能达到生产环境的压力，你将无法发现性能瓶颈和架构缺陷。
2. RDBMS 并不一定能迁移到 NoSQL
任何在RDBMS上工作的好好的东西并不一定能在MongoDB上工作。所以请你做好心理准备，仔细对比数据库的功能。为了更好的性能，你应该根据 10gen 的建议来设计你的文档和查询。你的应用也许需要重新架构以便于迁移到非关系型数据库。
3. 考虑你的数据的一致性和持久性需求
这一点很重要！MongoDB通过多实例备份来提解决数据持久性问题。我们不推荐你在生产环境中只使用一个MongoDB实例。你必须理解为什么要这么做。
MongoDB 最佳实践
1. 始终启用备份
备份能保证你应用的高可用性。假如你的一个节点down了，第二节点可以迅速启用，你的应用不会中断。
2. 使用最新版本
10gen在不断的发布更新，特别是2.0.x包含了很高的性能提升和并行改进，索引改进和bug修复。如果你还在使用 1.6.3的话，你应该尽快升级。
3. 不要在32位的系统上跑MongoDB
MongoDB在32位系统上有“2.5GB数据限制”。它的存储引擎使用内存映射来读取文件以获得更好的性能。这个功能依赖于内存寻址，而32位系统的内存不能超过4GB。
4. 默认开启日志
MongoDB支持数据库操作的提前日志（write-ahead journaling）。这个功能有助于灾难恢复。
5. 注意你数据文件的位置
你应该保证你的MongoDB的数据文件是存储在物理驱动器上，例如 /data/mongodb。当然你也可以使用虚拟的驱动器，但是必须非常小心。因为它有可能会影响到你的集群架构。我们建议你使用 Amazon EBS 来存放你的数据库文件。
6. 保证足够大的内存
为了保证整个集群的性能，你要确保整个所有MongoDB的工作实例（working set）包括索引可以完全装入内存。如果你发现“page faults”的概率在增加，很有可能mongoDB的数据量超出了你的内存。在这种情况下你有两种选择：加内存，或者创建分片集群（Sharding）。我们建议你先考虑加内存。
7. 保持 65% 以内的压力
如果你发现你的集群压力达到了65%，那么你应该考虑扩大你的集群了。通常，你应该保证数据库压力低于65%。
8. 特别小心分片集群
分片集群需要你充分理解你应用的数据访问方式。你应该充分了解MongoDB的分片工作方式，并且确认你确实需要这个功能。还有，选择一个分片钥匙（sharding key）是对于性能也是很重要的。
配置服务器对于一个集群的健康也是很重要的。在分片集群的环境中，你必须有三台配置服务器。永远不要删除配置服务器的数据，时常备份这些数据。这些配置服务器也需要64位的环境。还有，不要把三台配置服务器放在同一台机器上！
9. 使用 Mongo MMS 来图形化的监控你的数据库
如果你还没有使用 Mongo MMS的话，我强烈推荐这个工具。10gen 正在大力开发这个产品。它提供了一个非常友好的可视化的界面来监控你的MongoDB集群。
10. MongoDB 资源
技术总是在不断进步，你需要市场关注这些信息：
- Documentation: http://www.mongodb.org/display/DOCS/Home
- Google Group: http://groups.google.com/group/mongodb-user
- Bugs: https://jira.mongodb.org
- Blog: http://blog.mongodb.org/
原文发布时间为：2012-03-01
本文来自云栖社区合作伙伴“Linux中国”
