我被困在这两个NoSQL数据库之间 .
在我的项目中，我将在数据库中创建一个数据库 . 例如，我需要一个创建动态表的解决方案 .
因此用户可以创建包含列和行的表 . 我认为MongoDB或CouchDB对此都有好处，但我不确定是哪一个 . 我也需要高效的分页 .
自己问这个问题？您将决定您的数据库选择 .
你需要 master-master 吗？然后是CouchDB . 主要是CouchDB支持主 - 主复制，预期节点长时间断开连接 . MongoDB在这种环境下表现不佳 .
你需要 MAXIMUM R/W throughput 吗？然后是MongoDB
您是否需要终极 single-server durability 因为您只有一台数据库服务器？然后是CouchDB .
您是否在保持疯狂吞吐量的同时存储需要分片的 MASSIVE data 集？然后是MongoDB .
您需要强大的 consistency 数据吗？然后是MongoDB .
你需要高 availability 的数据库吗？然后是CouchDB .
你希望 multi databases 和多表/集合吗？然后是MongoDB
您有 mobile app offline users 并希望将其活动数据同步到服务器？然后你需要CouchDB .
您需要多种 querying 发动机吗？然后是MongoDB
您需要大型 community 才能使用DB吗？然后是MongoDB
请注意MongoDB中稀疏唯一索引的问题 . 我已经打了它，解决方法非常麻烦 .
问题是这个 - 你有一个字段，如果存在，它是唯一的，你希望找到字段不存在的所有对象 . 在Mongo中实现稀疏唯一索引的方式是缺少该字段的对象根本不在索引中 - 它们无法通过该字段上的查询检索 - {$exists: false} 只是不起作用 .
{$exists: false}
我提出的唯一解决方法是使用一个特殊的null值系列，其中空值转换为连接到uuid的特殊前缀（如 null: ） . 这是一个真正令人头痛的问题，因为在编写/查询/阅读时，必须注意转换为空值或从空值转换 . 一个主要的滋扰 .
我从未在MongoDB中使用过服务器端javascript执行（无论如何都不建议），当只有一个Mongo节点时，它们的map / reduce性能很差 . 由于所有这些原因，我现在正在考虑查看CouchDB，也许它更符合我的特定情况 .
顺便说一句，如果有人知道描述稀疏唯一索引问题的相应Mongo问题的链接 - 请分享 .
很老的问题，但它在谷歌的顶部，我不太喜欢我看到的答案，所以这是我自己的 .
Couchdb的功能远远超过开发CouchApps的能力 . 大多数人在经典的3层Web架构中使用CouchDb .
在实践中，大多数人的决定因素是MongoDb允许使用类似SQL的语法进行临时查询，而CouchDb则没有（你必须创建map / reduce视图，即使创建这些视图也会让某些人失望是快速应用程序开发友好 - 它们与存储过程无关） .
为了解决在接受的答案中提出的问题：CouchDb有一个很好的版本控制系统，但这并不意味着它只适用于（或更适合）版本化很重要的地方 . 此外，由于其仅附加性质，couchdb具有重写友好性（写入操作立即返回，同时保证不会丢失任何数据） .
任何人都没有提到的一个非常重要的事情是CouchDb依赖于b树索引 . 这意味着无论您有1“行”还是20亿，查询时间将始终保持在10毫秒以下 . 这是一个改变游戏规则，使CouchDb成为一个低延迟且易读的数据库，这真的不容忽视 .
为了公平和详尽，MongoDb优于CouchDb的优势在于工具和营销 . 他们拥有适用于所有主要语言和平台的一流公民工具，使得入职变得轻松，这增加了他们的特殊查询，使得从SQL过渡变得更加容易 .
CouchDb没有这种级别的工具 - 即使现在有很多库可用 - 但是CouchDb作为HTTP API公开，因此很容易用你喜欢的语言创建一个包装器来与它交谈 . 我个人喜欢这种方法，因为它避免膨胀，并允许你只采取你想要的（界面隔离原则） .
因此，我认为使用其中一个很大程度上是对他们范式的安慰和偏好的问题 . 对于某些人来说CouchDb接近"just fits"但是如果在了解了数据库功能（在详尽的official guide中）之后你没有"hell yeah"时刻，你应该继续前进 .
如果您只是想使用“正确工具的正确工具”，我不鼓励使用CouchDb . 因为你会发现你不能以那种方式使用它而你最终会成为现实生气和写博客文章，如“在CouchDb中加入哪里？”和“交易管理在哪里？” . 事实上，Couchdb是 - 自相矛盾 - 非常透明，但同时需要一种范式转换和改变你处理问题的方式来真正发光（并且真正起作用） .
但是，一旦你完成了它，它真的是值得的 . 我个人需要非常强大的理由或在项目中选择另一个数据库的重大交易，但到目前为止我还没有遇到任何数据库 .
我总结了那篇文章中的答案：
http://www.quora.com/How-does-MongoDB-compare-to-CouchDB-What-are-the-advantages-and-disadvantages-of-each
MongoDB：更好的查询，BSON中的数据存储（更快的访问），更好的数据一致性，多个集合
CouchDB：更好的复制，主从复制和冲突解决，JSON中的数据存储（人类可读，通过REST服务更好地访问），通过map-reduce查询 .
总而言之，MongoDB更快，CouchDB更安全 .
另外：http://nosql.mypopescu.com/post/298557551/couchdb-vs-mongodb
我相信你可以使用Mongo（更熟悉它），并且非常确定你也可以使用沙发 .
两者都是面向文档的（基于JSON），所以没有“列”而是文档中的字段 - 但它们可以是完全动态的 .
他们都这样做你可能想看看其他使用的因素：你关心的其他功能，受欢迎程度等.Google见解，Indeed.com工作帖可以看待受欢迎程度 .
你可以尝试一下我认为你应该可以在5分钟内运行mongo .
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：主 - 主复制
一篇博客文章（2011年10月）由同时尝试过这两篇文章的人撰写，A MongoDB Guy Learns CouchDB对CouchDB的分页发表评论并不那么有用 .
由Kristina Chodorow（MongoDB背后的团队的一部分）的日期（2009年6月）benchmark，
我会去MongoDB .
希望能帮助到你 .
上面的答案使故事复杂化 .
如果您计划拥有移动组件，或者需要桌面用户脱机工作，然后将其工作同步到服务器，则需要使用CouchDB .
如果您的代码只在服务器上运行，那么请使用MongoDB
而已 . 除非您需要CouchDB（非常棒）复制到移动和桌面设备的能力，否则MongoDB目前具有性能，社区和工具优势 .
7 回答
自己问这个问题？您将决定您的数据库选择 .
你需要 master-master 吗？然后是CouchDB . 主要是CouchDB支持主 - 主复制，预期节点长时间断开连接 . MongoDB在这种环境下表现不佳 .
你需要 MAXIMUM R/W throughput 吗？然后是MongoDB
您是否需要终极 single-server durability 因为您只有一台数据库服务器？然后是CouchDB .
您是否在保持疯狂吞吐量的同时存储需要分片的 MASSIVE data 集？然后是MongoDB .
您需要强大的 consistency 数据吗？然后是MongoDB .
你需要高 availability 的数据库吗？然后是CouchDB .
你希望 multi databases 和多表/集合吗？然后是MongoDB
您有 mobile app offline users 并希望将其活动数据同步到服务器？然后你需要CouchDB .
您需要多种 querying 发动机吗？然后是MongoDB
您需要大型 community 才能使用DB吗？然后是MongoDB
请注意MongoDB中稀疏唯一索引的问题 . 我已经打了它，解决方法非常麻烦 .
问题是这个 - 你有一个字段，如果存在，它是唯一的，你希望找到字段不存在的所有对象 . 在Mongo中实现稀疏唯一索引的方式是缺少该字段的对象根本不在索引中 - 它们无法通过该字段上的查询检索 -
{$exists: false}只是不起作用 .我提出的唯一解决方法是使用一个特殊的null值系列，其中空值转换为连接到uuid的特殊前缀（如 null: ） . 这是一个真正令人头痛的问题，因为在编写/查询/阅读时，必须注意转换为空值或从空值转换 . 一个主要的滋扰 .
我从未在MongoDB中使用过服务器端javascript执行（无论如何都不建议），当只有一个Mongo节点时，它们的map / reduce性能很差 . 由于所有这些原因，我现在正在考虑查看CouchDB，也许它更符合我的特定情况 .
顺便说一句，如果有人知道描述稀疏唯一索引问题的相应Mongo问题的链接 - 请分享 .
很老的问题，但它在谷歌的顶部，我不太喜欢我看到的答案，所以这是我自己的 .
Couchdb的功能远远超过开发CouchApps的能力 . 大多数人在经典的3层Web架构中使用CouchDb .
在实践中，大多数人的决定因素是MongoDb允许使用类似SQL的语法进行临时查询，而CouchDb则没有（你必须创建map / reduce视图，即使创建这些视图也会让某些人失望是快速应用程序开发友好 - 它们与存储过程无关） .
为了解决在接受的答案中提出的问题：CouchDb有一个很好的版本控制系统，但这并不意味着它只适用于（或更适合）版本化很重要的地方 . 此外，由于其仅附加性质，couchdb具有重写友好性（写入操作立即返回，同时保证不会丢失任何数据） .
任何人都没有提到的一个非常重要的事情是CouchDb依赖于b树索引 . 这意味着无论您有1“行”还是20亿，查询时间将始终保持在10毫秒以下 . 这是一个改变游戏规则，使CouchDb成为一个低延迟且易读的数据库，这真的不容忽视 .
为了公平和详尽，MongoDb优于CouchDb的优势在于工具和营销 . 他们拥有适用于所有主要语言和平台的一流公民工具，使得入职变得轻松，这增加了他们的特殊查询，使得从SQL过渡变得更加容易 .
CouchDb没有这种级别的工具 - 即使现在有很多库可用 - 但是CouchDb作为HTTP API公开，因此很容易用你喜欢的语言创建一个包装器来与它交谈 . 我个人喜欢这种方法，因为它避免膨胀，并允许你只采取你想要的（界面隔离原则） .
因此，我认为使用其中一个很大程度上是对他们范式的安慰和偏好的问题 . 对于某些人来说CouchDb接近"just fits"但是如果在了解了数据库功能（在详尽的official guide中）之后你没有"hell yeah"时刻，你应该继续前进 .
如果您只是想使用“正确工具的正确工具”，我不鼓励使用CouchDb . 因为你会发现你不能以那种方式使用它而你最终会成为现实生气和写博客文章，如“在CouchDb中加入哪里？”和“交易管理在哪里？” . 事实上，Couchdb是 - 自相矛盾 - 非常透明，但同时需要一种范式转换和改变你处理问题的方式来真正发光（并且真正起作用） .
但是，一旦你完成了它，它真的是值得的 . 我个人需要非常强大的理由或在项目中选择另一个数据库的重大交易，但到目前为止我还没有遇到任何数据库 .
我总结了那篇文章中的答案：
http://www.quora.com/How-does-MongoDB-compare-to-CouchDB-What-are-the-advantages-and-disadvantages-of-each
MongoDB：更好的查询，BSON中的数据存储（更快的访问），更好的数据一致性，多个集合
CouchDB：更好的复制，主从复制和冲突解决，JSON中的数据存储（人类可读，通过REST服务更好地访问），通过map-reduce查询 .
总而言之，MongoDB更快，CouchDB更安全 .
另外：http://nosql.mypopescu.com/post/298557551/couchdb-vs-mongodb
我相信你可以使用Mongo（更熟悉它），并且非常确定你也可以使用沙发 .
两者都是面向文档的（基于JSON），所以没有“列”而是文档中的字段 - 但它们可以是完全动态的 .
他们都这样做你可能想看看其他使用的因素：你关心的其他功能，受欢迎程度等.Google见解，Indeed.com工作帖可以看待受欢迎程度 .
你可以尝试一下我认为你应该可以在5分钟内运行mongo .
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：主 - 主复制
一篇博客文章（2011年10月）由同时尝试过这两篇文章的人撰写，A MongoDB Guy Learns CouchDB对CouchDB的分页发表评论并不那么有用 .
由Kristina Chodorow（MongoDB背后的团队的一部分）的日期（2009年6月）benchmark，
我会去MongoDB .
希望能帮助到你 .
上面的答案使故事复杂化 .
如果您计划拥有移动组件，或者需要桌面用户脱机工作，然后将其工作同步到服务器，则需要使用CouchDB .
如果您的代码只在服务器上运行，那么请使用MongoDB
而已 . 除非您需要CouchDB（非常棒）复制到移动和桌面设备的能力，否则MongoDB目前具有性能，社区和工具优势 .