NoSQL - MongoDB vs CouchDB [关闭]

Question

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

Answer 1

查看以下链接

• CouchDB Vs MongoDB
• MongoDB or CouchDB - fit for production?
• DB-Engines - Comparison CouchDB vs. MongoDB

更新：我找到了很棒的 comparison of NoSQL 数据库。

MongoDB (3.2)

• 编写语言：C++
• 要点：JSON 文档存储
• 许可证：AGPL（驱动程序：Apache）
• 协议：自定义、二进制 (BSON)
• 主/从复制（使用副本集进行自动故障转移）
• 内置分片
• 查询是 javascript 表达式
• 在服务器端运行任意 javascript 函数
• 具有地理空间索引和查询
• 具有不同性能特征的多个存储引擎
• 性能优于功能
• 文档验证
• 日记
• 强大的聚合框架
• 在 32 位系统上，限制为 ~2.5Gb
• 集成文本搜索
• GridFS 用于存储大数据 + 元数据（实际上不是 FS）
• 数据中心感知

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

例如：对于大多数您会使用 MySQL 或 PostgreSQL 做的事情，但预定义的列确实会让您望而却步。

CouchDB (1.2)

• 编写于：Erlang
• 要点：数据库一致性、易用性
• 许可证：Apache
• 协议：HTTP/REST
• 双向 (!) 复制，
• 连续或临时，
• 带有冲突检测，
• 因此，主-主复制。 (!)
• MVCC - 写入操作不会阻塞读取
• 提供以前版本的文档
• 防崩溃（可靠）设计
• 需要不时压缩
• 视图：嵌入式地图/减少
• 格式化视图：列表和显示
• 可以进行服务器端文档验证
• 可以进行身份​​验证
• 通过“_changes”实时更新 (!)
• 附件处理

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

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

Answer 2

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

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

我想向尚未尝试过但不是基于报告中显示的版本 (2.5.1) 的任何人推荐 Couchbase，因为它比 CB Server 今天的版本落后了近 2 个修订版，即将发布2H15 4.0。

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

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

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

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

Answer 3

看看这些链接：

1. MongoDB vs CouchDB (from MongoDB side)

2. CouchDB vs MongoDB: An attempt for a More Informed Comparison

3. CouchDB vs. MongoDB Benchmark(perfomance comparison)

Answer 4

如果您来自 MySQL 世界，MongoDB 对您来说会“感觉”更自然，因为它支持类似查询的语言。

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

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

MongoDB的复制（replica sets）是master-slave-slave-slave-*的设置，你只能在一个replica set中写入master并从其中任意一个读取。

对于标准站点配置，这很好。它很好地映射到 MySQL 的使用情况。

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

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

这里是一个简短的概述，所以它是有道理的：

• CouchDB 将所有数据存储在 b 树中
• 您不能使用诸如“SELECT * FROM user WHERE...”之类的内容动态“查询”它
• 相反，您定义数据的离散“视图”...“这是我所有用户的视图”、“这是所有 10 岁以上用户的视图”“这是所有年龄超过 10 岁的用户的视图” 30" 等等。
• 这些视图是使用 map-reduce 方法定义的，并被定义为 JavaScript 函数。
• 当您定义视图时，数据库开始通过它提供您分配视图的数据库的所有文档，并将您的函数结果记录为该数据的“索引”。
• 无论您的 map/reduce 函数做什么，您都可以对视图执行一些基本查询，例如询问特定键 (ID) 或 ID 范围。
• 通读these slides，这是我见过的关于 Couch 中 map/reduce 的最佳说明。

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

因此，如果这听起来更像您需要/想要的，那就去做吧。

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

如果您想要原始速度和数据安全性，您可以让 Mongo 比 CouchDB 运行得更快，因为您可以告诉它在内存不足的情况下运行，并且除了稀疏间隔之外不会将内容提交到磁盘.

你可以对 Couch 做同样的事情，但它的基于 HTTP 的通信协议将比使用 Mongo 的原始二进制通信慢 2-4 倍，因为这种“速度胜过一切！”场景。

请记住，如果服务器崩溃或磁盘故障损坏并让您的数据库被遗忘，那么原始疯狂的疯狂速度将毫无用处，因此该数据点并不像看起来那么惊人（除非您正在进行实时交易华尔街的系统，在这种情况下看看 Redis）。

希望对大家有所帮助！