千億級 資料 遷移mongodb成本節省及效能優化實踐

線上某IOT核心業務叢集之前採用 mysql作為主儲存資料庫，隨著業務規模的不斷增加， mysql已無法滿足海量資料儲存需求，業務面臨著容量痛點、成本痛點問題、資料不均衡問題等。

該業務儲存使用者IOT相關資料，同時凌晨低峰期通過 MongoDB Spark Connector 連結叢集做大資料分析。

400億該業務遷移 mongodb後，同樣的資料節省了極大的記憶體、 CPU、磁碟成本，同時完美解決了容量痛點、資料不均衡痛點，並且實現了一定的效能提升。

此外，遷移時候的mysql資料為 400億， 3個月後的現在對應 mongodb叢集資料已增長到 1000億，如果以 1000億資料規模等比例計算成本，實際成本節省比例會更高。

當前國內很多mongod文件資料、效能資料等還停留在早期的 MMAP_V1儲存引擎，實際上從 mongodb-3.x版本開始， mongodb預設儲存引擎已經採用高效能、高壓縮比、更小鎖粒度的 wiredtiger儲存引擎，因此其效能、成本等優勢相比之前的 MMAP_V1儲存引擎更加明顯。

關於作者

前滴滴出行技術專家，現任OPPO 文件資料庫  mongodb 負責人，負責  oppo 千萬級峰值  TPS/ 十萬億級資料量文件資料庫  mongodb 研發和運維工作，一直專注於分散式快取、高效能服務端、資料庫、中介軟體等相關研發。後續持續分享《  MongoDB 核心原始碼設計、效能優化、最佳運維實踐》

1.  業務遷移背景

該業務在遷移mongodb前已有約 400億資料，申請了 64套 mysql叢集，由業務通過 shardingjdbc 做分庫分表，提前拆分為64個庫，每個庫 100張表。主從高可用選舉通過依賴開源 orchestrator組建， mysql架構圖如下圖所示：

 說明： 上圖中紅色代表磁碟告警，很多節點磁碟使用水位即將100%。

如上圖所示，業務一年多前一次性申請了64套 MySQL叢集，單個叢集節點數一主三從，每個節點規格如下：

l  cpu： 4

l  mem： 16G

l  磁碟：500G

l  總節點數：64*4=256

l  SSD伺服器

該業務執行一年多時間後，總叢集資料量達到了400億，並以每月 200億速度增長，由於資料不均衡等原因，造成部分叢集資料量大，持續性耗光磁碟問題。由於節點眾多，越來越多的叢集節點磁碟突破瓶頸，為了解決磁碟瓶頸， DBA不停的提升節點磁碟容量。業務和 DBA都面臨嚴重痛點，主要如下：

①　 資料不均衡問題

②　 節點容量問題

③　 成本持續性增加

④　 DBA工作量劇增 (部分磁碟提升不了需要遷移資料到新節點 )，業務也提心吊膽

業務

2.  為何選擇mongodb-附十大核心優勢總結

業務遇到瓶頸後，基於mongodb在公司已有的影響力，業務開始調研 mongodb，通過和業務接觸瞭解到，業務使用場景都是普通的增、刪、改、查、排序等操作，同時查詢條件都比較固定，用 mongodb完全沒任何問題。

此外，mongodb相比傳統開源資料庫擁有如下核心優索：

l  優勢一：模式自由

mongodb為 schema-free結構，資料格式沒有嚴格限制。業務資料結構比較固定，該功能業務不用，但是並不影響業務使用 mongodb儲存結構化的資料。

l  優勢二： 天然高可用支援

mysql高可用依賴第三方元件來實現高可用， mongodb副本集內部多副本通過 raft協議天然支援高可用，相比 mysql減少了對第三方元件的依賴。

l  優勢三： 分散式 - 解決分庫分表及海量資料儲存痛點

mongodb是分散式資料庫，完美解決 mysql分庫分表及海量資料儲存痛點，業務無需在使用資料庫前評估需要提前拆多少個庫多少個表， mongodb對業務來說就是一個無限大的表 (當前我司最大的表儲存數千億資料，查詢效能無任何影響 )。

此外，業務在早期的時候一般資料都比較少，可以只申請一個分片mongodb叢集。而如果採用 mysql，就和本次遷移的 IOT業務一樣，需要提前申請最大容量的叢集，早期資料量少的時候嚴重浪費資源。

l  優勢四： 完善的資料均衡機制、不同分片策略、多種片建型別支援

關於balance：支援自動 balance、手動 balance、時間段任意配置 balance.

關於分片策略：支援範圍分片、hash分片，同時支援預分片。

關於片建型別：支援單自動片建、多欄位片建

l  優勢五：不同等級的 資料一致性及安全性保證

mongodb在設計上根據不同一致性等級需求，支援不同型別的 Read Concern   、Write Concern讀寫相關配置，客戶端可以根據實際情況設定 。此外，mongodb核心設計擁有完善的 rollback機制。

l  優勢六：高併發、高效能

為了適應大規模高併發業務讀寫，mongodb線上程模型設計、併發控制、高效能儲存引擎等方面做了很多細緻化優化。

l  優勢七：wiredtiger高效能儲存引擎設計

網上很多評論還停留在早期MMAPv1儲存引擎，相比 MMAPv1， wiredtiger引擎效能更好，壓縮比更高，鎖粒度更小，具體如下：

①　 WiredTiger提供了低延遲和高吞吐量

②　 處理比記憶體大得多的資料，而不會降低效能或資源

③　 系統故障後可快速恢復到最近一個checkpoint

④　 支援PB級資料儲存

⑤　 多執行緒架構，盡力利用樂觀鎖併發控制演算法減少鎖操作

⑥　 具有hot-caches能力

⑦　 磁碟IO最大化利用，提升磁碟 IO能力

⑧　 其他

更多WT儲存引擎設計細節可以參考：

l  優勢八：成本節省-WT引擎高壓縮比支援

    mongodb對資料的壓縮支援 snappy、 zlib演算法， 在以往線上真實的資料空間大小與真實磁碟空間消耗進行對比，可以得出以下結論：

①　 mongodb預設的 snappy壓縮演算法壓縮比約為 2.2-4.5倍

②　 zlib壓縮演算法壓縮比約為 4.5-7.5倍 (本次遷移採用 zlib高壓縮演算法 )

 

 

 

壓縮演算法	真實資料量	真實磁碟空間消耗
snappy壓縮演算法	3.5T	1 - 1.8T
zlib壓縮演算法	3.5T	0.5 - 0.7T

此外，以線上已有的從mysql、 Es遷移到 mongodb的真實業務磁碟消耗統計對比，同樣的資料，儲存在 mongodb、 Mysql、 Es的磁碟佔比 ≈ 1： 3.5： 6，不同資料儲存佔比有差距。

l  優勢九：天然N機房 (不管同城還是異地 )多活容災支援

mongodb天然高可用機制及代理標籤自動識別轉發功能的支援，可以通過節點不同機房部署來滿足同城和異地N機房多活容災需求，從而實現成本、效能、一致性的“三豐收”。更多機房多活容災的案例詳見Qcon分享：

l  優勢十：完善的客戶端均衡訪問策略

mongodb客戶端訪問路由策略由客戶端自己指定，該功能通過 Read Preference 實現 ，支援 primary   、primaryPreferred 、 secondary 、 secondaryPreferred 、 nearest 五種客戶端均衡訪問策略。

l  分散式事務支援

mongodb-4.2 版本開始已經支援分散式事務功能，當前對外文件版本已經迭代到  version-4.2.12，分散式事務功能也進一步增強。此外，從  mongodb-4.4 版本產品規劃路線圖可以看出， mongodb 官方將會持續投入開發查詢能力和易用性增強功能，例如  union 多表聯合查詢、索引隱藏等

3.  mongodb資源評估及部署架構

業務開始遷移mongodb的時候，通過和業務對接梳理，該叢集規模及業務需求總結如下：

①　 已有資料量400億左右

②　 資料磁碟消耗總和30T左右

③　 讀寫峰值流量4-5W/s左右，流量很小

④　 同城兩機房多活容災

⑤　 讀寫分離

⑥　 每月預計增加200億資料

⑦　 滿足幾個月內1500億新增資料需求

說明： 資料規模和磁碟消耗按照單副本計算，例如mysql 64個分片， 256個副本，資料規模和磁碟消耗計算方式為： 64個主節點資料量之和、 64個分片主節點磁碟消耗之和。

3.1 mongodb資源評估

    分片數及儲存節點套餐規格選定評估過程如下：

l  記憶體評估

我司都是容器化部署，以往經驗來看，mongodb對記憶體消耗不高，歷史百億級以上 mongodb叢集單個容器最大記憶體基本上都是 64Gb，因此記憶體規格確定為 64G。

l  分片評估

    業 務流量峰值3-5W/s，考慮到可能後期有更大峰值流量，因此按照峰值 10W/s寫， 5w/s讀，也就是峰值 15W/s評估，預計需要 4個分片。

l  磁碟評估

mysql中已有資料 400億，磁碟消耗 30T。按照以網線上遷移經驗， mongodb預設配置磁碟消耗約為 mysql的 1/3-1/5， 400億資料對應 mongodb磁碟消耗預計 8T。考慮到 1500億資料，預計 4個分片，按照每個分片 400億規模，預計每個分片磁碟消耗 8T。

線上單臺物理機10多 T磁碟，幾百 G記憶體，幾十個 CPU，為了最大化利用伺服器資源，我們需要預留一部分磁碟給其他容器使用。另外，因為容器組套餐化限制，最終確定確定單個節點磁碟在 7T。預計 7T節點， 4個分片儲存約 1500億資料。

l  CPU規格評估

由於容器排程套餐化限制，因此CPU只能限定為 16CPU(實際上用不了這麼多 CPU)。

l  mongos代理及 config server規格評估

此外，由於分片叢集還有mongos代理和 config server複製集，因此還需要評估 mongos代理和 config server節點規格。由於 config server只主要儲存路由相關後設資料，因此對磁碟、 CUP、 MEM消耗都很低； mongos代理只做路由轉發只消耗 CPU，因此對記憶體和磁碟消耗都不高。最終，為了最大化節省成本，我們決定讓一個代理和一個 config server複用同一個容器，容器規格如下：

8CPU/8G記憶體 /50G磁碟，一個代理和一個 config server節點複用同一個容器。

分片及儲存節點規格總結： 4分片 /16CPU、 64G記憶體、 7T磁碟。

mongos及 config server規格總結： 8CPU/8G記憶體 /50G磁碟

節點型別	單個節點容器規格	說明
shardServer儲存節點	16CPU、 64G記憶體、 7T磁碟	1個分片儲存約 400億資料 4個分片預計儲存 1500-1600億資料
mongos及 config server節點	8CPU/8G記憶體 /50G磁碟	一個代理和一個 config server節點複用同一個容器

3.2 叢集部署架構

    由於該業務所在城市只有兩個機房，因此我們採用2+2+1(2mongod+2mongod+1arbiter模式 )，在 A機房部署 2個 mongod節點， B機房部署 2個 mongod節點， C機房部署一個最低規格的選舉節點，如下圖所示：

說明：

①　 每個機房代理部署2個 mongos代理，保證業務訪問代理高可用，任一代理掛掉，對應機房業務不受影響。

②　 如果機房A掛掉，則機房 B和機房 C剩餘 2mongod+1arbiter，則會在 B機房 mongod中從新選舉一個主節點。 arbiter選舉節點不消耗資源

③　 客戶端配置nearest ，實現就近讀，確保請求通過代理轉發的時候，轉發到最近網路時延節點，也就是同機房對應儲存節點讀取資料。

④　 弊端：如果是異地機房，B機房和 C機房寫存在跨機房寫場景。 A B 為同城機房，則沒有該弊端，同城機房時延可以忽略。

4.  業務全量+增量遷移方式

遷移過程由業務自己完成，通過阿里開源的datax工具實現，該遷移工具的更多細節可以參考：

5. 效能優化過程

該叢集優化過程按照如下兩個步驟優化：資料遷移開始前的提前預優化、遷移過程中瓶頸分析及優化、遷移完成後效能優化。

5.1 資料遷移開始前的提前預操作

和業務溝通確定，業務每條資料都攜帶有一個裝置標識ssoid，同時業務查詢更新等都是根據 ssoid維度查詢該裝置下面的單條或者一批資料，因此片建選擇 ssoid。

l  分片方式

為了充分雜湊資料到4個分片，因此選擇 hash分片方式，這樣資料可以最大化雜湊，同時可以滿足同一個 ssoid資料落到同一個分片，保證查詢效率。

l  預分片

mongodb如果分片片建為 hashed分片，則可以提前做預分片，這樣就可以保證資料寫進來的時候比較均衡的寫入多個分片。預分片的好處可以規避非預分片情況下的 chunk遷移問題，最大化提升寫入效能。

sh.shardCollection("xxx.xxx", { ssoid :"hashed"}, false, { numInitialChunks: 8192} )

注意事項： 切記提前對ssoid建立 hashed索引，否則對後續分片擴容有影響。

l  就近讀

    客戶端增加nearest 配置，從離自己最近的節點讀，保證了讀的效能。

l  mongos代理配置

       A機房業務只配置 A機房的代理， B機房業務只配置 B機房代理，同時帶上 nearest配置，最大化的實現本機房就近讀，同時避免客戶端跨機房訪問代理。

l  禁用enableMajorityReadConcern

禁用該功能後ReadConcern majority將會報錯， ReadConcern majority功能注意是避免髒讀，和業務溝通業務沒該需求，因此可以直接關閉。

mongodb預設使能了 enableMajorityReadConcern，該功能開啟對效能有一定影響，參考：

MongoDB readConcern 原理解析

l  儲存引擎cacheSize規格選擇

     單個容器規格：16CPU、 64G記憶體、 7T磁碟，考慮到全量遷移過程中對記憶體壓力，記憶體碎片等壓力會比較大，為了避免 OOM，設定 cacheSize=42G。

5.2 資料全量遷移過程中優化過程

全量資料遷移過程中，遷移速度較塊，記憶體髒資料較多，當髒資料比例達到一定比例後使用者讀寫請求對應執行緒將會阻塞，使用者執行緒也會去淘汰記憶體中的髒資料page，最終寫效能下降明顯。

wiredtiger儲存引擎 cache淘汰策略相關的幾個配置如下 :

 

     由於業務全量遷移資料是持續性的大流量寫，而不是突發性的大流量寫，因此eviction_target、 eviction_trigger、 eviction_dirty_target、 eviction_dirty_trigger幾個配置用處不大，這幾個引數閥值只是在短時間突發流量情況下調整才有用。

     但是，在持續性長時間大流量寫的情況下，我們可以通過提高wiredtiger儲存引擎後臺執行緒數來解決髒資料比例過高引起的使用者請求阻塞問題，淘汰髒資料的任務最終交由 evict模組後臺執行緒來完成。

     全量大流量持續性寫儲存引擎優化如下：

db.adminCommand( { setParameter : 1, "wiredTigerEngineRuntimeConfig" : "eviction=(threads_min=4, threads_max=20)"})

5.3 全量遷移完成後，業務流量讀寫優化

前面章節我們提到，在容器資源評估的時候，我們最終確定選擇單個容器套餐規格為如下：

16CPU、 64G記憶體、 7T磁碟。

全量遷移過程中為了避免OOM，預留了約 1/3記憶體給 mongodb server層、作業系統開銷等，當全量資料遷移完後，業務寫流量相比全量遷移過程小了很多，峰值讀寫 OPS約 2-4W/s。

也就是說，前量遷移完成後，cache中髒資料比例幾乎很少，基本上不會達到 20%閥值，業務讀流量相比之前多了很多 (資料遷移過程中讀流量走原 mysql叢集 )。為了提升讀效能，因此做了如下效能調整 (提前建好索引 )：

l  節點cacheSize從之前的 42G調整到 55G，儘量多的快取熱點資料到記憶體，供業務讀，最大化提升讀效能。

l  每天凌晨低峰期做一次cache記憶體加速釋放，避免 OOM。

    上面的核心優後後，業務測時延監控曲線變化，時延更加平穩，平均時延也有25%左右的效能優後，如下圖所示：

6.  遷移前後，業務測時延統計對比(Mysql vs mongodb)

6.1 效能收益對比

l  遷移前業務測時延監控曲線(平均時延 7ms,  2月 1日資料，此時 mysql叢集只有 300億資料 )：

l  遷移mongodb後並且業務流量全部切到 mongodb後業務測時延監控曲線 (平均 6ms,  3月 6日資料，此時 mongodb叢集已有約 500億資料 ))

總結：

l  mysql(300億資料 )時延：約 7ms

l  mongodb(500億資料 )時延：約 6ms

6.2 效能質疑解答

該文有同學可能質疑效能資料，認為mongodb例項規格是 16CPU/64G記憶體 /7T磁碟，而 mysql是 4CPU/16G記憶體 /500G磁碟。認為 mongodb規格更高，而 mysql資源規格低。但是忽略了單個節點承載的資料量和流量這個因素，按照單例項對比，總結如下 (由於只記錄了 mysql 300億時候、 mongodb 500億時候的業務測時延，因此還是以這兩個時間點為例比較 )。

Mysql和 mongodb的 CPU都不是瓶頸，都很空閒，兩者之間容器規格唯一區別就是記憶體，單例項規格、資料量、業務測時延等對比總結 (單例項 mysql資料量約 300/64=4.7億， mongodb約 125億 )：

 如果mysql採用 mongodb同樣的規格，由於 mysql同樣資料磁碟消耗是 mongodb 3.3倍，因此需要 22T左右磁碟，並且承擔同樣的資料量和流量，效能會不會好於方案 1？這個不是很確定，因為都是線上環境，不可能為了驗證這個測試而大費周章。

如上，方案3和方案 1、方案 2的效能對比有待驗證。實際上， mongodb當前 4個分片已經 1000億資料了，客戶端訪問時延基本上沒有變化，還是約 6ms，因此實際上如果同等資源規格驗證， mysql單個節點需要承擔如下資料量和業務流量：

7.  遷移成本收益對比

7.1 Mysql叢集規格及儲存資料最大量

原mysql叢集一共 64套，每套叢集 4副本，每個副本容器規格： 4CPU、 16G mem、 500G磁碟，總共可以儲存 400億資料，這時候大部分節點已經開始磁碟 90%水位告警， DBA對部分節點做了磁碟容量提升。

總結如下：

①　 叢集總套數：64

②　 單套叢集副本數：4

③　 每個節點規格：4CPU、 16G mem、 500G磁碟

④　 該64套叢集最大儲存資料量： 400億

7.2 mongodb叢集規格及儲存資料最大量

mongodb從 mysql遷移過來後，資料量已從 400億增加到 1000億，並以每個月增加 200億資料。 mongodb叢集規格及儲存資料量總結如下：

①　 分片數：4

②　 單分片副本數：4

③　 每個節點規格：16CPU、 64G mem、 7T磁碟

④　 四個分片儲存資料量：當前已存1000億，最大可存 1500億資料。

7.3 成本對比計算過程

說明： 由於mysql遷移 mongodb後，資料不在往 mysql中寫入，流量切到 mongodb時候 mysql中大約儲存有 400億資料，因此我們以這個時間點做為對比時間點。以 400億資料為基準，資源消耗對比如下表 (每個分片只計算主節點資源消耗，因為 mysql和 mongodb都是 4副本 )：

資源項	mysql	mongodb	成本比
分片數	64	4	無對比意義
CPU總數	4*64=256	16*4=64	4:1
記憶體總數	16*64=1024G	64*4=256G	4:1
磁碟	主節點磁碟消耗總和 ≈ 30T	主節點磁碟消耗總和 ≈ 9T	3.3:1
是否還可寫資料	否，磁碟幾乎都滿了	是，還可以寫 1200億資料

由於mongodb四個分片還有很多磁碟冗餘，該四個分片相比 400億資料，還可以寫 1200億資料。如果按照 1600億資料計算，如果還是按照 mysql之前套餐規格，則 mysql叢集數需要再增加三倍，也就是總叢集套數需要 64*4=256套，資源佔用對比如下：

資源項	mysql	mongodb	成本比	說明
mysql叢集數 /mongodb分片數	64*4=256套	4	無意義
CPU總數	4*256=1024	16*4=64	16:1	可能有冗餘，只能反應一種趨勢，無嚴格意義對比
記憶體總數	16*256=4096G	64*4=256G	16:1
磁碟	主節點磁碟消耗總和約 30*4=120T	主節點磁碟消耗總和約 9*4=36T	3.3:1	同樣資料，各自真實磁碟佔用情況

7.4 收益總結 (客觀性對比 )

從上面的內容可以看出，該業務遷移mongodb後，除了解決了業務容量痛點、促進業務快速迭代開發、效能提升外，成本還節省了數倍。成本節省總結如下：

①　 400億維度計算 (mysql和 mongodb都儲存相同的 400億資料 )：

CPU和記憶體成本比例： 4:1

磁碟成本比例：3.3:1

②　 1500億維度計算 (mysql叢集都採用之前規格等比例換算 )：

CPU和記憶體成本比例： 16:1

磁碟成本比例：3.3:1

從上面的分析可以看出，資料量越大，按照等比例換算原則，mongodb儲存成本會更低，原因如下：

l  CPU/記憶體節省原因：

主要是因為mongodb海量資料儲存及高效能原因，索引建好後，單例項單表即使幾百億資料，讀寫也是 ms級返回 (注意：切記查詢更新建好索引 )。

此外，由於mongodb分散式功能，對容量評估更加方便，就無需提前一次性申請很多套 mysql，而是根據實際需要可以隨時加分片。

l  磁碟節省原因：

mongodb儲存引擎 wiredtiger預設高壓縮、高效能。

 

最後， 鑑於客觀性成本評價，CPU/記憶體成本部分可能會有爭議，比如 mysql記憶體和 CPU是否申請的時候就申請過大。 mongodb對應 CPU也同樣存在該問題，例如申請的單個容器是 16CPU，實際上真實只消耗了幾個 CPU。

但是，磁碟節省是實時在在的，是相同資料情況下mysql和 mongodb的真實磁碟消耗對比。

當前該叢集總資料量已經達到千億級，並以每個月200億規模增加，單從容器計費層面上換算， 1000億資料按照等比例換算，預計可節省極大的成本。

8.  最後：千億級規模mongodb叢集注意事項

mongodb無需分庫分表，單表可以無限大，但是單表隨著資料量的增多會引起以下問題：

①　 切記提前建好索引，否則影響查詢更新效能(資料越多，無索引查詢掃描會越慢 )。

②　 切記提前評估好業務需要那些索引，單節點單個表數百億資料，加索引執行時間較長。

③　 伺服器異常情況下節點替換時間相比會更長。

④　 切記資料備份不要採用mongodump/mongorestore方式，而是採用熱備或者檔案拷貝方式備份。

⑤　 節點替換儘量從備份中拷貝資料載入方式恢復，而不是通過主從全量同步方式，全量同步過程較長。

9.  未來挑戰(該叢集未來萬億級實時資料規模挑戰)

隨著時間推移，業務資料增長也會越來越多，單月資料量增長曲線預計會直線增加(當前每月資料量增加 200億左右 )，預計未來 2-3年該叢集總資料量會達到萬億級，分片數也會達到 20個分片左右，可能會遇到各自各樣的問題。

l  但是，IOT業務資料存在明顯的冷數問題，一年前的資料使用者基本上不會訪問，因此我們考慮做如下優後來滿足效能、成本的進一步提升：冷資料歸檔到低成本 SATA盤

l  冷資料提升壓縮比，最大化減少磁碟消耗

l  如何解決冷資料歸檔sata盤過程中的效能問題

冷熱歸檔儲存可以參考之前在Qcon、 dbaplus、 mongodb中文社群分享的另一篇文章：

10. 最後說明(業務場景總結)

本千億級IOT業務使用場景總結如下：

①　 本分享的業務資料讀、更新、排序等都可以走索引，包括單欄位索引、多欄位索引、陣列索引，所有查詢和更新都能確定走具體的某個最優索引。    

②　 查詢都是單表查詢，不涉及多表聯合查詢。

③　 大資料分析利用mongodb官方開源 實現。

資料庫場景非常重要，脫離業務場景談資料庫優劣無任何意義。例如本文的業務場景，業務能確定需要建那些索引，同時所有的更新、查詢、排序都可以對應具體的最優索引，因此該場景就非常適合mongodb。