若进行博客等文本类数据的读写以及搜索引擎连接的解决方案对比，这就包括了搜索引擎数据同步，文章属性、文章内容、文章内图片以及图片属性的存储和查询，可以肯定的下结论：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，是更好的解决方案。
![file]()
公众号“读字节” 分布式，大数据，软件架构的深度，专业解读
[前往读字节的知乎——了解更多关于大数据的知识(https://www.zhihu.com/people/fangshun/answers])
