博客數據庫要鏈接Elasticsearch，使用MySQL仍是MongoDB更合理

若進行博客等文本類數據的讀寫以及專業搜索引擎的鏈接的解決方案對比，能夠確定的下結論：MongoDB的解決方案中要遠遠好於MySQL的解決方案。

1、從開發工序角度

MySQL的文章讀寫方式

方式一：文章標題、做者、標籤、時間和內容存關係表，圖片存OSS，地址存關係表

上述方式由於OSS和MySQL沒有事務關係，所以須要編輯文章過程當中存儲圖片和存儲草稿都是分開設計，後臺寫入是分開執行，查詢過程更適合前端異步獲取圖片，另外OSS須要額外的訪問受權。

最最關鍵的問題是OSS收費！

方式2：文章標題、做者、標籤、時間和內容存關係表，圖片存本地，地址存關係表，Nginx做爲圖片查詢代理

上圖中實線爲寫入過程，虛線爲查詢過程。寫入本地文件的過程依然沒法保證事務，所以仍須要後臺分開執行，查詢過程Nginx的業務受權很是麻煩，須要引入Openresty和受權服務器的對接，並且文件的存儲存在文件數超過操做系統最大限制的可能，圖片缺少可靠性備份機制。

惟一的好處就是圖片存儲本地不用額外付費。

咱們再看看MongoDB文章讀寫方式

如上圖方式一：整存整取，MongoDB能夠將文章標題、做者、標籤、時間和內容，圖片存在一個集合中，那麼圖片爲BSON格式，造成整存整取，若文章+圖片的完整文檔不超過16M，是BSON比較合適。
若文檔由於圖過大，超過16M，就使用方式二，使用MongoDB提供的GridFS插件存取。

方式一：從開發工序上最簡單，但不適合太大圖片，致使文檔總體超過16M。

方式二：至關於須要訪問不一樣的MongoDB數據庫，從代碼複雜度上就要更高，並且一致性控制不如方式一好。

其餘優點：這兩種方式均可以獲得MongoDB的統一訪問控制保護。這兩種方式都使圖片經過副本集實現可靠性備份。

但最最關鍵的是沒有MySQL變扭的超出技術範圍的架構考慮，到底用OSS要收費，仍是用Http代理的免費模式，容忍可靠性、複雜性及安全性問題超級大的狀況。

2、從性能角度看

一、文章插入性能

從目前MongoDB4實測狀況看，給定時間段內數據寫入量級越大，MongoDB的完成時間就比MySQL的完成時間越短。所以博客網站平臺或者博客爬蟲系統，寫入的數據量特別大的狀況下，MongoDB能夠提供更優越的負載能力。

二、伸縮性

MongoDB和MySQL均可以進行數據庫級的內存緩存，可是MongoDB能夠將文檔最大可能的緩存在內存中，獲得最優的性能表現。若內存不夠的狀況出現就會溢出到磁盤中，那麼性能就會減弱，這個時候能夠經過水平分區實現，更好的內存表現。

MySQL的分片必須經過自研或引入第三方的分片應用實現手動分片，即一張數據表遷移到不一樣MySQL庫中，按照數據記錄進行分表，最終達到分片應用對多庫實現負載均衡的目的，這種方式的缺點就是實現分片的過程很是複雜和麻煩。

MongoDB的分片屬於其核心架構之一，也是NoSQL自然所擅長的能力，所以MongoDB能夠在用戶不干預的狀況下實現集合分片，這比MySQL的手動分片不知道要輕鬆多少。

上圖中Mongos路由器做爲接口，鏈接整個集羣，將全部的讀寫請求指引到合適的分片上，配置服務器持久化分片集羣的元數據，以及數據在分片之間進行遷移的歷史信息，並且配置服務器自己也是高可靠的。

3、與Elasticsearch鏈接角度看

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過程很大的麻煩。

4、總結

從上面的架構描述上，其實已經強有力的論證了MongoDB不管做爲存儲文檔型的博客文章也好，仍是與其餘專有搜索引擎同步也好，相對於MySQL，是更好的解決方案。

咱們是「讀字節」技術專家團隊，感謝您的關注！ 讀字節官網