MongoDB或CouchDB - 适合生产环境吗？
5
我是10gen的CTO（MongoDB的开发者），所以我有点偏见，但我也管理着一些正在使用MongoDB的网站。
businessinsider现在已经在生产中使用mongo超过一年了。他们将其用于从用户和博客文章到站点上的每个图像的所有内容。
shopwiki将其用于一些事情，包括实时分析和缓存层。他们每秒执行超过1000次写入到一个相当大的数据库。
如果您访问mongodb Production Deployments page，您会看到一些正在生产中使用mongo的人。
如果您对生产部署的规模或范围有任何问题，请在我们的用户列表上发布，我们将非常乐意帮助您。
5
BBC和meebo.com在生产中使用CouchDB，我的一个客户也是如此。 以下是其他使用Couch的人的列表：CouchDB in the wild
主要挑战是知道如何组织您的文档并停止以关系数据的方式思考。
1
SourceForge使用MongoDB。可以查看此演示文稿或在这里阅读相关信息。
2
我们将CouchDB作为MySQL的替代品来运行我们的商店（每个商店有70,000个项目，总共有4百万个所有项目的属性，项目之间存在交叉连接）。
我们的目标是：
从主数据库轻松复制到具有不同文档的多个客户端。
快速预计算数据，例如“我拥有多少部件具有这种属性和过滤器，并适合那些条件”
事实是：
- 我们的商店现在比使用MySQL时运行得更快（mysql数据库还需要额外1-3天的预计算（因此更新两次），才能准备好进行产品计数和过滤；CouchDB只需要5个小时，所以我们可以每晚更新产品数据）
- 设置（经过筛选的）数据分发和备份到商店节点非常快捷。
但也有以下问题：
- 理解map/reduce和没有连接的限制相当困难。
- 没有“删除where”或“更新where”等数据操作，除非使用外部程序。
- 复制工作良好，除非出现问题；否则对于初学者来说很难找出原因。
- 如果你不是Linux极客，没有二进制文件的CouchDB安装可能很困难。但是CouchDB社区很有帮助（＃couchdb），幸运的是，市场上有一些公司（cloudant，iriscouch）提供从免费到大型企业的服务。
- CouchDB在不断发展，因此正在进行很多变化（改进），这可能会改变你的工作方式。但基本事物保持稳定。
因此，MySQL作为数据创建和维护的数据库是可靠且易于理解和处理的。 我认为我们不会更改这种使用方式。但我也不想错过CouchDB视图的功能和复制设置的便利性。
生产机器有时会因为配置不当和忘记进行日志轮换（视图构建时间过长或挂起、复制停止）而出现问题，但从未丢失数据，并且总是可以轻松重置。
1
我正在生产环境中使用CouchDB。目前它存储了所有那些不属于原始数据库模式的“可选”字段。现在，我正在考虑将所有数据移动到CouchDB。
我承认这是一个相当冒险的步骤。首先，因为它还没有达到v1.0版本。其次，因为它需要占用很多磁盘空间。根据我的计算，具有相同行数的MySQL数据库与CouchDB文件（带索引）相比，后者大约大30倍。
但我非常确信这会完美地解决问题。6
CouchDB 0.11（于三月底发布）是为了1.0版本而冻结功能的版本。这意味着我们将在1.0版本中保持与当前API的兼容性，因此如果您已经有一段时间没有使用CouchDB，现在是再次了解它的好时机。
我对 MongoDB 一无所知，但来自于 CouchDB FAQ 的回答如下：
CouchDB 是否已经准备好用于生产环境？
是的，请参考 InTheWild 以获取使用 CouchDB 的一部分项目列表。另一个很好的概述可在 CouchDB Case Studies 中找到。
此外，这里还有一些链接：
2
我们在生产中使用couchdb，自从该项目被列入Apache之前就一直使用。
我们将所有可能使用DBMS以及各种非结构化数据存储在其中。个人而言，我很喜欢你可以将各种数据放进去，并使用视图根据情况筛选不需要的内容的方式。
最困难的部分是摆脱DBMS的思维方式。当存储格式更改时，为了安全起见，我们编写了自己的迁移工具，因此这并不是一个问题。
我们还没有遇到任何负面经验，但是也没有在任何重负载下运行设置。我认为，由于我们拥有两个从单个主服务器复制所有写入的从服务器类型，所以事情应该会很顺利。我相当确定我们不必这样做才能正确复制，但这是我们在开始时设置的方式，一直沿用至今。
我们目前在生产环境中使用MongoDB作为缓存层和产品导入及操纵产品数据的存储引擎。我们是一家电子商务公司，管理着超过200万个产品（1亿多个属性），涉及10多个分销商，如果没有MongoDB，这个任务将几近不可能。
3
原文链接