若进行博客等文本类数据的读写以及专业搜索引擎的链接的解决方案对比,能够确定的下结论:MongoDB的解决方案中要远远好于MySQL的解决方案。前端
MySQL的文章读写方式数据库
方式一:文章标题、做者、标签、时间和内容存关系表,图片存OSS,地址存关系表缓存
上述方式由于OSS和MySQL没有事务关系,所以须要编辑文章过程当中存储图片和存储草稿都是分开设计,后台写入是分开执行,查询过程更适合前端异步获取图片,另外OSS须要额外的访问受权。安全
最最关键的问题是OSS收费!服务器
方式2:文章标题、做者、标签、时间和内容存关系表,图片存本地,地址存关系表,Nginx做为图片查询代理架构
上图中实线为写入过程,虚线为查询过程。写入本地文件的过程依然没法保证事务,所以仍须要后台分开执行,查询过程Nginx的业务受权很是麻烦,须要引入Openresty和受权服务器的对接,并且文件的存储存在文件数超过操做系统最大限制的可能,图片缺少可靠性备份机制。负载均衡
惟一的好处就是图片存储本地不用额外付费。异步
咱们再看看MongoDB文章读写方式elasticsearch
如上图方式一:整存整取,MongoDB能够将文章标题、做者、标签、时间和内容,图片存在一个集合中,那么图片为BSON格式,造成整存整取,若文章+图片的完整文档不超过16M,是BSON比较合适。
若文档由于图过大,超过16M,就使用方式二,使用MongoDB提供的GridFS插件存取。工具
方式一:从开发工序上最简单,但不适合太大图片,致使文档总体超过16M。
方式二:至关于须要访问不一样的MongoDB数据库,从代码复杂度上就要更高,并且一致性控制不如方式一好。
其余优点:这两种方式均可以获得MongoDB的统一访问控制保护。这两种方式都使图片经过副本集实现可靠性备份。
但最最关键的是没有MySQL变扭的超出技术范围的架构考虑,到底用OSS要收费,仍是用Http代理的免费模式,容忍可靠性、复杂性及安全性问题超级大的状况。
一、文章插入性能
从目前MongoDB4实测状况看,给定时间段内数据写入量级越大,MongoDB的完成时间就比MySQL的完成时间越短。所以博客网站平台或者博客爬虫系统,写入的数据量特别大的状况下,MongoDB能够提供更优越的负载能力。
二、伸缩性
MongoDB和MySQL均可以进行数据库级的内存缓存,可是MongoDB能够将文档最大可能的缓存在内存中,获得最优的性能表现。若内存不够的状况出现就会溢出到磁盘中,那么性能就会减弱,这个时候能够经过水平分区实现,更好的内存表现。
MySQL的分片必须经过自研或引入第三方的分片应用实现手动分片,即一张数据表迁移到不一样MySQL库中,按照数据记录进行分表,最终达到分片应用对多库实现负载均衡的目的,这种方式的缺点就是实现分片的过程很是复杂和麻烦。
MongoDB的分片属于其核心架构之一,也是NoSQL自然所擅长的能力,所以MongoDB能够在用户不干预的状况下实现集合分片,这比MySQL的手动分片不知道要轻松多少。
上图中Mongos路由器做为接口,链接整个集群,将全部的读写请求指引到合适的分片上,配置服务器持久化分片集群的元数据,以及数据在分片之间进行迁移的历史信息,并且配置服务器自己也是高可靠的。
MySQL链接Elasticsearch
一种方式能够经过CDC(数据变动捕获)工具抓取binglog到Kafka,再由Kafka管道输出到Elasticsearch
另外一种方式经过JDBC轮询数据库,再推送Elasticsearch
第一种方式在引入CDC抓取工具,例如debezium后,会让整个流程很是复杂,经历的环节过多,仍要控制好Kafka的按键分区和折叠模式,数据管道也要解决关系结构向文档结构的ETL过程。
固然方式一也能够不用Kafka,直接走Logstash管道的过滤通道,可是第三方CDC抓取工具就要再考虑一层与Logstash的对接过程。
第二种方式虽然简单,不过JDBC轮询对MySQL有不小的影响,并且业务表须要提供变化日志表,再有Logstash等清洗程序再作ETL合并同步,这个过程也不容易。
咱们再看MongoDB链接Elasticsearch
经过mongo-connector能够轻松实现MongoDB到Elasticsearch的数据实时同步
mongo-connector经过监听Oplog,很是相似MySQL CDC工具对binglog的监听,实时对数据进行采集并直接同步到Elasticsearch中,由于MongoDB和Elasticsearch都是无模式的文档型数据库,所以ETL过程能够由mongo-connector工具实现MongoDB集合向ES索引的无缝写入,会省去ETL过程很大的麻烦。
从上面的架构描述上,其实已经强有力的论证了MongoDB不管做为存储文档型的博客文章也好,仍是与其余专有搜索引擎同步也好,相对于MySQL,是更好的解决方案。
咱们是“读字节”技术专家团队,感谢您的关注! 读字节官网