何时在 MongoDB 上使用 CouchDB，反之亦然

When to use CouchDB over MongoDB and vice versa

提问by Luke101

I am stuck between these two NoSQL databases.

我被困在这两个 NoSQL 数据库之间。

In my project I will be creating a database within a database. For example, I need a solution to create dynamic tables.

在我的项目中，我将在数据库中创建一个数据库。例如，我需要一个解决方案来创建动态表。

So users can create tables with columns and rows. I think either MongoDB or CouchDB will be good for this, but I am not sure which one. I will also need efficient paging as well.

因此用户可以创建带有列和行的表。我认为 MongoDB 或 CouchDB 对此都有好处，但我不确定是哪一个。我还需要高效的分页。

采纳答案by user799188

Of C, A & P (Consistency, Availability & Partition tolerance) which 2 are more important to you? Quick reference, the Visual Guide To NoSQL Systems

C、A&P（Consistency、Availability & Partition Tolerance）哪两个对你更重要？快速参考，NoSQL 系统可视化指南

• MongodB : Consistency and Partition Tolerance
• CouchDB : Availability and Partition Tolerance

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

A blog post, Cassandra vs MongoDB vs CouchDB vs Redis vs Riak vs HBase vs Membase vs Neo4j comparisonhas 'Best used' scenarios for each NoSQL database compared. Quoting the link,

一篇博客文章Cassandra 与 MongoDB、CouchDB、Redis、Riak、HBase、Membase 与 Neo4j 的比较对每个 NoSQL 数据库进行了“最佳使用”场景的比较。引用链接，

• MongoDB: If you need dynamic queries. If you prefer to define indexes, not map/reduce functions. If you need good performance on a big DB. If you wanted CouchDB, but your data changes too much, filling up disks.
• CouchDB : For accumulating, occasionally changing data, on which pre-defined queries are to be run. Places where versioning is important.

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

A recent (Feb 2012) and more comprehensive comparisonby Riyad Kalla,

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

• MongoDB : Master-Slave Replication ONLY
• CouchDB : Master-Master Replication

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

A blog post (Oct 2011) by someone who tried both, A MongoDB Guy Learns CouchDBcommented on the CouchDB's paging being not as useful.

尝试了这两种方法的人的博客文章（2011 年 10 月）A MongoDB Guy Learns CouchDB评论说 CouchDB 的分页没有那么有用。

A dated (Jun 2009) benchmarkby Kristina Chodorow(part of team behind MongoDB),

注明日期（2009年6月）基准由克里斯蒂娜·乔多罗（幕后团队的MongoDB的一部分），

I'd go for MongoDB.

我会去 MongoDB。

Hope it helps.

希望能帮助到你。

回答by Ewan Makepeace

The answers above all over complicate 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

1. 如果您计划拥有一个移动组件，或者需要桌面用户离线工作，然后将他们的工作同步到您需要 CouchDB 的服务器。
2. 如果您的代码仅在服务器上运行，则使用 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.

就是这样。除非您需要 CouchDB 的（很棒的）复制到移动和桌面设备的能力，否则 MongoDB 目前具有性能、社区和工具优势。

回答by tobiak777

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.

很老的问题，但它在谷歌之上，我不太喜欢我看到的答案，所以这是我自己的。

There's much more to Couchdb than the ability to develop CouchApps. Most people use CouchDb in a classical 3-tiers web architecture.

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

In practice the deciding factor for most people will be the fact that MongoDb allows ad-hoc querying with a SQL like syntax while CouchDb doesn't (you've got to create map/reduce views which turns some people off even though creating these views is Rapid Application Development friendly - they have nothing to do with stored procedures).

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

To address points raised in the accepted answer : CouchDb has a great versionning system, but it doesn't mean that it is only suited (or more suited) for places where versionning is important. Also, couchdb is heavy-write friendly thanks to its append-only nature (writes operations return in no time while guaranteeing that no data will ever be lost).

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

One very important thing that is not mentioned by anyone is the fact that CouchDb relies on b-tree indexes. This means that whether you have 1 "row" or 20 billions, the querying time will always remain below 10ms. This is a game changer which makes CouchDb a low-latency and read-friendly database, and this really shouldn't be overlooked.

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

To be fair and exhaustive the advantage MongoDb has over CouchDb is tooling and marketing. They have first-class citizen tools for all major languages and platforms making the on-boarding easy and this added to their adhoc querying makes the transition from SQL even easier.

公平而详尽地讲，MongoDb 相对于 CouchDb 的优势在于工具和营销。他们拥有适用于所有主要语言和平台的一流公民工具，使入门变得容易，并且添加到他们的即席查询中使从 SQL 的转换变得更加容易。

CouchDb doesn't have this level of tooling - even though there are many libraries available today - but CouchDb is exposed as an HTTP API and it is therefore quite easy to create a wrapper in your favorite language to talk with it. I personally like this approach as it avoids bloat and allows you to only take what you want (interface segregation principle).

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

So I'd say using one or the other is largely a matter of comfort and preference with their paradigms. CouchDb approach "just fits", for certain people, but if after learning about the database features (in the exhaustive official guide) you don't have your "hell yeah" moment, you should probably move on.

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

I'd discourage using CouchDb if you just want to use "the right tool for the right job". because you'll find out that you can't just use it that way and you'll end up being pissed and writing blog posts such as "Where are joins in CouchDb ?" and "Where is transaction management ?". Indeed Couchdb is - paradoxically - very transparent but at the same time requires a paradigm shift and a change in the way you approach problems to really shine (and really work).

如果您只想使用“正确工作的正确工具”，我不鼓励使用 CouchDb。因为你会发现你不能就这样使用它，你最终会生气并写博客文章，比如“CouchDb 中的连接在哪里？” 和“交易管理在哪里？”。事实上，Couchdb 是——矛盾的是——非常透明，但同时需要范式转变和你处理问题的方式的改变才能真正发光（并且真正起作用）。

But once you've done that it really pays off. I'd personally need very strong reasons or a major deal breaker on a project to choose another database, but so far I haven't met any.

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

回答by Somnath Muluk

Ask this questions yourself? And you will decide your DB selection.

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

1. Do you need master-master? Then CouchDB. Mainly CouchDB supports master-master replication which anticipates nodes being disconnected for long periods of time. MongoDB would not do well in that environment.
2. Do you need MAXIMUM R/W throughput? Then MongoDB
3. Do you need ultimate single-server durabilitybecause you are only going to have a single DB server? Then CouchDB.
4. Are you storing a MASSIVE dataset that needs sharding while maintaining insane throughput? Then MongoDB.
5. Do you need strong consistencyof data? Then MongoDB.
6. Do you need high availabilityof database? Then CouchDB.
7. Are you hoping multi databasesand multi tables/ collections? Then MongoDB
8. You have a mobile app offline usersand want to sync their activity data to a server? Then you need CouchDB.
9. Do you need large variety of queryingengine? Then MongoDB
10. Do you need large communityto be using DB? Then MongoDB

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

回答by Alexis Dufrenoy

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

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

MongoDB：更好的查询，BSON中的数据存储（更快的访问），更好的数据一致性，多个集合

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.

CouchDB：更好的复制，主对主复制和冲突解决，JSON 中的数据存储（人类可读，通过 REST 服务更好地访问），通过 map-reduce 查询。

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

所以总而言之，MongoDB 更快，CouchDB 更安全。

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

另外：http: //nosql.mypopescu.com/post/298557551/couchdb-vs-mongodb

回答by mark

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

请注意 MongoDB 中稀疏唯一索引的问题。我已经成功了，解决方法非常麻烦。

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 - {$exists: false}just does not work.

问题是 - 您有一个字段，如果存在该字段是唯一的，并且您希望找到该字段不存在的所有对象。在 Mongo 中实现稀疏唯一索引的方式是，缺少该字段的对象根本不在索引中 - 它们无法通过对该字段的查询来检索 -{$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.

我想出的唯一解决方法是使用特殊的 null 值系列，其中空值被转换为连接到 uuid的特殊前缀（如null:）。这是一个真正令人头疼的问题，因为在写入/查询/读取时必须注意转换为空值/从空值转换。一个大麻烦。

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.

我从未在 MongoDB 中使用过服务器端 javascript 执行（无论如何都不建议这样做），并且当只有一个 Mongo 节点时，它们的 map/reduce 性能很差。由于所有这些原因，我现在正在考虑检查 CouchDB，也许它更适合我的特定场景。

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

顺便说一句，如果有人知道描述稀疏唯一索引问题的相应 Mongo 问题的链接 - 请分享。

回答by dm.

I'm sure you can with Mongo (more familiar with it), and pretty sure you can with couch too.

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

Both are documented oriented (JSON-based) so there would be no "columns" but rather fields in documents -- but they can be fully dynamic.

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

They both do it you may want to look at other factors on which to use: other features you care about, popularity, etc. Google insights, indeed.com job posts would be ways to look at popularity.

他们都这样做，您可能想查看其他要使用的因素：您关心的其他功能、受欢迎程度等。Google 见解、deide.com 职位发布将是查看受欢迎程度的方法。

You could just try it i think you should be able to have mongo running in 5 minutes.

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