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

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

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

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

204219 次浏览
小开

我相信你可以用Mongo(更熟悉它)，你也可以用沙发。

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

它们都能做到，你可能需要考虑其他可以使用的因素:你关心的其他功能，受欢迎程度等等。谷歌的见解，indeed.com的招聘信息是衡量受欢迎程度的方法。

你可以试试，我想你应该可以在5分钟内运行mongo。

小开
最佳答案

C, A &P(一致性，可用性和amp;分区容忍度)哪两个对你来说更重要?快速参考， NoSQL系统可视化指南 . xml

  • MongodB:一致性和分区容忍
  • CouchDB:可用性和分区容忍

在一篇博客文章中，Cassandra vs MongoDB vs CouchDB vs Redis vs Riak vs HBase vs Membase vs Neo4j比较比较了每个NoSQL数据库的“最好的使用”场景。引用链接，

  • MongoDB:如果你需要动态查询。如果您更喜欢定义索引，而不是映射/减少函数。如果您需要在大DB上有良好的性能。如果您想要CouchDB，但数据更改太多，会填满磁盘。
  • CouchDB:用于积累偶尔更改的数据，并在这些数据上运行预定义的查询。版本控制很重要的地方。

Riyad Kalla最近(2012年2月)的全面的比较，

  • MongoDB:主从复制
  • CouchDB:主-主复制

一个尝试过这两种方法的人的博客文章(2011年10月)， a MongoDB Guy learned CouchDB评论说CouchDB的分页没有那么有用。

日期(2009年6月)基准由克里斯蒂娜Chodorow (MongoDB团队的一部分)，

我会选择MongoDB。

希望能有所帮助。

小开

注意MongoDB中稀疏唯一索引的一个问题。我已经击中它，它是非常麻烦的工作。

问题是这样的——你有一个字段，它是唯一的，如果存在，你希望找到所有的对象，该字段不存在。在Mongo中实现稀疏唯一索引的方式是，缺少该字段的对象根本不在索引中-它们不能通过对该字段的查询检索- {$exists: false}不起作用。

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

我从未在MongoDB中使用过服务器端javascript执行(无论如何都不建议)，当只有一个MongoDB节点时，他们的map/reduce性能非常糟糕。由于所有这些原因，我现在正在考虑使用CouchDB，也许它更适合我的特定场景。

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

小开

我总结了在那篇文章中找到的答案:

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更安全。

还:# EYZ0

小开

以上这些答案使故事变得更加复杂。

  1. 如果您计划使用移动组件，或者需要桌面用户离线工作，然后将他们的工作同步到服务器，那么您就需要CouchDB。
  2. 如果你的代码只在服务器上运行，那么就使用MongoDB

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

小开

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

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

在实践中，对于大多数人来说，决定因素是MongoDb允许使用类似SQL的语法进行自组织查询，而CouchDb不允许(你必须创建映射/缩减视图，这让一些人望而却步，尽管创建这些视图对快速应用程序开发是友好的——它们与存储过程无关)。

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

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

公平而详尽地说，MongoDb相对于CouchDb的优势在于工具和营销。他们为所有主要语言和平台提供了一流的公民工具，使入职变得很容易，加上他们的特别查询，使从SQL的过渡更加容易。

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

所以我想说，使用一种或另一种很大程度上是对他们的范式的舒适和偏好的问题。CouchDb方法对于某些人来说“只是适合”，但是如果在了解了数据库特性之后(在详尽的官方指南中)，您还没有“太好了”的时刻，那么您可能应该继续前进。

如果您只是想“用正确的工具做正确的工作”，我不建议使用CouchDb。因为你会发现你不能这样使用它，最后你会很生气，并写博客文章，比如“CouchDb中的连接在哪里?”和“事务管理在哪里?”实际上，Couchdb是非常透明的，但与此同时，它需要进行范式转换，并改变处理问题的方式，这样才能真正发挥作用(并真正发挥作用)。

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

小开

自己问这个问题?你将决定你的DB选择。

  1. 你需要-主吗?然后CouchDB。CouchDB主要支持主-主复制，可以预见节点长时间断开连接。MongoDB在这种环境下做得不好。
  2. 你需要最大读写吞吐量吗?然后MongoDB
  3. 您是否需要最终的单服务器耐久性，因为您只需要一个DB服务器?然后CouchDB。
  4. 您是否存储了一个需要分片的大量的数据集，同时保持疯狂的吞吐量?然后MongoDB。
  5. 你需要强大的一致性数据吗?然后MongoDB。
  6. 你需要高可用性的数据库吗?然后CouchDB。
  7. 你希望多数据库和多表/集合吗?然后MongoDB
  8. 你有一个手机app线下用户，想要同步他们的活动数据到服务器?然后需要CouchDB。
  9. 你需要大量的EYZ0引擎吗?然后MongoDB
  10. 你需要大社区来使用DB吗?然后MongoDB

提交答案