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

Question

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

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

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

Answer 1

C,A&P(一致性,可用性和分区容差)哪两个对您更重要？快速参考,NoSQL系统的可视化指南

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

一篇博客文章,Cassandra vs MongoDB vs CouchDB vs Redis vs Riak vs HBase vs Membase vs Neo4j比较每个NoSQL数据库的" 最佳使用 "场景比较.引用链接,

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

Riyad Kalla 最近(2012年2月)和更全面的比较,

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

一篇博客文章(2011年10月)是一位尝试过这两篇文章的人,A MongoDB Guy Learns CouchDB对CouchDB的分页发表评论并不那么有用.

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

我会去MongoDB.

希望能帮助到你.

Answer 2

上面的答案使故事复杂化.

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

而已.除非您需要CouchDB(非常棒)复制到移动和桌面设备的能力,否则MongoDB目前具有性能,社区和工具优势.

Answer 3

很老的问题,但它在谷歌的顶部,我不太喜欢我看到的答案,所以这是我自己的.

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方法"恰到好处",但如果在了解了数据库功能(在详尽的官方指南中)之后,你没有"地狱耶"的那一刻,那么你应该继续前进.

如果您只是想使用"正确工具的正确工具",我不鼓励使用CouchDb.因为你会发现你不能以那种方式使用它,你最终会生气并写博客帖子,例如"CouchDb中的哪些联接？" 和"交易管理在哪里？".事实上,Couchdb是 - 自相矛盾 - 非常透明,但同时需要一种范式转换,以及改变你处理问题的方式来真正发光(并且真正起作用).

但是一旦你做完了,它真的会有回报.我个人需要非常强大的理由或在项目上选择另一个数据库的重大交易,但到目前为止我还没有遇到任何数据库.

Answer 4

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

1. 你需要高手吗？然后是CouchDB.主要是CouchDB支持主 - 主复制,预计节点会长时间断开连接.MongoDB在这种环境下表现不佳.
2. 您需要MAXIMUM R/W吞吐量吗？然后是MongoDB
3. 您是否需要最终的单服务器持久性,因为您只需要一台数据库服务器？然后是CouchDB.
4. 您是否在保持疯狂吞吐量的同时存储需要分片的MASSIVE数据集？然后是MongoDB.
5. 您需要强大的数据一致性吗？然后是MongoDB.
6. 您需要高可用性的数据库吗？然后是CouchDB.
7. 您希望多数据库和多表/集合吗？然后是MongoDB
8. 您有移动应用离线用户,并希望将其活动数据同步到服务器？然后你需要CouchDB.
9. 你需要各种各样的查询引擎吗？然后是MongoDB
10. 你需要大型社区来使用数据库吗？然后是MongoDB

Answer 5

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

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

Answer 6

请注意MongoDB中稀疏唯一索引的问题.我已经打了它,解决方法非常麻烦.

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

我提出的唯一解决方法是使用一个特殊的null值系列,其中一个空值被转换为一个特殊的前缀(如null:)连接到一个uuid.这是一个真正的头痛,因为在编写/查询/阅读时,必须注意转换为空值或从空值转换.一个主要的滋扰.

我从来没有在MongoDB中使用服务器端javascript执行(无论如何都不建议),当只有一个Mongo节点时,它们的map/reduce性能很差.由于所有这些原因,我现在正在考虑查看CouchDB,也许它更符合我的特定情况.

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

Answer 7

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

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

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

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