查询

理查德是对的，Mongo 将更像 MySQL，其 sql-esque 查询结构。

CouchDB 可以在没有任何 map-reduce 函数的情况下按 ID 进行查询，但是一旦您想要更复杂的查询，是的，您需要在存储在 CouchDB 服务器中的 JavaScript 中编写一个 map（和一个可选的 reduce）函数。如果您对此感兴趣，这个 (
http://www.slideshare.net/gabriele.lana/couchdb-vs-mongodb-2982288) 是我见过的最好的幻灯片，它描述了如何使用示例。

有些人实际上喜欢 CouchDB 的这一方面；我觉得它不必要的复杂。

使用上

Couch 使用基于 HTTP REST 的接口。非常直观，设计得非常好。还允许您编写基于 JavaScript 的应用程序，这些应用程序直接从客户端的浏览器调用数据库（孩子们正在调用 CouchApps；）

Mongo 使用二进制协议。

存储

CouchDB 不会将其数据存储为 JSON；它将它存储为 Erlang 术语（自定义二进制格式）。每次您对数据库进行读写时，它实际上都会对 JSON 进行序列化和反序列化。在 CouchDB 1.2 中，它们包含一个新的 C 解析器，以帮助显着加快速度。

这是我创建 UBJSON 规范 (http://ubjson.org/) 的原因之一来回磁盘以响应查询。如果您有兴趣，Tim Anglade 做了一些有趣的基准测试，只需更改沙发的响应格式，并看到了巨大的性能提升 -

理查德是正确的，Mongo 专门处理 BSON 格式的内容。

性能和一致性

Mongo 开箱即用，速度更快； CouchDB 开箱即用是安全的。

Mongo 对其磁盘上的数据进行就地更新，CouchDB 采用了写时复制/仅追加设计几乎是错误的。

它以fsync'ing所有内容并不断重新复制文档突变（B +路径更新）的数据文件部分为代价，使其具有疯狂的弹性。由于这种核心设计，Couch 将始终（按设计）在单服务器容量中，比 Mongo 更安全。由于 Mongo 的就地编辑，您总是有可能损坏旧数据。

在多服务器配置中，这个问题被冲掉了，您可以只查看您需要/想要的数据库的其他方面。

使用 Mongo，您可以使用 'w' 参数强制它对每次写入进行 fsync，并强制它在您的复制集上复制 1+ 个已写入数据的副本（如果您的配置很大）。根据您的设置，Mongo 是“最终一致”或“一致”-仅取决于您可以等待写入的 ACK 多长时间。

相反，使用 CouchDB，如果您需要在每个服务器的基础上获得更快的性能，您可以在每次写入时关闭 fsync'ing，并让它在刷新之前缓存一些更改。关于远程复制，因为是master-master，双向的，所以没有办法在write返回之前等待一个write复制到所有替代server，因为server无法知道有多少client在等待更改；他们只是解析更改日志并自行消化更改。

复制

CouchDB 是一个分布式多主数据存储。如果您需要许多独立的节点来相互协作，而没有一个是权威（例如在像 CDN 这样的地理分布式系统中），那么您需要这个。

Mongo 以称为“副本集”的分组进行复制；每组允许一个单一的主人。只能写入 master。在分布式系统中，您需要通过“回拨”到主节点来执行所有写入操作。

这通常是第一个可以帮助团队根据他们的应用程序类型决定他们需要哪种 DBMS 的项目；

理查德说的其他一切都恰到好处。

复杂性/难度

大型 CouchDB 部署最终几乎都使用 BigCouch（一个自动分片和复制的 CouchDB 版本，它结合了 Dynamo，将来会被结合到 CouchDB 中）。您还可以创建一个完全连接的复制规则图（A 更新 B、B 更新 C、A 更新 C 并且每个人都相互更新。Huzzah！），具体取决于问题的具体情况。

大型 MongoDB 部署看起来像大型 MySQL 部署，最好留给经验丰富的 Mongo 人员或来自我们维度之外的能量生物。

它并没有那么糟糕，但您将拥有：

副本集由 2 个以上的服务器组成，每个服务器代表您数据的一个分片。 2 个以上的副本集集合，代表您的整个可操作数据集。

然后你有仲裁节点来帮助在主节点失败时在新的主节点中投票。钍en 有新服务器启动的配置节点可以从中提取副本信息，我认为在某些地方也有代理节点。

很多时候，这些较小的服务可以在与数据服务器节点本身相同的硬件上运行，但关键是，有多种类型，您的网络设置并不简单。

就像我说的;扩展 Mongo 很像扩展 MySQL。 Scaling Couch 开箱即用要简单得多，即使您使用 BigCouch 在 Couch 中间完成分片，它仍然相对简单。

总结（如何选择）

我在 G + (
https://plus.google.com/107397941677313236670/posts/LFBB233PKQ1) 上面详细地写了这篇文章，但归结为以下几点：

你需要大师大师吗？然后是 CouchDB。

您需要最大 R/W 吞吐量吗？然后是 MongoDB，讨论结束（您可以像 Blitz.io 那样进行 Couch / Redis 设置，但假设我们在这里只是讨论单个数据库决策，而不是整个基础架构决策）

您是否需要终极的单服务器持久性，因为您将只拥有一台数据库服务器？然后是 CouchDB。

您是否在存储需要分片的海量数据集，同时保持疯狂的吞吐量？然后是MongoDB。

我相信还有更多好的决定因素；如果您好奇，请留下评论，我会将它们附加到列表中。