何时使用 CouchDB 而不是 MongoDB，反之亦然

我相信你可以用 Mongo（更熟悉它），而且很确定你也可以用沙发。

两者都是面向文档的（基于 JSON），因此文档中没有“列”，而是字段——但它们可以是完全动态的。

它们都这样做，您可能需要查看要使用的其他因素：您关心的其他功能、受欢迎程度等。谷歌洞察和 indeed.com 招聘信息将是查看受欢迎程度的方法。

你可以试试，我认为你应该能够在 5 分钟内运行 mongo。

在C，A和P（一致性，可用性和分区容错）中，哪2个对你来说更重要？快速参考，NoSQL 系统可视化指南

• MongodB：一致性和分区容错
• CouchDB：可用性和分区容错

一篇博文，Cassandra vs MongoDB vs CouchDB vs Redis vs Riak vs HBase vs Membase vs Neo4j 比较，比较了每个 NoSQL 数据库的“最佳使用”方案。引用链接，

• MongoDB：如果您需要动态查询。如果您更喜欢定义索引，而不是 map/reduce 函数。如果您需要在大型数据库上获得良好的性能。如果你想要 CouchDB，但你的数据变化太大，填满了磁盘。
• CouchDB ：用于累积、偶尔更改的数据，并对其运行预定义的查询。版本控制很重要的地方。

最近（2012 年 2 月）Riyad Kalla 进行的更全面的比较，

• MongoDB：仅限主从复制
• CouchDB ： Master-Master 复制

2011 年 10 月，一位尝试过这两种方法的人发表了一篇博文，A MongoDB Guy Learns CouchDB 评论说 CouchDB 的分页没有那么有用。

Kristina Chodorow（MongoDB团队的一部分）的日期（2009年6月）基准测试，

我会选择MongoDB。

Be aware of an issue with sparse unique indexes in MongoDB. I've hit it and it is extremely cumbersome to workaround.

The problem is this - you have a field, which is unique if present and you wish to find all the objects where the field is absent. The way sparse unique indexes are implemented in Mongo is that objects where that field is missing are not in the index at all - they cannot be retrieved by a query on that field - just does not work. {$exists: false}

The only workaround I have come up with is having a special null family of values, where an empty value is translated to a special prefix (like null:) concatenated to a uuid. This is a real headache, because one has to take care of transforming to/from the empty values when writing/quering/reading. A major nuisance.

I have never used server side javascript execution in MongoDB (it is not advised anyway) and their map/reduce has awful performance when there is just one Mongo node. Because of all these reasons I am now considering to check out CouchDB, maybe it fits more to my particular scenario.

BTW, if anyone knows the link to the respective Mongo issue describing the sparse unique index problem - please share.

I summarize the answers found in that article:

http://www.quora.com/How-does-MongoDB-compare-to-CouchDB-What-are-the-advantages-and-disadvantages-of-each

MongoDB: Better querying, data storage in BSON (faster access), better data consistency, multiple collections

CouchDB: Better replication, with master to master replication and conflict resolution, data storage in JSON (human-readable, better access through REST services), querying through map-reduce.

So in conclusion, MongoDB is faster, CouchDB is safer.

Also: http://nosql.mypopescu.com/post/298557551/couchdb-vs-mongodb

The answers above all overcomplicate the story.

1. If you plan to have a mobile component, or need desktop users to work offline and then sync their work to a server you need CouchDB.
2. If your code will run only on the server then go with MongoDB

That's it. Unless you need CouchDB's (awesome) ability to replicate to mobile and desktop devices, MongoDB has the performance, community and tooling advantage at present.

Very old question but it's on top of Google and I don't quite like the answers I see so here's my own.

Couchdb 的功能远不止开发 CouchApp 的能力。大多数人在经典的 3 层 Web 架构中使用 CouchDb。

在实践中，大多数人的决定性因素是MongoDb允许使用类似SQL的语法进行临时查询，而CouchDb则不允许（您必须创建map/reduce视图，即使创建这些视图对快速应用程序开发友好，也会使一些人望而却步 - 它们与存储过程无关）。

为了解决公认的答案中提出的问题：CouchDb 有一个很棒的版本控制系统，但这并不意味着它只适合（或更适合）版本控制很重要的地方。此外，couchdb 由于其仅追加的性质（写入操作立即返回，同时保证不会丢失任何数据），因此对重度写入友好。

没有人提到的一件非常重要的事情是 CouchDb 依赖于 b 树索引。这意味着无论您有 1 个“行”还是 200 亿，查询时间都将始终保持在 10 毫秒以下。这是一个游戏规则的改变者，使 CouchDb 成为一个低延迟和易于读取的数据库，这真的不应该被忽视。

公平地说，MongoDb 相对于 CouchDb 的优势在于工具和营销。他们拥有适用于所有主要语言和平台的一流公民工具，使入门变得容易，再加上他们的临时查询，使从 SQL 的过渡变得更加容易。

CouchDb 没有这种级别的工具——尽管现在有很多可用的库——但 CouchDb 是作为 HTTP API 公开的，因此很容易用你喜欢的语言创建一个包装器来与它通信。我个人喜欢这种方法，因为它避免了膨胀，并允许你只拿你想要的东西（接口隔离原则）。

所以我想说，使用其中之一很大程度上取决于对他们的范式的舒适和偏好。对于某些人来说，CouchDb 方法“正好适合”，但如果在了解了数据库功能（在详尽的官方指南中）之后，您没有“地狱是”的时刻，您可能应该继续前进。

如果您只想使用“正确的工具完成正确的工作”，我不建议使用 CouchDb。因为你会发现你不能只是这样使用它，你最终会生气并写博客文章，例如“CouchDb 中的连接在哪里？”和“事务管理在哪里？”。事实上，自相矛盾的是，Couchdb 非常透明，但同时需要范式转变和处理问题的方式的改变才能真正闪耀（并真正发挥作用）。

但是一旦你这样做了，它就真的得到了回报。我个人需要非常有力的理由或一个项目的重大交易破坏者来选择另一个数据库，但到目前为止我还没有遇到任何理由。

2022 年 12 月更新：由于这篇文章仍然获得很多浏览量，我觉得重要的是要告诉人们我最近转向使用 MongoDB 作为我的日常驱动程序，同时将 CouchDB 保留在我的工具带中，以用于此数据库更有意义的特殊情况（即不需要视图的情况）。选择这个原因有很多，最重要的原因是：

• 性能：虽然预计算索引是一项强大的资产，但 CouchDB 的主要限制是其 QueryServer 架构。每次更新文档时，它都必须由每个视图进行序列化和处理（即使这是以延迟方式发生的，即在访问视图时）。但更重要的是，每次更新视图时（例如，为作为新功能实现的一部分添加的新字段添加过滤逻辑），数据库的所有文档都必须发送到视图。当您的数据库中有数百万个文档时，这变得很重要。你开始担心更新你的观点的影响，它变成了一种分心。如果您决定为每种数据类型创建一个数据库来绕过此限制，则您将无法在所有文档中映射/缩减，因为视图的作用域是每个数据库的。MongoDB通过将文档分割为集合（即数据类型）来避免这种情况，因此在更新索引时，仅影响数据库数据的子集。此外，MongoDB使用二进制格式，使这些操作的性能更高（而CouchDB使用以纯文本形式发送到视图服务器的JSON）。如果您不设计需要大规模运营（数十万或更多日用户）的产品，这一点可能并不重要。
• MongoDB提供的工具是全面而成熟的，无论我们谈论的是各种编程语言的官方支持的驱动程序，还是与IDE的集成。
• 高级查询：开箱即用的各种数据类型和高级查询功能（地理类型、GridFS 允许将任意大小的文件直接存储在数据库中等）。轻松访问强大的查询聚合功能使我意识到 CouchDB 在多大程度上抑制了我的工作效率。
• 无缝支持重新分片：使用 MongoDB 进行重新分片很容易，而使用 CouchDB 手动移动文件是一项危险的操作。
• 许多其他小物品可以提高生活质量并真正加起来。

我一直是 CouchDB 的忠实粉丝，但我不得不承认，在生产力和生活质量改善方面，迁移到 MongoDB 作为日常驱动程序感觉很像回到文明。现在，我只考虑将 CouchDB 用于键值存储场景（其中不需要 map-reduce 视图，只需要通过键获取文档 - CouchDB 在这方面大放异彩），以及需要像每个用户一样的数据库的高级情况（例如，支持设备之间的高级同步）。

我看到 MongoDB 的唯一缺点是它消耗大量内存，以至于我无法将其安装在规格较低的开发机器上（相比之下，couchdb 是在启动时启动的，我没有注意到，几乎不消耗任何资源）。但是，考虑到节省的时间和提供的功能，我觉得这是值得的。

作为一个长期的 CouchDB 用户，我在 MongoDB 中看到的价值与推广 MongoDB 的其他答案中突出显示的项目完全不同，所以我觉得提供这个更新对我来说很重要（老实说，当我想起这篇文章时，也是出于理智）。与我一直使用的 SQL 产品和 ORM 相比，CouchDB 当时给我带来了相当大的生产力提升，当时有很多关于 MongoDB 可靠性的恐怖故事流传。

然而，截至目前，我可能有的少数担忧（互联网人可能给予了不成比例的重视——它们基本上都归结为默认值，其可靠性权衡可能会在许多情况下让新用户感到惊讶）不再成立。

在这一点上，作为一个长期的 CouchDB 用户，我可以很好地比较这两种产品，我会向需要为他们的 Web 应用程序提供高效且可扩展的软件开发体验的人推荐 MongoDB，并建议只选择 CouchDB 来满足特定需求。

CouchDB 在当时有动力，这可能影响了我的看法，但开发停滞不前，很长一段时间没有引入有意义的功能，否则它可能会在生活质量方面赶上 MongoDB。我认为有两个可能的原因：现在中止的 CouchDB 重写方式在很长一段时间内转移了资源，也许是早期的架构决策（例如查询服务器架构）很可能从一开始就限制了它的未来。这些方面似乎都不是核心团队的首要任务。

我并不完全后悔选择CouchDB，因为它对我有很大的帮助，它教会我的思维方式非常有帮助，允许我在MongoDB中编写高性能代码（与使用CouchDB解决业务问题所必须遵守的纪律相比，在MongoDB中编写高性能代码是一件轻而易举的事）。但是，如果我今天必须再做一次，我会更快地过渡到MongoDB作为我的日常驱动程序。我通常很擅长在技术出现时挑选获胜的马，但这次我似乎没有那么好地玩这个游戏。希望这会有所帮助。

自己问这个问题？您将决定您的数据库选择。

1. 你需要master-master吗？然后是 CouchDB。CouchDB主要支持主-主复制，预计节点会长时间断开连接。MongoDB在这种环境中表现不佳。
2. 您需要最大 R/W 吞吐量吗？然后是MongoDB
3. 您是否需要最终的单服务器持久性，因为您只有一台数据库服务器？然后是 CouchDB。
4. 您是否存储了一个需要分片的海量数据集，同时保持疯狂的吞吐量？然后是MongoDB。
5. 您是否需要强大的数据一致性？然后是MongoDB。
6. 您需要数据库的高可用性吗？然后是 CouchDB。
7. 您是否希望多数据库和多表/集合？然后是MongoDB
8. 您有一个移动应用程序离线用户，并希望将其活动数据同步到服务器？然后你需要 CouchDB。
9. 您需要种类繁多的查询引擎吗？然后是MongoDB
10. 您是否需要大型社区来使用 DB？然后是MongoDB