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

我陷入了这两个NoSQL数据库之间。

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

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

在C，A和P（一致性，可用性和分区容限）中，哪2个对您更重要？快速参考，NoSQL系统可视指南

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

博客文章Cassandra，MongoDB，CouchDB，Redis，Riak，HBase，Membase和Neo4j的比较为每个NoSQL数据库提供了“ 最佳使用 ”方案。引用链接，

• MongoDB：如果您需要动态查询。如果您想定义索引，则不希望映射/归约函数。如果您需要大型DB上的良好性能。如果您想要CouchDB，但是您的数据变化太大，则填满了磁盘。
• CouchDB：用于累积，偶尔更改的数据，在这些数据上运行预定义的查询。版本控制很重要的地方。

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

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

MongoDB Guy Learns CouchDB的博客作者（2011年10月）发表了一篇文章，评论说CouchDB的分页没有什么用处。

由Kristina Chodorow（MongoDB支持的团队的一部分）发布的基准测试日期（2009年6月），

我去MongoDB。

希望能帮助到你。

最重要的是答案使故事复杂化。

1. 如果您计划使用移动组件，或者需要桌面用户脱机工作，然后将其工作同步到服务器，则需要CouchDB。
2. 如果您的代码仅在服务器上运行，请使用MongoDB

而已。除非您需要CouchDB的（出色的）功能复制到移动设备和台式机设备，否则MongoDB目前具有性能，社区和工具优势。

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

除了开发CouchApps的能力之外，Couchdb还有很多其他功能。大多数人在经典的3层Web体系结构中使用CouchDb。

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

要解决公认的答案中提出的问题：CouchDb具有出色的版本控制系统，但这并不意味着它仅适用于（或更适合于）版本控制很重要的地方。另外，由于其“仅追加”性质，couchdb非常适合写操作（写操作会立即返回，同时保证不会丢失任何数据）。

一个没有被任何人提及的非常重要的事情是CouchDb依赖于b树索引。这意味着无论您有1个“行”还是200亿个，查询时间将始终保持在10ms以下。这是一个改变游戏规则的工具，它使CouchDb成为了低延迟和易读的数据库，这确实不容忽视。

公平和详尽地讲，MongoDb与CouchDb相比具有的优势是工具和营销。他们拥有适用于所有主要语言和平台的一流的公民工具，从而使上船变得容易，并且将其添加到其自组织查询中使从SQL的过渡更加容易。

CouchDb没有这种级别的工具-尽管今天有很多可用的库-但是CouchDb作为HTTP API公开，因此很容易用您喜欢的语言创建包装器与之对话。我个人喜欢这种方法，因为它避免了膨胀，并且只允许您采取所需的方法（接口隔离原则）。

因此，我想说，使用它们中的一个主要取决于他们的范例的舒适性和偏好。对于某些人来说，CouchDb方法“很合适”，但是如果在了解了数据库功能之后（在详尽的官方指南中），您没有“大惊小怪”的时刻，那么您应该继续前进。

如果您只想使用“适合正确工作的正确工具”，我不鼓励使用CouchDb。因为您会发现自己不能仅以这种方式使用它，并且最终会感到恼火并撰写博客文章，例如“ CouchDb中的联接在哪里？” 和“交易管理在哪里？”。确实，Couchdb确实是（非常矛盾的）非常透明，但是同时又需要进行范式转换，并且需要改变解决问题的方法以真正发挥作用（并真正起作用）。

但是，一旦完成，它真的会带来回报。我个人需要一个非常有力的理由，或者需要一个重大的项目中断者来选择另一个数据库，但是到目前为止，我还没有遇到任何问题。

你自己问这个问题吗？然后，您将决定数据库的选择。

1. 您需要大师大师吗？然后是CouchDB。CouchDB主要支持主-主复制，该复制可预期节点长时间断开连接。MongoDB在那种环境下做得不好。
2. 您是否需要最大R / W吞吐量？然后是MongoDB
3. 是否只需要一个数据库服务器，您是否需要最终的单服务器持久性？然后是CouchDB。
4. 您是否正在存储需要分片并同时保持疯狂吞吐量的MASSIVE数据集？然后是MongoDB。
5. 您需要强大的数据一致性吗？然后是MongoDB。
6. 您需要数据库的高可用性吗？然后是CouchDB。
7. 您是否希望多个数据库和多个表/集合？然后是MongoDB
8. 您有一个移动应用程序离线用户，并且想要将其活动数据同步到服务器吗？然后，您需要CouchDB。
9. 您是否需要各种各样的查询引擎？然后是MongoDB
10. 您是否需要大型社区来使用DB？然后是MongoDB

我总结了该文章中找到的答案：

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

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

问题是-您有​​一个字段，如果存在，则该字段是唯一的，并且您希望查找该字段不存在的所有对象。在Mongo中实现稀疏唯一索引的方式是，缺少该字段的对象根本不在索引中-无法通过对该字段的查询来检索它们- {$exists: false}完全不起作用。

我想出的唯一解决方法是拥有一个特殊的null值系列，其中一个空值会转换为连接到uuid 的特殊前缀（如null：）。这确实令人头疼，因为在写/查询/读时必须注意转换为空值。一个很大的麻烦。

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

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

我确定您可以使用Mongo（对此比较熟悉），并且也可以肯定也可以使用沙发。

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

他们俩都这样做，您可能想看看要使用的其他因素：您关心的其他功能，受欢迎程度等。

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