何时在 MongoDB 上使用 CouchDB，反之亦然
我被困在这两个 NoSQL 数据库之间。
在我的项目中，我将在数据库中创建一个数据库。例如，我需要一个创建动态表的解决方案。
因此用户可以创建具有列和行的表。我认为 MongoDB 或 CouchDB 都会对此有好处，但我不确定哪一个。我也需要有效的分页。
C, A & P（一致性、可用性和分区容限）哪两个对您来说更重要？快速参考，Visual Guide To NoSQL Systems
MongoDB：一致性和分区容错
CouchDB：可用性和分区容错
在一篇博文中，Cassandra vs MongoDB vs CouchDB vs Redis vs Riak vs HBase vs Membase vs Neo4j comparison 为每个比较的 NoSQL 数据库提供了“最佳使用”方案。引用链接，
MongoDB：如果您需要动态查询。如果您更喜欢定义索引，而不是 map/reduce 函数。如果您需要在大型数据库上获得良好的性能。如果您想要 CouchDB，但您的数据更改太多，会填满磁盘。
CouchDB ：用于累积、偶尔更改的数据，在这些数据上运行预定义的查询。版本控制很重要的地方。
Riyad Kalla 最近（2012 年 2 月）和更多comprehensive comparison，
MongoDB：仅主从复制
CouchDB：主-主复制
A MongoDB Guy Learns CouchDB 的一篇博文（2011 年 10 月）由尝试过这两种方法的人评论说 CouchDB 的分页没有那么有用。
Kristina Chodorow（MongoDB 背后的团队成员）的日期（2009 年 6 月）benchmark，
我会选择 MongoDB。
希望能帮助到你。
最重要的答案使故事复杂化。
如果您计划拥有一个移动组件，或者需要桌面用户离线工作，然后将他们的工作同步到服务器，那么您需要 CouchDB。如果您的代码仅在服务器上运行，请使用 MongoDB
而已。除非您需要 CouchDB 的（很棒的）复制到移动和桌面设备的能力，否则 MongoDB 目前具有性能、社区和工具优势。
非常老的问题，但它在谷歌之上，我不太喜欢我看到的答案，所以这是我自己的。
Couchdb 的功能远不止开发 CouchApps 的能力。大多数人在经典的 3 层 Web 架构中使用 CouchDb。
实际上，对于大多数人来说，决定因素是 MongoDb 允许使用类似 SQL 的语法进行临时查询，而 CouchDb 则不允许（您必须创建 map/reduce 视图，即使创建这些视图也会让一些人感到厌烦是快速应用程序开发友好的 - 它们与存储过程无关）。
为了解决在接受的答案中提出的问题：CouchDb 有一个很棒的版本控制系统，但这并不意味着它只适合（或更适合）版本控制很重要的地方。此外，couchdb 由于其仅附加特性（写入操作立即返回，同时保证不会丢失任何数据），因此对大量写入友好。
任何人都没有提到的一件非常重要的事情是 CouchDb 依赖于 b-tree 索引这一事实。这意味着无论你有 1 个“行”还是 200 亿个，查询时间都将始终保持在 10ms 以下。这是一个游戏规则改变者，它使 CouchDb 成为一个低延迟且易于阅读的数据库，这一点确实不容忽视。
公平地说，MongoDb 相对于 CouchDb 的优势在于工具和营销。他们拥有适用于所有主要语言和平台的一流公民工具，使入门变得容易，这添加到他们的临时查询中，使从 SQL 的过渡更加容易。
CouchDb 没有这种级别的工具——即使现在有很多库可用——但是 CouchDb 是作为 HTTP API 公开的，因此很容易用你喜欢的语言创建一个包装器来与之交谈。我个人喜欢这种方法，因为它避免了臃肿并允许你只取你想要的东西（接口隔离原则）。
所以我想说使用其中一个在很大程度上是他们的范式的舒适和偏好问题。对于某些人来说，CouchDb 方法“恰到好处”，但是如果在了解了数据库功能（在详尽的 official guide 中）之后，您还没有“该死的”时刻，您可能应该继续前进。
如果您只想使用“正确的工具完成正确的工作”，我不鼓励使用 CouchDb。因为你会发现你不能那样使用它，你最终会生气并写博客文章，例如“CouchDb 中的连接在哪里？”和“事务管理在哪里？”。事实上，Couchdb - 矛盾的是 - 非常透明，但同时需要范式转变和处理问题的方式的改变才能真正发光（并且真正起作用）。
但是一旦你做到了，它真的会得到回报。我个人需要非常充分的理由或项目的重大交易破坏者来选择另一个数据库，但到目前为止我还没有遇到任何问题。
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. 几乎所有数据库不都是这样吗？这种措辞方式暗示了其他情况。
自己问这个问题？您将决定您的数据库选择。
你需要大师大师吗？然后是 CouchDB。主要是 CouchDB 支持 master-master 复制，它预计节点会长时间断开连接。 MongoDB 在那种环境中表现不佳。您需要最大的 R/W 吞吐量吗？那么 MongoDB 你是否需要终极的单服务器持久性，因为你只需要一个数据库服务器？然后是 CouchDB。您是否正在存储需要分片同时保持疯狂吞吐量的海量数据集？然后是 MongoDB。您需要数据的强一致性吗？然后是 MongoDB。您需要数据库的高可用性吗？然后是 CouchDB。您希望多数据库和多表/集合吗？那么 MongoDB 你有一个移动应用离线用户，想要将他们的活动数据同步到服务器？然后你需要 CouchDB。您需要种类繁多的查询引擎吗？那么 MongoDB 你需要大型社区来使用数据库吗？然后是 MongoDB
我总结了在那篇文章中找到的答案：
MongoDB：更好的查询、BSON 中的数据存储（更快的访问）、更好的数据一致性、多个集合
CouchDB：更好的复制，具有主到主复制和冲突解决，JSON 中的数据存储（人类可读，通过 REST 服务更好地访问），通过 map-reduce 进行查询。
所以总而言之，MongoDB 更快，CouchDB 更安全。
另外：http://nosql.mypopescu.com/post/298557551/couchdb-vs-mongodb
请注意 MongoDB 中稀疏唯一索引的问题。我已经成功了，解决方法非常麻烦。
问题是 - 你有一个字段，如果存在它是唯一的，并且你希望找到该字段不存在的所有对象。在 Mongo 中实现稀疏唯一索引的方式是，缺少该字段的对象根本不在索引中 - 它们无法通过对该字段的查询来检索 - {$exists: false} 只是不起作用。
我想出的唯一解决方法是有一个特殊的 null 系列值，其中一个空值被转换为一个特殊的前缀（如 null:）连接到一个 uuid。这是一个真正令人头疼的问题，因为在写入/查询/读取时必须注意与空值之间的转换。一个大麻烦。
我从未在 MongoDB 中使用过服务器端 javascript 执行（无论如何不建议这样做），并且当只有一个 Mongo 节点时，它们的 map/reduce 性能很差。由于所有这些原因，我现在正在考虑查看 CouchDB，也许它更适合我的特定场景。
顺便说一句，如果有人知道描述稀疏唯一索引问题的相应 Mongo 问题的链接 - 请分享。
national id number 字段的 client 表，根据定义，该字段是唯一的 - 但可能是未知的（也许客户是外国人）。
我相信你可以使用 Mongo（更熟悉它），并且很确定你也可以使用沙发。
两者都是面向文档的（基于 JSON 的），因此文档中没有“列”而是字段——但它们可以是完全动态的。
他们都这样做，您可能想查看其他要使用的因素：您关心的其他功能、受欢迎程度等。谷歌洞察力、indeed.com 职位发布将是查看受欢迎程度的方法。
您可以尝试一下，我认为您应该能够在 5 分钟内运行 mongo。
关注公众号
不定期副业成功案例分享
