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

本文涉及的产品
云数据库 MongoDB,独享型 2核8GB
推荐场景:
构建全方位客户视图
对象存储 OSS,20GB 3个月
RDS MySQL Serverless 基础系列,0.5-2RCU 50GB
简介: 博客数据库要连接Elasticsearch,使用MySQL还是MongoDB更合理

若进行博客等文本类数据的读写以及专业搜索引擎的连接的解决方案对比,可以肯定的下结论:MongoDB的解决方案中要远远好于MySQL的解决方案。


一、从开发工序角度


MySQL的文章读写方式


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


20210228202607276.png


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


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


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


20210228202607618.png


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


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


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


20210228202607851.png


如上图方式一:整存整取,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的手动分片不知道要轻松多少。


20210228202608154.png


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


三、与Elasticsearch连接角度看


MySQL连接Elasticsearch


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


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


20210228202608531.png


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


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


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


我们再看MongoDB连接Elasticsearch


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


20210228202609111.png


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


四、总结


从上面的架构描述上,其实已经强有力的论证了MongoDB无论作为存储文档型的博客文章也好,还是与其他专有搜索引擎同步也好,相对于MySQL,是更好的解决方案。


相关文章
|
1月前
|
安全 关系型数据库 MySQL
MySQL安全最佳实践:保护你的数据库
本文深入探讨了MySQL数据库的安全防护体系,涵盖认证安全、访问控制、网络安全、数据加密、审计监控、备份恢复、操作系统安全、应急响应等多个方面。通过具体配置示例,为企业提供了一套全面的安全实践方案,帮助强化数据库安全,防止数据泄露和未授权访问,保障企业数据资产安全。
|
17天前
|
缓存 关系型数据库 BI
使用MYSQL Report分析数据库性能(下)
使用MYSQL Report分析数据库性能
54 3
|
23天前
|
关系型数据库 MySQL 数据库
自建数据库如何迁移至RDS MySQL实例
数据库迁移是一项复杂且耗时的工程,需考虑数据安全、完整性及业务中断影响。使用阿里云数据传输服务DTS,可快速、平滑完成迁移任务,将应用停机时间降至分钟级。您还可通过全量备份自建数据库并恢复至RDS MySQL实例,实现间接迁移上云。
|
10天前
|
关系型数据库 MySQL 分布式数据库
阿里云PolarDB云原生数据库收费价格:MySQL和PostgreSQL详细介绍
阿里云PolarDB兼容MySQL、PostgreSQL及Oracle语法,支持集中式与分布式架构。标准版2核4G年费1116元起,企业版最高性能达4核16G,支持HTAP与多级高可用,广泛应用于金融、政务、互联网等领域,TCO成本降低50%。
|
11天前
|
关系型数据库 MySQL 数据库
阿里云数据库RDS费用价格:MySQL、SQL Server、PostgreSQL和MariaDB引擎收费标准
阿里云RDS数据库支持MySQL、SQL Server、PostgreSQL、MariaDB,多种引擎优惠上线!MySQL倚天版88元/年,SQL Server 2核4G仅299元/年,PostgreSQL 227元/年起。高可用、可弹性伸缩,安全稳定。详情见官网活动页。
|
11天前
|
关系型数据库 分布式数据库 数据库
阿里云数据库收费价格:MySQL、PostgreSQL、SQL Server和MariaDB引擎费用整理
阿里云数据库提供多种类型,包括关系型与NoSQL,主流如PolarDB、RDS MySQL/PostgreSQL、Redis等。价格低至21元/月起,支持按需付费与优惠套餐,适用于各类应用场景。
|
10天前
|
SQL 关系型数据库 MySQL
Mysql数据恢复—Mysql数据库delete删除后数据恢复案例
本地服务器,操作系统为windows server。服务器上部署mysql单实例,innodb引擎,独立表空间。未进行数据库备份,未开启binlog。 人为误操作使用Delete命令删除数据时未添加where子句,导致全表数据被删除。删除后未对该表进行任何操作。需要恢复误删除的数据。 在本案例中的mysql数据库未进行备份,也未开启binlog日志,无法直接还原数据库。
|
17天前
|
Ubuntu 安全 关系型数据库
安装与配置MySQL 8 on Ubuntu,包括权限授予、数据库备份及远程连接指南
以上步骤提供了在Ubuntu上从头开始设置、配置、授权、备份及恢复一个基础但完整的MySQL环境所需知识点。
195 7
|
25天前
|
SQL Java 关系型数据库
Java连接MySQL数据库环境设置指南
请注意,在实际部署时应该避免将敏感信息(如用户名和密码)硬编码在源码文件里面;应该使用配置文件或者环境变量等更为安全可靠地方式管理这些信息。此外,在处理大量数据时考虑使用PreparedStatement而不是Statement可以提高性能并防止SQL注入攻击;同时也要注意正确处理异常情况,并且确保所有打开过得资源都被正确关闭释放掉以防止内存泄漏等问题发生。
68 13
|
17天前
|
缓存 监控 关系型数据库
使用MYSQL Report分析数据库性能(上)
最终建议:当前系统是完美的读密集型负载模型,优化重点应放在减少行读取量和提高数据定位效率。通过索引优化、分区策略和内存缓存,预期可降低30%的CPU负载,同时保持100%的缓冲池命中率。建议每百万次查询后刷新统计信息以持续优化
76 6

热门文章

最新文章

推荐镜像

更多