为了账号安全,请及时绑定邮箱和手机立即绑定

博客数据库要连接Elasticsearch,使用MySQL还是MongoDB更合理

2021.03.01 11:20 163浏览

若进行博客等文本类数据的读写以及搜索引擎连接的解决方案对比,这就包括了搜索引擎数据同步,文章属性、文章内容、文章内图片以及图片属性的存储和查询,可以肯定的下结论:MongoDB的解决方案中要远远好于MySQL的解决方案。

一、从开发工序角度

MySQL的文章读写方式

**方式一:**文章标题、作者、标签、时间和内容存关系表,图片存OSS,地址存关系表

file

上述方式因为OSS和MySQL没有事务关系,因此需要编辑文章过程中存储图片和存储草稿都是分开设计,后台写入是分开执行,查询过程更适合前端异步获取图片,另外OSS需要额外的访问授权。

最最关键的问题是OSS收费!

**方式2:**文章标题、作者、标签、时间和内容存关系表,图片存本地,地址存关系表,Nginx作为图片查询代理

file

上图中实线为写入过程,虚线为查询过程。写入本地文件的过程依然无法保证事务,因此仍需要后台分开执行,查询过程Nginx的业务授权非常麻烦,需要引入Openresty和授权服务器的对接,而且文件的存储存在文件数超过操作系统最大限制的可能,图片缺乏可靠性备份机制。

唯一的好处就是图片存储本地不用额外付费。

我们再看看MongoDB文章读写方式

file

如上图方式一:整存整取,MongoDB可以将文章标题、作者、标签、时间和内容,图片存在一个集合中,那么图片为BSON格式,形成整存整取,若文章+图片的完整文档不超过16M,是BSON比较合适。
若文档因为图过大,超过16M,就使用方式二,使用MongoDB提供的GridFS插件存取。

**方式一:**从开发工序上最简单,但不适合太大图片,导致文档整体超过16M。

**方式二:**相当于需要访问不同的MongoDB数据库,从代码复杂度上就要更高,而且一致性控制不如方式一好。

其他优势:这两种方式都可以得到MongoDB的统一访问控制保护。这两种方式都使图片通过副本集实现可靠性备份。

但最最关键的是没有MySQL变扭的超出技术范围的架构考虑,到底用OSS要收费,还是用Http代理的免费模式,容忍可靠性、复杂性及安全性问题超级大的情况。

二、从性能角度看

1、文章插入性能

从目前MongoDB4实测情况看,给定时间段内数据写入量级越大,MongoDB的完成时间就比MySQL的完成时间越短。因此博客网站平台或者博客爬虫系统,写入的数据量特别大的情况下,MongoDB可以提供更优越的负载能力。

2、伸缩性

MongoDB和MySQL都可以进行数据库级的内存缓存,但是MongoDB可以将文档最大可能的缓存在内存中,得到最优的性能表现。若内存不够的情况出现就会溢出到磁盘中,那么性能就会减弱,这个时候可以通过水平分区实现,更好的内存表现。

MySQL的分片必须通过自研或引入第三方的分片应用实现手动分片,即一张数据表迁移到不同MySQL库中,按照数据记录进行分表,最终达到分片应用对多库实现负载均衡的目的,这种方式的缺点就是实现分片的过程非常复杂和麻烦。

MongoDB的分片属于其核心架构之一,也是NoSQL天然所擅长的能力,因此MongoDB可以在用户不干预的情况下实现集合分片,这比MySQL的手动分片不知道要轻松多少。

file

上图中Mongos路由器作为接口,连接整个集群,将所有的读写请求指引到合适的分片上,配置服务器持久化分片集群的元数据,以及数据在分片之间进行迁移的历史信息,而且配置服务器本身也是高可靠的。

三、与Elasticsearch连接角度看

MySQL连接Elasticsearch

一种方式可以通过CDC(数据变更捕获)工具抓取binglog到Kafka,再由Kafka管道输出到Elasticsearch

另一种方式通过JDBC“轮询”数据库,再推送Elasticsearch

file

第一种方式在引入CDC抓取工具,例如debezium后,会让整个流程非常复杂,经历的环节过多,仍要控制好Kafka的按键分区和折叠模式,数据管道也要解决关系结构向文档结构的ETL过程。

当然方式一也可以不用Kafka,直接走Logstash管道的过滤通道,但是第三方CDC抓取工具就要再考虑一层与Logstash的对接过程。

第二种方式虽然简单,不过JDBC轮询对MySQL有不小的影响,而且业务表需要提供变化日志表,再有Logstash等清洗程序再做ETL合并同步,这个过程也不容易。

我们再看MongoDB连接Elasticsearch

通过mongo-connector可以轻松实现MongoDB到Elasticsearch的数据实时同步

file

mongo-connector通过监听Oplog,非常类似MySQL CDC工具对binglog的监听,实时对数据进行采集并直接同步到Elasticsearch中,因为MongoDB和Elasticsearch都是无模式的文档型数据库,因此ETL过程可以由mongo-connector工具实现MongoDB集合向ES索引的无缝写入,会省去ETL过程很大的麻烦。

四、总结

从上面的架构描述上,其实已经强有力地论证了MongoDB无论作为存储文档型的博客文章也好,还是与其他专有搜索引擎同步也好,相对于MySQL,是更好的解决方案。
> 我们是“读字节”技术专家团队,感谢您的关注!

点击查看更多内容
0人点赞

若觉得本文不错,就分享一下吧!

评论

相关文章推荐

正在加载中
意见反馈 帮助中心 APP下载
官方微信

举报

0/150
提交
取消