小編的世界優質文選資料

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

字體大小：
2021年3月02日 -
：

讀字節ReadByte上述方式因為OSS和MySQL沒有事務關系，因此需要編輯文章過程中存儲圖片和存儲草稿都是分開設計，後台寫入是分開執行，查詢過程更適合前端異步獲取圖片，另外OSS需要額外的訪問授權。 最最關鍵的問題是OSS收費！方式2：文章標題、作者、標簽、時間和內容存關系表，圖片存本地，地址存關系表，Nginx作為圖片查詢代理上圖中實線為寫入過程，虛線為查詢過程。 寫入本地文件的過程依然無法保證事務，因此仍需要後台分開執行，查詢過程Nginx的業務授權非常麻煩，需要引入Openresty和授權服務器的對接，而且文件的存儲存在文件數超過操作系統最大限制的可能，圖片缺乏可靠性備份機制。 唯一的好處就是圖片存儲本地不用額外付費。 我們再看看MongoDB文章讀寫方式如上圖方式一：整存整取，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的手動分片不知道要輕松多少。 上圖中Mongos路由器作為接口，連接整個集群，將所有的讀寫請求指引到合適的分片上，配置服務器持久化分片集群的元數據，以及數據在分片之間進行遷移的歷史信息，而且配置服務器本身也是高可靠的。 三、與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過程很大的麻煩。 四、總結從上面的架構描述上，其實已經強有力的論證了MongoDB無論作為存儲文檔型的博客文章也好，還是與其他專有搜索引擎同步也好，相對於MySQL，是更好的解決方案。 我們是“讀字節”技術專家團隊，感謝您的關注！
第頁完，請繼續朗讀下一頁。喜歡 小編的世界，請記得按讚、收藏及分享

讀字節ReadByte

上述方式因為OSS和MySQL沒有事務關系，因此需要編輯文章過程中存儲圖片和存儲草稿都是分開設計，後台寫入是分開執行，查詢過程更適合前端異步獲取圖片，另外OSS需要額外的訪問授權。

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

方式2：
文章標題、作者、標簽、時間和內容存關系表，圖片存本地，地址存關系表，Nginx作為圖片查詢代理

上圖中實線為寫入過程，虛線為查詢過程。寫入本地文件的過程依然無法保證事務，因此仍需要後台分開執行，查詢過程Nginx的業務授權非常麻煩，需要引入Openresty和授權服務器的對接，而且文件的存儲存在文件數超過操作系統最大限制的可能，圖片缺乏可靠性備份機制。

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

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

如上圖方式一
：整存整取，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的手動分片不知道要輕松多少。

上圖中Mongos路由器作為接口，連接整個集群，將所有的讀寫請求指引到合適的分片上，配置服務器持久化分片集群的元數據，以及數據在分片之間進行遷移的歷史信息，而且配置服務器本身也是高可靠的。三、與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過程很大的麻煩。四、總結

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

我們是“讀字節”技術專家團隊，感謝您的關注！