NoSQL - MongoDB与CouchDB比较

13 浏览
0 Comments

NoSQL - MongoDB与CouchDB比较

已关闭。这个问题是基于观点的。目前无法接受答案。


想要改进这个问题吗? 通过编辑这篇文章,使问题能够用事实和引用来回答。

改善这个问题

我对NoSQL运动完全不了解。我听说过MongoDB和CouchDB。我知道它们之间有区别。你建议先学习哪一个作为进入NoSQL世界的第一步?

admin 更改状态以发布 2023年5月23日
0
0 Comments

如果你来自MySQL的世界,那么由于其类似查询语言的支持,MongoDB会让你感觉更自然。

我认为这就是它为什么对许多人都如此友好的原因。

如果您想利用多节点设置中的非常好的主主复制支持,可能在不同的数据中心或类似的情况下,那么CouchDB非常出色。

MongoDB的复制(副本集)是一个主-从-从-从- *设置,只能在复制集的主节点上写入并从任意一个节点读取。

对于标准网站配置,这很合适。它非常适合MySQL的使用。

但是,如果您尝试创建像CDN这样需要保持所有全局节点同步的全球服务,即使读/写所有节点,像CouchDB中的复制也会对您很有帮助。

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

以下是一个快速概述,这样它就有些意义了:

  • CouchDB将所有数据存储在B树中。
  • 您不能使用“SELECT * FROM user WHERE ...”之类的东西以动态方式查询它。
  • 相反,您定义数据的离散“视图”...... “这是我的所有用户的视图”,“这是大于10岁的所有用户的视图”“这是大于30岁的所有用户的视图”等等。
  • 这些视图使用映射-减少方法定义,并且定义为JavaScript函数。
  • 当您定义视图时,数据库开始将分配给视图的数据库的所有文档通过它进行并记录您的函数的结果作为该数据的“索引”。
  • 有一些基本查询可以对视图进行操作,例如查找特定键(ID)或ID范围,而不管映射/减少函数的内容。
  • 阅读这些幻灯片,这是我看过的关于Couch中map / reduce的最好澄清。

因此,这两个源都使用JSON文档,但是CouchDB遵循这种更“每个服务器都是主服务器,并且可以与世界同步”的方法,这非常出色,如果您需要它的话,而MongoDB实际上是NoSQL世界中的MySQL。

因此,如果这听起来更像您所需/想要的,请选择它。

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

如果您想要纯速度而不考虑数据安全性,可以使Mongo比CouchDB运行得更快,因为您可以让它在内存中运行,而不会在除了稀疏间隔之外立即将数据提交到磁盘。

您也可以对Couch执行相同的操作,但是它的基于HTTP的通信协议在这种“速度优于一切!”方案中将比Mongo的原始二进制通信慢2-4倍。

请记住,如果服务器崩溃或磁盘故障导致数据库被毁坏,那么原始狂野的速度就没有用了,因此该数据点并不像看起来那么惊人(除非你正在华尔街做实时交易系统,在这种情况下可看看Redis)。

希望这一切都有所帮助!

0
0 Comments

请查看以下链接:

更新:我找到了一篇关于NoSQL数据库的好的比较文章(英文)

MongoDB (3.2)

  • 使用语言:C++
  • 主要特点:JSON文档存储
  • 许可证:AGPL(驱动程序:Apache)
  • 协议:自定义、二进制(BSON)
  • 主/从复制(通过副本集自动容错)
  • 内置分片处理
  • 查询是JavaScript表达式
  • 可以在服务器端运行任意JavaScript函数
  • 拥有地理空间索引和查询
  • 不同性能特征的多个存储引擎
  • 性能优先于特性
  • 文档验证
  • 日志记录
  • 功能强大的聚合框架
  • 在32位系统上,限制为约2.5Gb
  • 集成文本搜索
  • 使用GridFS来存储大数据+元数据(实际不是文件系统)
  • 数据中心感知

最佳用途:如果需要动态查询;如果您更喜欢定义索引而不是map/reduce函数;如果需要对大型数据库进行良好的性能;如果您需要CouchDB,但是数据更改太频繁,导致磁盘满了。

例如:大多数使用MySQL或PostgreSQL的场景,但是预定义的列实在是束缚了您的手脚。

CouchDB (1.2)

  • 使用语言:Erlang
  • 主要特点:数据库一致性、易用性
  • 许可证:Apache
  • 协议:HTTP/REST
  • 双向(!)复制,可以是连续性或即席性的,带有冲突检测,因此可以实现主-主复制(!)
  • MVCC-写操作不会阻塞读操作
  • 文档的先前版本可供使用
  • 崩溃重启式(可靠)设计
  • 需要定期压缩
  • 可嵌入Map/Reduce的视图
  • 格式化视图:列表视图和展示视图
  • 可能的服务器端文档验证
  • 可用于身份验证
  • 通过 '_changes'实现的实时更新(!)
  • 附件处理

最佳用途:用于积累、偶尔更改的数据,需要运行预定义查询的场景。版本控制很重要的场景。

例如:CRM、CMS系统。主-主复制是一个尤其有趣的特性,可以轻松实现多站点部署。

0