NoSQL - MongoDB 与 CouchDB

声明:本页面是StackOverFlow热门问题的中英对照翻译,遵循CC BY-SA 4.0协议,如果您需要使用它,必须同样遵循CC BY-SA许可,注明原文地址和作者信息,同时你必须将它归于原作者(不是我):StackOverFlow 原文地址: http://stackoverflow.com/questions/3375494/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me): StackOverFlow

提示:将鼠标放在中文语句上可以显示对应的英文。显示中英文
时间:2020-09-09 11:46:33  来源:igfitidea点击:

NoSQL - MongoDB vs CouchDB

mongodbcouchdbnosql

提问by mpenrow

I am a complete noob when it comes to the NoSQL movement. I have heard lots about MongoDB and CouchDB. I know there are differences between the two. Which do you recommend learning as a first step into the NoSQL world?

谈到 NoSQL 运动,我完全是个菜鸟。我听说过很多关于 MongoDB 和 CouchDB 的信息。我知道两者之间存在差异。作为进入 NoSQL 世界的第一步,您建议学习哪个?

采纳答案by amra

See following links

请参阅以下链接

Update: I found great comparison of NoSQLdatabases.

更新:我发现了 NoSQL数据库的很好的比较

MongoDB (3.2)

MongoDB (3.2)

  • Written in: C++
  • Main point: JSON document store
  • License: AGPL (Drivers: Apache)
  • Protocol: Custom, binary (BSON)
  • Master/slave replication (auto failover with replica sets)
  • Sharding built-in
  • Queries are javascript expressions
  • Run arbitrary javascript functions server-side
  • Has geospatial indexing and queries
  • Multiple storage engines with different performance characteristics
  • Performance over features
  • Document validation
  • Journaling
  • Powerful aggregation framework
  • On 32bit systems, limited to ~2.5Gb
  • Text search integrated
  • GridFS to store big data + metadata (not actually an FS)
  • Data center aware
  • 编写:C++
  • 要点:JSON文档存储
  • 许可证:AGPL(驱动程序:Apache)
  • 协议:自定义,二进制(BSON)
  • 主/从复制(带有副本集的自动故障转移)
  • 内置分片
  • 查询是 javascript 表达式
  • 在服务器端运行任意 javascript 函数
  • 具有地理空间索引和查询
  • 具有不同性能特征的多个存储引擎
  • 性能优于功能
  • 文件验证
  • 日记
  • 强大的聚合框架
  • 在 32 位系统上,限制为 ~2.5Gb
  • 文本搜索集成
  • GridFS 存储大数据 + 元数据(实际上不是 FS)
  • 数据中心感知

Best used: If you need dynamic queries. If you prefer to define indexes, not map/reduce functions. If you need good performance on a big DB. If you wanted CouchDB, but your data changes too much, filling up disks.

最佳用途:如果您需要动态查询。如果您更喜欢定义索引,而不是 map/reduce 函数。如果您需要在大数据库上获得良好的性能。如果你想要 CouchDB,但你的数据变化太多,填满磁盘。

For example: For most things that you would do with MySQL or PostgreSQL, but having predefined columns really holds you back.

例如:对于大多数你会用 MySQL 或 PostgreSQL 做的事情,但是预定义的列确实会让你望而却步。

CouchDB (1.2)

CouchDB (1.2)

  • Written in: Erlang
  • Main point: DB consistency, ease of use
  • License: Apache
  • Protocol: HTTP/REST
  • Bi-directional (!) replication,
  • continuous or ad-hoc,
  • with conflict detection,
  • thus, master-master replication. (!)
  • MVCC - write operations do not block reads
  • Previous versions of documents are available
  • Crash-only (reliable) design
  • Needs compacting from time to time
  • Views: embedded map/reduce
  • Formatting views: lists & shows
  • Server-side document validation possible
  • Authentication possible
  • Real-time updates via '_changes' (!)
  • Attachment handling
  • 写于:二郎
  • 要点:DB一致性、易用性
  • 许可证:阿帕奇
  • 协议:HTTP/REST
  • 双向(!)复制,
  • 连续或临时,
  • 通过冲突检测,
  • 因此,主-主复制。(!)
  • MVCC - 写操作不会阻塞读
  • 以前版本的文档可用
  • 防碰撞(可靠)设计
  • 需要不时压缩
  • 视图:嵌入地图/减少
  • 格式化视图:列表和显示
  • 可以进行服务器端文档验证
  • 可进行身份验证
  • 通过“_changes”(!)实时更新
  • 附件处理

Best used: For accumulating, occasionally changing data, on which pre-defined queries are to be run. Places where versioning is important.

最佳用途:用于累积、偶尔更改的数据,在这些数据上运行预定义的查询。版本控制很重要的地方。

For example: CRM, CMS systems. Master-master replication is an especially interesting feature, allowing easy multi-site deployments.

例如:CRM、CMS系统。主-主复制是一个特别有趣的功能,可以轻松进行多站点部署。

回答by Riyad Kalla

If you are coming from the MySQL world, MongoDB is going to "feel" a lot more natural to you because of its query-like language support.

如果您来自 MySQL 世界,那么 MongoDB 会让您“感觉”更加自然,因为它具有类似查询的语言支持。

I think that is what makes it so friendly for a lot of people.

我认为这就是它对很多人如此友好的原因。

CouchDB is fantastic if you want to utilize the really great master-master replication support with a multi-node setup, possibly in different data centers or something like that.

如果您想在多节点设置中使用真正出色的主-主复制支持,可能在不同的数据中心或类似的地方,CouchDB 非常棒。

MongoDB's replication (replica sets) is a master-slave-slave-slave-* setup, you can only write to the master in a replica set and read from any of them.

MongoDB 的复制(副本集)是主-从-从-从-* 设置,您只能写入副本集中的主服务器并从其中任何一个读取。

For a standard site configuration, that is fine. It maps to MySQL usage really well.

对于标准站点配置,这很好。它非常好地映射到 MySQL 的使用。

But if you are trying to create a global service like a CDN that needs to keep all global nodes synced even though read/write to all of them, something like the replication in CouchDB is going to be a huge boon to you.

但是,如果您正在尝试创建像 CDN 这样的全局服务,即使对所有全局节点进行读/写,也需要保持所有全局节点同步,那么 CouchDB 中的复制之类的东西对您来说将是一个巨大的福音。

While MongoDB has a query-like language that you can use and feels very intuitive, CouchDB takes a "map-reduce" approach and this concepts of views. It feels odd at first, but as you get the hang of it, it really starts feeling intuitive.

虽然 MongoDB 有一种类似查询的语言,您可以使用它并且感觉非常直观,但 CouchDB 采用“map-reduce”方法和视图概念。一开始感觉很奇怪,但是当你掌握了它的窍门时,它真的开始感觉很直观。

Here is a quick overview so it makes some sense:

这是一个快速概述,所以它是有道理的:

  • CouchDB stores all your data in a b-tree
  • You cannot "query" it dynamically with something like "SELECT * FROM user WHERE..."
  • Instead, you define discrete "views" of your data... "here is a view of all my users", "here is a view of all users older than 10" "here is a view of all users older than 30" and so on.
  • These views are defined using map-reduce approach and are defined as JavaScript functions.
  • When you define a view, the DB starts feeding all the documents of the DB you assigned the view to, through it and recording the results of your functions as the "index" on that data.
  • There are some basic queries you can do on the views like asking for a specific key (ID) or range of IDs regardless of what your map/reduce function does.
  • Read through these slides, it's the best clarification of map/reduce in Couch I've seen.
  • CouchDB 将所有数据存储在 B 树中
  • 你不能用“SELECT * FROM user WHERE ...”之类的东西动态“查询”它
  • 相反,您定义数据的离散“视图”......“这是我所有用户的视图”,“这是所有 10 岁以上用户的视图”“这是所有 30 岁以上用户的视图”和很快。
  • 这些视图是使用 map-reduce 方法定义的,并被定义为 JavaScript 函数。
  • 当您定义一个视图时,DB 开始提供您分配该视图的 DB 的所有文档,通过它并将您的函数结果记录为该数据的“索引”。
  • 无论您的 map/reduce 函数做什么,您都可以在视图上执行一些基本查询,例如询问特定的键 (ID) 或 ID 范围。
  • 通读这些幻灯片,这是我见过的对 Couch 中 map/reduce 的最好说明。

So both of these sources use JSON documents, but CouchDB follows this more "every server is a master and can sync with the world" approach which is fantastic if you need it, while MongoDB is really the MySQL of the NoSQL world.

所以这两个来源都使用 JSON 文档,但 CouchDB 更遵循“每个服务器都是主控器,可以与世界同步”的方法,如果您需要它,这非常棒,而 MongoDB 确实是 NoSQL 世界的 MySQL。

So if that sounds more like what you need/want, go for that.

所以如果这听起来更像你需要/想要的,那就去做吧。

Little differences like Mongo's binary protocol vs the RESTful interface of CouchDB are all minor details.

像 Mongo 的二进制协议与 CouchDB 的 RESTful 接口这样的小差异都是小细节。

If you want raw speed and to hell with data safety, you canmake Mongo run faster than CouchDB as you can tell it to operate out of memory and not commit things to disk except for sparse intervals.

如果你想要原始速度和数据安全,你可以让 Mongo 比 CouchDB 运行得更快,因为你可以告诉它在内存不足的情况下运行,而不是将东西提交到磁盘,除了稀疏间隔。

You can do the same with Couch, but it's HTTP-based communication protocol is going to be 2-4x slower than raw binary communication with Mongo in this "speed over everything!" scenario.

你可以用 Couch 做同样的事情,但它的基于 HTTP 的通信协议将比使用 Mongo 的原始二进制通信慢 2-4 倍,在这种“速度超过一切!” 设想。

Keep in mind that raw crazy insane speed is useless if a server crash or disk failure corrupts and toasts your DB into oblivion, so that data point isn't as amazing as it might seem (unless you are doing real-time trading systems on Wall Street, in which case look at Redis).

请记住,如果服务器崩溃或磁盘故障损坏并将您的数据库烤成遗忘,那么原始疯狂的疯狂速度是无用的,因此该数据点并不像看起来那么惊人(除非您在 Wall 上进行实时交易系统)街,在这种情况下看看Redis)。

Hope that all helps!

希望对大家有帮助!

回答by Austin Gonyou

There are now many more NoSQL databases on the market than ever before. I suggest even having a look at the Gartner Magic Quadrant if you're looking for a database that will also be great for enterprise applications based on support, expandability, management, and cost.

现在市场上的 NoSQL 数据库比以往任何时候都多。如果您正在寻找基于支持、可扩展性、管理和成本也非常适合企业应用程序的数据库,我建议您甚至查看 Gartner 魔力象限。

http://www.gartner.com/technology/reprints.do?id=1-23A415Q&ct=141020&st=sb

http://www.gartner.com/technology/reprints.do?id=1-23A415Q&ct=141020&st=sb

I would like to suggest Couchbase to anyone who's not tried it yet, but not based on the version that is shown in the report (2.5.1) because it is nearly 2 revisions behind where CB Server is today, nearing release of 4.0 in 2H15.

我想向任何还没有尝试过 Couchbase 的人推荐 Couchbase,但不是基于报告中显示的版本 (2.5.1),因为它比今天的 CB Server 落后近 2 个修订版,接近 2H15 的 4.0 版本.

http://www.couchbase.com/coming-in-couchbase-server-4-0

http://www.couchbase.com/coming-in-couchbase-server-4-0

The other part about Couchbase as a vendor/product is that it is a multi-use type of DB. It can act as a pure K/V store, Document Oriented Database with multi-dimensional scaling, Memcached, cache-aside with persistence, and supports ANSI 92 compliant SQL with automatic joins, replication to DR clusters with the push of a button, and even has a mobile component built-in to the ecosystem.

关于 Couchbase 作为供应商/产品的另一部分是它是一种多用途类型的数据库。它可以充当纯 K/V 存储、具有多维扩展的面向文档的数据库、Memcached、具有持久性的缓存,并支持具有自动连接的符合 ANSI 92 的 SQL,只需按一下按钮即可复制到 DR 集群,以及甚至在生态系统中内置了一个移动组件。

If nothing else, it's worth checking out the latest benchmarks:

如果不出意外,值得查看最新的基准测试:

http://info.couchbase.com/Benchmark_MongoDB_VS_CouchbaseServer_HPW_BM.htmlhttp://info.couchbase.com/NoSQL-Technical-Comparison-Report.html

http://info.couchbase.com/Benchmark_MongoDB_VS_CouchbaseServer_HPW_BM.html http://info.couchbase.com/NoSQL-Technical-Comparison-Report.html