我被困在这两个 NoSQL 数据库之间。
在我的项目中,我将在数据库中创建一个数据库。例如,我需要一个创建动态表的解决方案。
因此用户可以创建具有列和行的表。我认为 MongoDB 或 CouchDB 都会对此有好处,但我不确定哪一个。我也需要有效的分页。
我被困在这两个 NoSQL 数据库之间。
在我的项目中,我将在数据库中创建一个数据库。例如,我需要一个创建动态表的解决方案。
因此用户可以创建具有列和行的表。我认为 MongoDB 或 CouchDB 都会对此有好处,但我不确定哪一个。我也需要有效的分页。
C、A&P(Consistency、Availability & Partition tolerance)中哪两个对你来说更重要?快速参考,NoSQL 系统的可视化指南
一篇博文,Cassandra vs MongoDB vs CouchDB vs Redis vs Riak vs HBase vs Membase vs Neo4j 比较了每个 NoSQL 数据库的“最佳使用”场景。引用链接,
Riyad Kalla最近(2012 年 2 月)和更全面的比较,
A MongoDB Guy Learns CouchDB的博客文章(2011 年 10 月)由一个尝试过两者的人评论说 CouchDB 的分页没有那么有用。
Kristina Chodorow(MongoDB 背后团队的一部分)的过时(2009 年 6 月)基准测试,
我会选择 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 方法“恰到好处”,但是如果在了解了数据库功能(在详尽的官方指南中)之后,您没有“该死的”时刻,您可能应该继续前进。
如果您只想使用“正确的工具完成正确的工作”,我不鼓励使用 CouchDb。因为你会发现你不能那样使用它,你最终会生气并写博客文章,例如“CouchDb 中的连接在哪里?” 和“事务管理在哪里?”。事实上,Couchdb - 矛盾的是 - 非常透明,但同时需要范式转变和处理问题的方式的改变才能真正发光(并且真正起作用)。
但是一旦你做到了,它真的会得到回报。我个人需要非常充分的理由或项目的重大交易破坏者来选择另一个数据库,但到目前为止我还没有遇到任何问题。
自己问这个问题?您将决定您的数据库选择。
我总结了在那篇文章中找到的答案:
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 的),因此文档中没有“列”而是字段——但它们可以是完全动态的。
他们都这样做,您可能想查看其他要使用的因素:您关心的其他功能、受欢迎程度等。谷歌洞察力、indeed.com 职位发布将是查看受欢迎程度的方法。
您可以尝试一下,我认为您应该能够在 5 分钟内运行 mongo。