我10億級ES資料遷到MongoDB節省90%成本!--轉載

轉載:https://www.sohu.com/na/467051591_411876

作者介紹

楊亞洲，前滴滴出行專家工程師，現任OPPO檔案資料庫MongoDB負責人，負責數萬億級資料量檔案資料庫MongoDB內核研發、性能優化及運維作業，一直專注于分布式快取、高性能服務端、資料庫、中間件等相關研發，后續持續分享《MongoDB內核原始碼設計、性能優化、最佳運維實踐》，

前言

某智能產品業務資料之前存盤在Elasticsearch(Es)中，磁盤占用約30T(按照單副本計算)，總資料量25億，按照不同業務分類分別存在于不同表中，遷移前，業務存在較嚴重的性能及成本問題，當前業務已經遷移部分資料到MongoDB中，遷移后效果明顯，成本實作十倍級節省，業務抖動問題也得以解決，

當前我司已有數百億Es資料遷移MongoDB，同時也有數百億MongoDB遷移Es，根本原因業務就是選型錯誤引起，

本文以該場景業務遷移作為案例，主要分享以下方面的內容：

• MongoDB適用場景及不適用場景
• MongoDB和Es各自優勢
• MongoDB和Es同樣資料，真實磁盤消耗對比
• 對《從MongoDB遷移到ES后，我們減少了80%的服務器》一文的一些不同看法

沒有萬能的資料庫，本文最后會總結MongoDB和Es各自的適用場景，以客觀立場分析評價MongoDB和Es，拒絕“捧一個，踩一個”，

Es絕對是一款優秀的搜索引擎，在模糊匹配、全文搜索、復雜檢索等方面相比MongoDB擁有更大的優勢，

本文對應業務場景查詢比較簡單，查詢更新等條件都是固定欄位，不涉及復雜檢索，所以在此場景MongoDB更具優勢，另外，MongoDB當前默認的wiredtiger存盤引擎，在高壓縮、高性能、鎖粒度等方面進一步提升了MongoDB在該場景下的優勢，

我司已有多個業務數百億級資料從Es遷移MongoDB，由于其他業務遷移MongoDB的時間較早，之前沒有詳細記錄遷移前后的ES和MongoDB詳細資源對比，只有大概資源消耗比值，為了盡量客觀評價遷移前后的資料對比，因此選擇近期正在從Es遷移MongoDB的一個集群，同時記錄源集群和目的集群的詳細資源占用情況，這樣的對比結果會更加客觀真實，

一 業務背景

該業務存盤智能產品相關資料，總資料量20多億，單個集群ES磁盤消耗約30T，業務遷移背景如下（以下為業務開發同事整理)：

• Es集群不太穩定，造成秒級耗時，對我們業務影響挺大，感知非常明顯；
• 具體我們業務需求，主要是根據用戶id來進行精確查詢，沒有復雜全文檢索、模糊查詢等需求，所以其實用不到Es的優點；
• Es成本太高，

二 源Elasticsearch集群資源及部署情況

源ES集群業務在兩個機房各申請了一個集群，由業務自己通過雙寫的方式來保障資料一致性，當一個集群例外業務自己切流量到另外一個集群，

源ES集群部署架構及資源規格如下：

1 源Elasticsearch集群部署架構

如上圖所示，由于為了實作兩機房雙活容災及 [防止] 單集群抖動引起的業務故障，在A機房和B機房各搭建了一個ES集群，業務通過雙寫來自己維護兩個集群的資料一致性，

當A機房集群1例外，或者A機房掉電，則業務切流量到B機房備集群2，對應架構圖如下：

2 集群資源規格

A機房集群1和B機房集群2內部部署架構完全已有，單個集群總共有26個節點，每個節點都部署在容器中，單個容器規格資源如下所示：

• CPU：32
• 記憶體：64G
• 磁盤：2T
• 磁盤型別：SSD

單個集群總資源消耗如下：

• CPU：32*26=832
• 記憶體：64G*32=2048G
• 磁盤：2T*32=64T

兩個集群總資源消耗如下：

• CPU：32*26*2=1664
• 記憶體：64G*32*2=4096G
• 磁盤：2T*32*2=128T

3 源集群架構業務痛點

從上面的分析可以看出，為了保障業務多活和集群高可用，業務通過雙寫實作，例外后業務自己判斷切換，這增加了業務痛點，該架構主要痛點如下：

• 成本高，本身每個集群都是多副本，第2個備集群進一步增加了成本；
• 增加了業務開發難度，業務需要雙寫邏輯；
• 資料一致性無法得到保障，例如集群1例外或者故障，業務讀寫切到集群2，當集群1恢復正常，例外這斷時間內，集群2的資料會比集群1多；
• 不利于業務快速迭代開發；
• 業務只是按照固定欄位做查詢，查詢條件單一，這種場景選擇MongoDB本身性能會更好，

三 目的MongoDB集群架構

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

• 總資料量20多億；
• Es資料單集群磁盤消耗總和30.5T左右；
• 讀寫峰值流量流量很小，幾百上千；
• 同城兩機房多活容災；

1 MongoDB資源評估

分片數及存盤節點套餐規格選定評估程序如下:

• 記憶體評估

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

• 分片評估

業務讀寫流量很低，但是資料量較大，因此分片數確定為2個分片，

• 磁盤評估

按照以往測驗驗證及線上真實資料遷移對比，同樣的資料存入MongoDB和Es中真實磁盤消耗占比如下：

• MongoDB:Es ≈ 1：6

25億Es真實磁盤消耗30.5T，預計MongoDB磁盤消耗5T左右，考慮到未來資料增長，我們按照50億資料計算，預計需要10T空間，2個分片，因此每個分片5T資料，最終確定單個mongod實體容器磁盤規格5T，

• CPU規格評估

由于容器調度套餐化限制，因此CPU只能限定為16CPU(實際上用不了這么多CPU)，

• mongos代理及config server規格評估

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

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

分片及存盤節點規格總結：2分片/16CPU、64G記憶體、5T磁盤，

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

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 C為同城機房，則沒用該弊端，同城機房時延可以忽略，

四 性能優化程序

該集群優化程序按照如下兩個步驟優化：資料遷移開始前的提前預優化、遷移程序中瓶頸分析及優化、遷移完成后性能優化，

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

和業務溝通確定，業務每條資料都攜帶有唯一_id（用戶生成的，不是MongoDB內部生成），同時業務查詢更新等都是根據_id維度查詢該設備下面的單潭訓者一批資料，因此片建選擇_id，

• 分片方式

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

• 預分片

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

sh.shardCollection("user_xxx.user_xxx", {_id:"hashed"}, false, { numInitialChunks: 8192} )

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

• 就近讀

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

• mongos代理配置

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

• 禁用enableMajorityReadConcern

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

MongoDB默認使能了enableMajorityReadConcern，該功能開啟對性能有一定影響，參考：

1、MongoDB readConcern 原理決議：

https://developer.aliyun.com/article/60553

2、OPPO百萬級高并發MongoDB集群性能數十倍提升優化實踐：

https://mongoing.com/archives/29934

3、MongoDB原始碼分析、更多實踐案例細節：

https://github.com/y123456yz/reading-and-annotate-mongodb-3.6

• 存盤引擎cacheSize規格選擇

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

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)"})

更多存盤引擎及mongodb內核涉及實作參考：

mongodb原始碼分析、更多實踐案例細節：

https://github.com/y123456yz/reading-and-annotate-mongodb-3.6

3 讀流量切入MongoDB集群后內核優化

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

16CPU、64G記憶體、5T磁盤，

全量遷移程序中為了避免OOM，預留了約1/3記憶體給mongodb server層、作業系統開銷等，當資料遷移完后，業務寫流量相比全量遷移程序小了很多，

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

• 節點cacheSize從之前的42G調整到55G，盡量多的快取熱點資料到記憶體，供業務讀，最大化提升讀性能，
• 每天凌晨低峰期做一次cache記憶體加速釋放，避免OOM，

五 遷移MongoDB后性能對比

當前已有2個表從Es遷移到該MongoDB集群，同時該業務新增了15億其他業務資料到該集群，當前目的MongoDB集群已有近20億資料，

1 Es時延情況

由于該集群ES沒有歷史時延統計曲線統計，因此ES的時延統計只有以下現象(來自業務方反饋)：

查詢秒級耗時，對我們業務影響挺大，感知非常明顯，

2 MongoDB集群時延曲線

從上面的監控可以看出，由于除了遷移有源Es的資料，另外還有該業務的其他業務資料流量流向該集群，因此MongoDB集群流量相比Es會更高，MongoDB整體時延約1.5ms左右，遠遠好于之前Es的秒級時延抖動，

六 遷移成本收益對比

1 ElasticSearch集群規格

原Es單個集群一共26個節點，每個節點副本容器規格：32CPU、64Gmem、2T磁盤，磁盤型別SSD，單個集群規格總結如下：

• 單集群節點總數：26
• 每個節點規格：32CPU、64Gmem、2T磁盤
• 總資料量：25億
• 為了實作機房多活容災和業務高可用，實際部署了兩個Es集群，實際規格成本還的在上面的基礎上增加一倍，

2  MongoDB集群規格

當前該MongoDB集群已有約16億資料(其中部分為Es集群以外資料，該集群除了存盤部分Es遷移過來的資料，還存盤該業務線其他業務資料)，該MongoDB集群規格如下：

• 分片數：2
• 單分片副本數：4
• 每個節點規格：16CPU、64G mem、5T磁盤
• 兩個分片預計存盤最大資料量：預計存盤Es集群中總資料量的兩倍，

3 成本對比計算程序

• CPU、MEM記憶體成本對比計算程序

源Es兩個集群和目的MongoDB集群資源對比如下：

說明：由于集群部署方式可能有很多冗余，上面的CPU和記憶體成本比對比實際上不客觀，可能Es部署時候規格設定浪費，當然，MongoDB實際上CPU資源也非常空閑，所以CPU和記憶體指標對比無太大參考作用，

• 磁盤成本對比計算程序(成本比約6：1)

由于目的MongoDB集群中當前除了有源ES遷移過來的部分表外，還有該業務的其他資料，為了保障磁盤對比的客觀性，磁盤對比選材程序如下(說明：源Es有兩個集群，這里只計算單個集群單分資料的磁盤消耗，如果按照兩個集群計算，磁盤成本比為12:1，這種對比方法不客觀)：

• 只對比從源Es中遷移到MongoDB中的表；
• 只對比源Es集群和目的MongoDB集群表中資料量完全一樣的表；
• 排除源ES遷移到MongoDB但是當前還沒有遷移完的表；
• 源Es集群只計算一個集群單副本的磁盤消耗；

通過上面的選擇演算法，基本上做到了同樣資料在Es和MongoDB中的對比，磁盤真實消耗對比結果如下(說明：以下資料的Es磁盤占用為單個Es集群單副本方式計算結果，如果算2個Es集群，Es磁盤還需要乘2，es由我司Es開發人員提供，為了客觀公平，Es按照一個集群單副本計算；MongoDB磁盤占用計算方法為2個分片主節點真實磁盤占用之和，包括資料磁盤消耗+索引磁盤消耗)：

從上面的資料對比可以看出，同樣的資料Es磁盤占用約為MongoDB磁盤占用的6倍，和之前其他Es遷移MongoDB程序的資料占用比值類似，

表1檔案內容如下：

{

"_id" : null,

"channel" : null,

"content" : "04A193398BE7xxx7E080E2C3CC7B3sxxxxxxxxxC99F9520B8CD0842638DB0F550E125xxxxxxxxxxxxxDB5D3F320642A42CECD3EB5C27714524D0C1BF2A0C6B607D0DFDB669D6633A0E48C65B2623EA15E6DBB0FBF643150E18DD3D0575BDE448C03735A8841E312F8AF0D2BF67D1D357D1AB6249BF3FA4E014C5Axxxxxxxxxxxxxx30C10487667",

"create_time" : ISODate("2021-02-16T09:56:03Z"),

"duid" : "6F9E856EDDBB5xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxF41B0676FB2DE2171C18450E683DE1E9523B518F266856E01B0D6855E29911E5D10F0FA7E4A8EE5816333D89296E7554F05A58",

"update_time" : ISODate("2021-02-16T09:56:03Z")

}

表2檔案內容如下：

{

"_id" : "F9654874C1A37F74DA5E862C408EDC45",

"channel" : "10001",

"content" : "BA7110279AF5XXXXXXXXX6D7ACB8D0F9XXXXXXXXXXXXXX5CDB4693BE949F70E78A20E",

"create_time" : ISODate("2021-01-21T11:49:46Z"),

"imei" : "F96548XXXXXXXXXXXXXXXXX2C408EDC45",

"update_time" : ISODate("2021-01-21T11:49:46Z")

}

七 Elasticsearch和MongoDB各自適用場景總結

由于業務開發對業務場景評估不到位，當前我司線上MongoDB和Es適用程序存在如下現象：

• 數百億Es資料遷移MongoDB
• 也有數百億MongoDB資料遷移到Es

從線上真實業務使用情況為例，以下場景不適合MongoDB，實際上也不適合mysql等資料庫：

• 8欄位以上的隨機組合查詢

有些業務場景，查詢條件是由用戶觸發，查詢條件不固定，可能存在多個欄位的隨機組合查詢，MongoDB和MySQL等資料庫，都需要手動創建索引，由于8欄位以上的隨機組合查詢情況種類太多，因此很難手動建索引覆寫所有場景，所以選擇Es更優，只是成本會更高，

• 全文檢索

雖然MongoDB也支持全文檢索，MongoDB-4.2以下版本全文檢索能力性能和ES沒法比，建議全文檢索適用Es，

MongoDB-4.2全文搜索已經開始支持Lucene 引擎，可能性能會有很大提升，暫時沒做研究，也沒做性能對比，后續有空在研究，

• 其他復雜檢索，例如非前綴模糊匹配查詢

例如查詢db.member.find({"name":{ $regex:/XXX/ }})，查詢name欄位包含XXX的查詢，這類查詢Es更優，因為mongodb、mysql等底層都是KV存盤，查找KEY的時候都是從左到右比較key字串，如果是非前綴匹配模糊查詢，就需要全表掃描，

查詢以某欄位為開頭的檔案，db.member.find({"name":{$regex:/^XXX/}})這類就比較適合用mongodb查詢，前綴匹配，

MongoDB和Es不同場景性能對比(以下為真實線上資料對比)：

最后，脫離業務場景評估一個資料庫優劣很不合適，主流資料庫都優其存在的意義，不能因為資料庫在某種場景下不合適而全盤否定該資料庫，

八 對《從MongoDB遷移到ES后，我們減少了80%的服務器》一文的不同看法

《從MongoDB遷移到ES后，我們減少了80%的服務器》一文中以下觀點個人認不太贊同，主要如下：

1 文章內容的不同看法

MongoDB近幾年持續排名全球前五，市值近兩年已翻數倍，當前市值近200億左右，DB-Engines Ranking排名得分持續提升，說明本身有自己得市場和應用場景，而不是浪得虛名，沒《從MongoDB遷移到ES后，我們減少了80%的服務器》一文中說的不堪一擊，

• 服務器80%節省？mongodb部署架構嚴重資源浪費

從該文章可以看出，單個檔案200多位元組，MongoDB存盤引擎wiredtiger默認高壓縮、高性能、細粒度鎖，單個復制集即可存盤數十億資料，你們用了十多個容器，

同樣的資料，默認mongodb磁盤占用是Es的六分之一，加上這是日志集群，MongoDB可以采用1mongod+1mongod+1arbiter部署，規格8c/32gb/100gb 2個容器就可以滿足要求，這樣的部署才是合理的，成本會比同樣資料Es減少數倍，如果用mongodb，本身2個8c/32gb/100gb+1個低規格選舉節點容器即可搞定的事，你用了15臺，

• 任意組合的，現有MongoDB是不支持的？

任意組合的查詢不是mongodb不支持，是建索引麻煩，包括mysql、tidb等資料庫都是需要手動一個一個建索引，

• 性能提高十倍？一個走索引一個不走索引，這種資料對比不客觀

這本身就是個資料庫選型問題，隨機組合條件太多，索引不好建，你應該把索引查詢條件對應索引建好后對比，不過多欄位的隨機組合查詢，確實不適合用mongodb，建索引麻煩，

建議把mongodb對應查詢索引建好，重新測驗下查詢性能資料，

• MongoDB單集合資料量超過10億條，此情況下即使簡單條件查詢性能也不理想？

我司最大的mongodb集群單表幾千億資料，查詢2ms以內，

10億規模對我們線上業務就是毛毛雨，我們把mongodb集群歸類為如下幾檔：

• 小規模集群：資料量<100億
• 中型集群：資料量100億到1000億之間
• 大型集群：資料量大于1000億

當前我司15%-20%左右集群是百億級以上集群，已成功實作單個集群萬億級離線資料讀寫存盤，當前正在挑戰單個萬億級實時在線資料高并發在線讀寫，

萬億級離線資料讀寫優化案例詳見：《用最少人力玩轉萬億級資料，我用的就是MongoDB！》

后續將分享《單集群萬億級在線資料高并發讀寫優化實踐》

• 沒有人敢在核心專案中使用MongoDB？

我司25%-35%以上資料存盤檔案、圖片等元資料，甚至包括少量交易集群，非常核心，當前我司規模早已超過萬億級，

2 文章以下回復的不同看法

• MongoDB有的，Es都有？

沒有萬能的資料庫，正如上文所述，MongoDB在高并發寫、固定欄位索引查詢方面的性能表現，此外MongoDB存盤引擎高壓縮高性能，在成本上面體現很明顯，

業務場景很重要，不能“捧一個，踩一個”，主流資料庫都有其存在的理由，排名第五絕不是浪得虛名，

• 只有用事務的才是核心資料？

不太贊成這樣定義核心資料，用事務的不一定是核心資料，不用事務的也未必不是核心資料，例如我司存盤的幾千億檔案、圖片等元資料，沒有用到事務，但是是非常核心的資料，丟失會造成嚴重后果，

3 業界對資料庫幾個錯誤認識(以OPPO接入業務程序真實案例分享)

結合公司內部使用MongoDB為例，有時候出現以下情況：一些不適合MongoDB的業務場景，例如全文檢索、8欄位以上的隨機組合查詢、非前綴匹配模糊查詢，這些場景本身不適合選用MongoDB，但是業務選型錯誤，造成使用程序中的瓶頸，

甚至有相關研發人員因為選型錯誤在各種群里面說：“遠離mongo，珍愛生命”(該業務有全文檢索需求)；此外還存在業務陣列索引使用不當引起集群抖動(該業務陣列用法沒建索引引起)，認為MongoDB設計有問題，這些都是極不負責的行為，

通過這些真實業務接觸程序中的案例，總結如下幾點：

• 沒有萬能的資料庫，切記結合自身業務場景，選擇最優資料庫；
• 主流資料庫都有其存在的理由，不要因為在某些場景不適合而全盤否定該資料庫其他層面的優勢，例如不能因為MongoDB在全文檢索等復雜檢索上面的弱勢而全面否定MongoDB，也不能因為Es在磁盤成本、高并發讀寫等方面的劣勢而否定Es在復雜檢索上面的優勢；
• 切記以偏概全，捧一個踩一個，這都是及其不客觀的行為，

轉載:楊亞洲先生的<<回懟篇：我10億級ES資料遷到MongoDB節省90%成本!>>

https://www.sohu.com/na/467051591_411876

標籤：NoSQL

上一篇：MongoDB高手課,讓你有底氣把簡歷加上熟練使用

下一篇：Oracle資料庫失效物件處理