写点什么

话题讨论 | mongodb 拥有十大核心优势,为何国内知名度远不如 mysql 高?

发布于: 2021 年 02 月 22 日
话题讨论 | mongodb拥有十大核心优势,为何国内知名度远不如mysql高?

1. 背景

mongodb 是一款功能完善的分布式文档数据库,在高性能、动态扩缩容、高可用、易部署、易使用、海量数据存储、高压缩比等方面拥有天然优势。虽然 mongodb 有很多优势,但是在国内缺存在不少的误解,影响力有待提升。

2. mongodb 历年数据库得分排名及得分趋势

DB-Engines 是一个对数据库管理系统受欢迎程度进行排名的网站,近年来,MongoDB 在 DB-Engines 数据库流行度排行榜稳居榜单前五。在 DB-Engines 排名可以看出,mongodb 历年得分数据呈现持续增长的趋势,具体如下图所示:

  • 得分趋势图形

  • 近两年得分如下:

从历年得分排名可以看出,mongodb 总体趋势呈现持续增长态势,稳固了它在数据库系统中的使用优势。

  • mongodb roadmap:不仅仅是文档数据库

mongodb-4.2 版本开始已经支持分布式事务功能,当前对外文档版本已经迭代到 version-4.2.11,分布式事务功能也进一步增强。此外,从 mongodb-4.4 版本产品规划路线图可以看出,mongodb 官方将会持续投入开发查询能力和易用性增强功能,例如 union 多表联合查询、索引隐藏等。mongodb 产品路线图如下:

从 mongodb-4.2 版本分布式事务功能支持以及 4.4 版本 roadmap 规划图可以看出,mongodb 后续发展会持续朝着 NewSQL 方向前行,预计会为用户提供更全面的数据库服务功能。

3. 模式自由-加字段方便快捷


分布式 mongodb 核心优势特性主要如下:

  • 模式自由-加字段方便快捷

  1. 在集合中插入一条文档

use test;

db.blog.insert({"Title": "Title1",  "Description": "Description1", "Author": "Author1","Content": "Content1", "likes": "100", });

从上面的操作可以看出,mongodb 不需要提前建表,也不需要指定表中各个字段,使用灵活。

  1. 在已有文档 Title1 中添加一个不存在的字段(如给博客添加一个 tags 字段)

db.blog.update({"Title": "Title1"}, {$set: {tags: "tagxxx"}})


4. 天然高可用支持

当前开源数据库 Mysql,当同一个分片复制集中(假设一主两从)中的主服务器异常或者实例异常退出后,需要依赖第三方 MHA 插件来实现新主的选举。如果没有第三方 MHA 插件,或者第三方 MHA 插件异常,则无法选举新主节点,最终造成写失败。

相比 Mysql 对第三方 MHA 插件的依赖,mongodb 数据库自带天然高可用选举功能,具体架构图如下:


如上图所示,当主节点异常后,两个 mongod 从节点的保活报文会探测到该异常,然后 2 个从节点会进行一轮新的主节点投票选举(raft 协议)。主节点异常,剩余两个节点可以进行正常投票选举,因为满足 raft 多数派要求,最终会在两个主节点中快速选择一个新的主节点。

5. 分布式弹性扩缩容(解决分库分表及海量数据存储痛点)

扩容过程业务无感知,扩容新分片触发数据 balance 过程如下图所示(假设从 3 分片扩容到 6 分片):

有了分片水平扩容能力,就可以突破前面单分片复制集架构的容量限制、写入能力受限等瓶颈,基本上可以实现数据容量和写入能力成倍增长。


6. 完善的数据均衡机制、不同分片策略、多种片建类型支持


  • 完善的数据 balance 均衡机制



  • 不同分片策略及预分片功能支持

为了满足不同业务查询场景需求,mongodb 支持两种类型的分片策略:hash 分片和范围分片。这两种分片策略再不同业务场景,各自有不同的优缺点,这样业务可以根据实际情况来完成分片策略选择。具体如下:

hash 分片策略:通过对指定 shard key 进行 hash 计算,从而快速实现数据随机散列到不同分片,从而规避数据不均衡问题,适合单条数据查询相关业务场景。

范围分片策略:范围分片方式,比较适合业务有范围查询的场景,如果业务查询中带有范围查询,可以考虑该分片策略实现性能最大化。注意:范围分片策略方式,数据均衡性相比 hash 分片一般稍差。

    

此外,为了尽量提高性能,mongodb 默认还支持预分片功能,这样可以保证数据写入集群的适合尽量均衡,避免 balance 数据迁移过程对整个集群性能的影响,做到读写性能的最大化。hash 分片策略和范围分片策略都支持预分片,只是 hash 分片策略方式可以支持自动预分片,同时也支持手动预分片方式;范围分片策略方式只支持手动预分片。具体如下:

自动预分片支持:如果分片集群选用 hash 分片策略,则支持 shardCollection 时提前对片建进行自动预备分片。

手动预分片支持:hash 分片策略和范围分片策略都可以通过 mongodb 自有的 splitAt 等接口进行手动人工预分片,分片接口的支持确保预分片更加弹性自由。

     此外,除了支持常用的范围分片及 hash 分片策略外,mongodb 还支持 shardTag 分片模式,对一些极端特殊需求做定制化流量转发(例如对带有某种标记的数据转发到指定的节点)。

7. 完善的数据一致性及安全性保证

  • 数据一致性有较高要求场景

  • 数据一致性要求不高场景

8. 高并发、高性能

mongodb 为了满足不同业务链接需求(链接数多少、是否短链接、是否很多空闲链接等),支持两种线程模型:一个链接一个线程和 adaptive 动态线程池模型。

  • 一个链接一个线程

  • adaptive 动态线程模型

  • wiredtiger 高性能存储引擎设计

WT 和 innodb 存储引擎性能比较曲线如下:

WT 和 levelDb 存储引擎性能比较曲线如下:



9. 成本节省-WT 引擎高压缩比支持

mongodb 对数据的压缩支持 snappy、zlib 算法,针对存储层中的数据分类又可以分为以下几种:

  • 普通 collection 数据:对用户写入 collection 的数据是否需要压缩,支持 snappy、zlib 算法,4.2 增加zstd支持。

  • journal 数据:对 journal 日志数据是否压缩,支持 snappy、zlib 算法,4.2 增加zstd支持。

  • index 索引数据:对索引数据是否进行压缩,默认只支持前缀压缩,这样相同前缀的索引数据,共同的前缀只会存储一次,这样即可减少内存和磁盘消耗。

在以往线上真实的文本数据空间大小与真实磁盘空间消耗进行对比,可以得出以下结论:

① mongodb 默认的 snappy 压缩算法压缩比约为 2.2-3.5 倍

② zlib 压缩算法压缩比约为 4.5-7.5 倍(本次迁移采用 zlib 高压缩算法)

    也就是,如果 collection 数据和 journal 日志数据采用默认的 snappy 压缩算法,当数据量为 3.5T 时,真实的磁盘消耗约为 1-1.5T;如果采用 zlib 算法,3.5T 的数据量,真实的磁盘消耗为 500-700G 左右,不同数据类型会有差别,如下表所示:


    说明:1.不同数据类型会有差别;2.最新 4.2 以后版本引入了新的zstd算法,性能会更好,由于没有真实使用过 zstd 算法,因此不做具体数据对比。


10. 天然机房多活容灾支持






11. 完善的客户端均衡访问策略

mongodb 客户端访问路由策略由客户端自己指定,该功能通过 Read Preference 实现,具有如下几个配置方式:

  • primary :只从 primary 主节点读数据,这个是默认设置,所有读只走主节点。

  • primaryPreferred :优先从 primary 读取,如果复制集没有主节点则通过从节点读数据。

  • secondary :只从 scondary 节点读数据。

  • secondaryPreferred :优先从 secondary 读取,当没有 secondary 从节点成员时,才从 primary 读数据。

  • nearest :选择离自己最近的节点读数据,也就是就近访问。

通过在客户端 driver 中配置不同的读方式,可以方便实现读写分离、就近读数据等,如果对数据一致性要求高,也可以直接读主节点。我们以复制集 nearest 配置为例,架构图如下:

12. 分布式事务支持

mongodb-4.2 版本开始已经支持分布式事务功能,当前对外文档版本已经迭代到 version-4.2.11,分布式事务功能也进一步增强。此外,从 mongodb-4.4 版本产品规划路线图可以看出,mongodb 官方将会持续投入开发查询能力和易用性增强功能,例如 union 多表联合查询、索引隐藏等。mongodb 产品路线图如下:

从 mongodb-4.2 版本分布式事务功能支持以及 4.4 版本 roadmap 规划图可以看出,mongodb 后续发展会持续朝着 NewSQL 方向前行,预计会为用户提供更全面的数据库服务功能。


13. 最后:mongodb 这么多优势,为何国内影响力不高?

当前 mongodb 已经为我司提供了数万亿级数据库存储服务,从业务场景和业务接入情况来看,当前至少有 90%以上业务场景可以 mongodb 和 mysql 相互替代,这一部分业务使用 mongodb 也非常合适,业务切换到 mongodb 后也得到了一致性的认可,主要为业务解决了如下痛点:

  • 分库分表痛点:业务最大的痛,mongodb 可以理解为无限大的表,彻底解决该痛点。

  • 机房多活痛点:传统 mysql 双向同步具有物理服务器成本高(多副本情况下,又多了一倍)、人力成本高(你得找几个人来开发和运维双向同步系统)、数据一致性很难保证等。mongodb 分片及复制集架构可以天然支持机房多活,包括南北双机房,三机房,甚至更多国内国外机房多活都可解决。

  • 成本高,mysql 官方版本默认没有压缩等功能,同样得数据,默认配置,mongodb 磁盘相比 mysql 就可以节省 60%左右。

  • 分布式弹性扩缩容:有了该功能,除了可以解决分库分表痛点外,对业务容量评估也减轻了很大的工作量。例如如果 mysql,你不知道后续数据量就近多大,一般一次性就申请很多套,造成了资源浪费。

  • mongodb 分布式事务支持,突破了单机事务的限制。

  • 其他


如上,可以看出 mongodb 确实在部分业务场景有很多的优势,那为什么在国内影响力不高,甚至误解很深,个人理解如下:


个人认为除了上面图形中总结的原因外,还有另外两个很大的原因:

  1. 当前国内真正研究 mongodb 内核实现原理的人相比 mysql 确实少很多,遇到问题不知道怎么解决,最终造成不敢大规模使用。

  2. mongodb 生态相比 mysql 不足。

  3. 此外,大家更加习惯 SQL,已经养成习惯,其他数据库有个熟悉学习的过程,需要更多成本


以上是我的个人理解,大家可以说说自己的想法,补充为什么这么优秀的文档数据库 mongodb 在国内影响力不足


后续分享出 mongodb 踩过的所有坑到社区,让更多的人学习了解学习 mongodb。


发布于: 2021 年 02 月 22 日阅读数: 479
用户头像

万亿级mongodb集群性能优化实践 2020.10.13 加入

Qcon、Gdevops、dbaplus等讲师,滴滴出行专家工程师/OPPO-mongodb负责人,负责数万亿级mongodb内核研发、性能优化及运维工作。持续分享《MongoDB内核源码设计、性能优化、最佳实践》,https://github.com/y123456yz

评论 (6 条评论)

发布
用户头像
资料、文档没mysql丰富,为啥我也看到很多把mongodb和redis做比较?
2021 年 02 月 25 日 10:00
回复
资料这块确实是个痛点
2021 年 02 月 26 日 13:38
回复
用户头像
标题已改,原标题:为何拥有十大核心优势的mongodb数据库国内影响力不高?;改后标题:mongodb相比mysql拥有十大核心优势,为何国内知名度不高
2021 年 02 月 25 日 09:54
回复
用户头像
文档,使用者少,注定在国内redis的使用量要超过mongodb
2021 年 02 月 24 日 20:11
回复
感谢老兄回复,这里理解有误哈,mongodb不是和redis同一类型,mongodb对标的是mysql tidb这些海量数据存储,不是缓存
2021 年 02 月 25 日 09:49
回复
业界当前经常把mongodb和redis memcache做对比,这是不对的,是一种误解呢
2021 年 02 月 25 日 09:50
回复
没有更多了
话题讨论 | mongodb拥有十大核心优势,为何国内知名度远不如mysql高?