前言

線上某IOT核心業(yè)務(wù)集群之前采用MySQL作為主存儲(chǔ)數(shù)據(jù)庫，隨著業(yè)務(wù)規(guī)模的不斷增加，MySQL已無法滿足海量數(shù)據(jù)存儲(chǔ)需求，業(yè)務(wù)面臨著容量痛點(diǎn)、成本痛點(diǎn)問題、數(shù)據(jù)不均衡問題等。

400億該業(yè)務(wù)遷移MongoDB后，同樣的數(shù)據(jù)節(jié)省了極大的內(nèi)存、CPU、磁盤成本，同時(shí)完美解決了容量痛點(diǎn)、數(shù)據(jù)不均衡痛點(diǎn)，并且實(shí)現(xiàn)了一定的性能提升。

此外，遷移時(shí)候的MySQL數(shù)據(jù)為400億，3個(gè)月后的現(xiàn)在對應(yīng)MongoDB集群數(shù)據(jù)已增長到1000億，如果以1000億數(shù)據(jù)規(guī)模等比例計(jì)算成本，實(shí)際成本節(jié)省比例會(huì)更高。遷移MongoDB后，除了解決業(yè)務(wù)痛點(diǎn)問題，同時(shí)也促進(jìn)了業(yè)務(wù)的快速迭代開發(fā)，業(yè)務(wù)不在關(guān)心數(shù)據(jù)庫容量痛點(diǎn)、數(shù)據(jù)不均衡痛點(diǎn)、成本痛點(diǎn)等問題。

當(dāng)前國內(nèi)很多mongod文檔資料、性能數(shù)據(jù)等還停留在早期的MMAP_V1存儲(chǔ)引擎，實(shí)際上從MongoDB-3.x版本開始，MongoDB默認(rèn)存儲(chǔ)引擎已經(jīng)采用高性能、高壓縮比、更小鎖粒度的wiredtiger存儲(chǔ)引擎，因此其性能、成本等優(yōu)勢相比之前的MMAP_V1存儲(chǔ)引擎更加明顯。

一、業(yè)務(wù)遷移背景

該業(yè)務(wù)在遷移MongoDB前已有約400億數(shù)據(jù)，申請了64套MySQL集群，由業(yè)務(wù)通過shardingjdbc做分庫分表，提前拆分為64個(gè)庫，每個(gè)庫100張表。主從高可用選舉通過依賴開源orchestrator組建，MySQL架構(gòu)圖如下圖所示：

說明：上圖中紅色代表磁盤告警，磁盤使用水位即將100%。如上圖所示，業(yè)務(wù)一年多前一次性申請了64套MySQL集群，單個(gè)集群節(jié)點(diǎn)數(shù)一主三從，每個(gè)節(jié)點(diǎn)規(guī)格如下：

• cpu：4
• mem：16G
• 磁盤：500G
• 總節(jié)點(diǎn)數(shù)：64*4=256
• SSD服務(wù)器

該業(yè)務(wù)運(yùn)行一年多時(shí)間后，總集群數(shù)據(jù)量達(dá)到了400億，并以每月200億速度增長，由于數(shù)據(jù)不均衡等原因，造成部分集群數(shù)據(jù)量大，持續(xù)性耗光磁盤問題。由于節(jié)點(diǎn)眾多，越來越多的集群節(jié)點(diǎn)磁盤突破瓶頸，為了解決磁盤瓶頸，DBA不停的提升節(jié)點(diǎn)磁盤容量。業(yè)務(wù)和DBA都面臨嚴(yán)重痛點(diǎn)，主要如下：

• 數(shù)據(jù)不均衡問題
• 節(jié)點(diǎn)容量問題
• 成本持續(xù)性增加

DBA工作量劇增(部分磁盤提升不了需要遷移數(shù)據(jù)到新節(jié)點(diǎn))，業(yè)務(wù)也提心吊膽

二、為何選擇MongoDB-附十大核心優(yōu)勢總結(jié)

業(yè)務(wù)遇到瓶頸后，基于MongoDB在公司已有的影響力，業(yè)務(wù)開始調(diào)研MongoDB，通過和業(yè)務(wù)接觸了解到，業(yè)務(wù)使用場景都是普通的增、刪、改、查、排序等操作，同時(shí)查詢條件都比較固定，用MongoDB完全沒任何問題。

此外，MongoDB相比傳統(tǒng)開源數(shù)據(jù)庫擁有如下核心優(yōu)索：

優(yōu)勢一：模式自由

MongoDB為schema-free結(jié)構(gòu)，數(shù)據(jù)格式?jīng)]有嚴(yán)格限制。業(yè)務(wù)數(shù)據(jù)結(jié)構(gòu)比較固定，該功能業(yè)務(wù)不用，但是并不影響業(yè)務(wù)使用MongoDB存儲(chǔ)結(jié)構(gòu)化的數(shù)據(jù)。

優(yōu)勢二：天然高可用支持

MySQL高可用依賴第三方組件來實(shí)現(xiàn)高可用，MongoDB副本集內(nèi)部多副本通過raft協(xié)議天然支持高可用，相比MySQL減少了對第三方組件的依賴。

優(yōu)勢三：分布式-解決分庫分表及海量數(shù)據(jù)存儲(chǔ)痛點(diǎn)

MongoDB是分布式數(shù)據(jù)庫，完美解決MySQL分庫分表及海量數(shù)據(jù)存儲(chǔ)痛點(diǎn)，業(yè)務(wù)無需在使用數(shù)據(jù)庫前評估需要提前拆多少個(gè)庫多少個(gè)表，MongoDB對業(yè)務(wù)來說就是一個(gè)無限大的表(當(dāng)前我司最大的表存儲(chǔ)數(shù)千億數(shù)據(jù)，查詢性能無任何影響)。

此外，業(yè)務(wù)在早期的時(shí)候一般數(shù)據(jù)都比較少，可以只申請一個(gè)分片MongoDB集群。而如果采用MySQL，就和本次遷移的IOT業(yè)務(wù)一樣，需要提前申請最大容量的集群，早期數(shù)據(jù)量少的時(shí)候嚴(yán)重浪費(fèi)資源。

優(yōu)勢四：完善的數(shù)據(jù)均衡機(jī)制、不同分片策略、多種片建類型支持

• 關(guān)于balance：支持自動(dòng)balance、手動(dòng)balance、時(shí)間段任意配置balance.
• 關(guān)于分片策略：支持范圍分片、hash分片，同時(shí)支持預(yù)分片。
• 關(guān)于片建類型：支持單自動(dòng)片建、多字段片建

優(yōu)勢五：不同等級的數(shù)據(jù)一致性及安全性保證

MongoDB在設(shè)計(jì)上根據(jù)不同一致性等級需求，支持不同類型的Read Concern 、Write Concern讀寫相關(guān)配置，客戶端可以根據(jù)實(shí)際情況設(shè)置。此外，MongoDB內(nèi)核設(shè)計(jì)擁有完善的rollback機(jī)制來保證數(shù)據(jù)安全性和一致性。

優(yōu)勢六：高并發(fā)、高性能

為了適應(yīng)大規(guī)模高并發(fā)業(yè)務(wù)讀寫，MongoDB在線程模型設(shè)計(jì)、并發(fā)控制、高性能存儲(chǔ)引擎等方面做了很多細(xì)致化優(yōu)化。

優(yōu)勢七：wiredtiger高性能存儲(chǔ)引擎設(shè)計(jì)

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

• WiredTiger提供了低延遲和高吞吐量
• 處理比內(nèi)存大得多的數(shù)據(jù)，而不會(huì)降低性能或資源
• 系統(tǒng)故障后可快速恢復(fù)到最近一個(gè)checkpoint
• 支持PB級數(shù)據(jù)存儲(chǔ)
• 多線程架構(gòu)，盡力利用樂觀鎖并發(fā)控制算法減少鎖操作
• 具有hot-caches能力
• 磁盤IO最大化利用，提升磁盤IO能力
• 其他

優(yōu)勢八：成本節(jié)省-WT引擎高壓縮比支持

• MongoDB對數(shù)據(jù)的壓縮支持snappy、zlib算法，在以往線上真實(shí)的數(shù)據(jù)空間大小與真實(shí)磁盤空間消耗進(jìn)行對比，可以得出以下結(jié)論：
• MongoDB默認(rèn)的snappy壓縮算法壓縮比約為2.2-4.5倍

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

此外，以線上已有的從MySQL、Es遷移到MongoDB的真實(shí)業(yè)務(wù)磁盤消耗統(tǒng)計(jì)對比，同樣的數(shù)據(jù)，存儲(chǔ)在MongoDB、MySQL、Es的磁盤占比≈1：3.5：6。

后續(xù)會(huì)有數(shù)千億hbase數(shù)據(jù)遷移MongoDB，到時(shí)候總結(jié)同樣數(shù)據(jù)MongoDB和Hbase的磁盤消耗比。

優(yōu)勢九：天然N機(jī)房(不管同城還是異地)多活容災(zāi)支持

MongoDB天然高可用機(jī)制及代理標(biāo)簽自動(dòng)識(shí)別轉(zhuǎn)發(fā)功能的支持，可以通過節(jié)點(diǎn)不同機(jī)房部署來滿足同城和異地N機(jī)房多活容災(zāi)需求，從而實(shí)現(xiàn)成本、性能、一致性的“三豐收”。更多機(jī)房多活容災(zāi)的案例詳見Qcon分享：

優(yōu)勢十：完善的客戶端均衡訪問策略

MongoDB客戶端訪問路由策略由客戶端自己指定，該功能通過Read Preference實(shí)現(xiàn)，支持primary 、primaryPreferred 、secondary 、secondaryPreferred 、nearest 五種客戶端均衡訪問策略。

分布式事務(wù)支持

MongoDB-4.2 版本開始已經(jīng)支持分布式事務(wù)功能，當(dāng)前對外文檔版本已經(jīng)迭代到 version-4.2.11，分布式事務(wù)功能也進(jìn)一步增強(qiáng)。此外，從 MongoDB-4.4 版本產(chǎn)品規(guī)劃路線圖可以看出，MongoDB 官方將會(huì)持續(xù)投入開發(fā)查詢能力和易用性增強(qiáng)功能，例如 union 多表聯(lián)合查詢、索引隱藏等。

三、MongoDB資源評估及部署架構(gòu)

業(yè)務(wù)開始遷移MongoDB的時(shí)候，通過和業(yè)務(wù)對接梳理，該集群規(guī)模及業(yè)務(wù)需求總結(jié)如下：

• 已有數(shù)據(jù)量400億左右
• 數(shù)據(jù)磁盤消耗總和30T左右
• 讀寫峰值流量4-5W/s左右，流量很小
• 同城兩機(jī)房多活容災(zāi)
• 讀寫分離
• 每月預(yù)計(jì)增加200億數(shù)據(jù)
• 滿足幾個(gè)月內(nèi)1500億新增數(shù)據(jù)需求

說明：數(shù)據(jù)規(guī)模和磁盤消耗按照單副本計(jì)算，例如MySQL 64個(gè)分片，256個(gè)副本，數(shù)據(jù)規(guī)模和磁盤消耗計(jì)算方式為：64個(gè)主節(jié)點(diǎn)數(shù)據(jù)量之和、64個(gè)分片主節(jié)點(diǎn)磁盤消耗之和。

1、MongoDB資源評估

分片數(shù)及存儲(chǔ)節(jié)點(diǎn)套餐規(guī)格選定評估過程如下：

內(nèi)存評估

我司都是容器化部署，以往經(jīng)驗(yàn)來看，MongoDB對內(nèi)存消耗不高，歷史百億級以上MongoDB集群單個(gè)容器最大內(nèi)存基本上都是64Gb，因此內(nèi)存規(guī)格確定為64G。

分片評估

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

磁盤評估

MySQL中已有數(shù)據(jù)400億，磁盤消耗30T。按照以網(wǎng)線上遷移經(jīng)驗(yàn)，MongoDB默認(rèn)配置磁盤消耗約為mysql的1/3-1/5，400億數(shù)據(jù)對應(yīng)MongoDB磁盤消耗預(yù)計(jì)8T?？紤]到1500億數(shù)據(jù)，預(yù)計(jì)4個(gè)分片，按照每個(gè)分片400億規(guī)模，預(yù)計(jì)每個(gè)分片磁盤消耗8T。

線上單臺(tái)物理機(jī)10多T磁盤，幾百G內(nèi)存，幾十個(gè)CPU，為了最大化利用服務(wù)器資源，我們需要預(yù)留一部分磁盤給其他容器使用。另外，因?yàn)槿萜鹘M套餐化限制，最終確定確定單個(gè)節(jié)點(diǎn)磁盤在7T。預(yù)計(jì)7T節(jié)點(diǎn)，4個(gè)分片存儲(chǔ)約1500億數(shù)據(jù)。

CPU規(guī)格評估

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

mongos代理及config server規(guī)格評估

此外，由于分片集群還有mongos代理和config server復(fù)制集，因此還需要評估m(xù)ongos代理和config server節(jié)點(diǎn)規(guī)格。由于config server只主要存儲(chǔ)路由相關(guān)元數(shù)據(jù)，因此對磁盤、CUP、MEM消耗都很低;mongos代理只做路由轉(zhuǎn)發(fā)只消耗CPU，因此對內(nèi)存和磁盤消耗都不高。最終，為了最大化節(jié)省成本，我們決定讓一個(gè)代理和一個(gè)config server復(fù)用同一個(gè)容器，容器規(guī)格如下：

• 8CPU/8G內(nèi)存/50G磁盤，一個(gè)代理和一個(gè)config server節(jié)點(diǎn)復(fù)用同一個(gè)容器。
• 分片及存儲(chǔ)節(jié)點(diǎn)規(guī)格總結(jié)：4分片/16CPU、64G內(nèi)存、7T磁盤。
• mongos及config server規(guī)格總結(jié)：8CPU/8G內(nèi)存/50G磁盤

2、集群部署架構(gòu)

由于該業(yè)務(wù)所在城市只有兩個(gè)機(jī)房，因此我們采用2+2+1(2mongod+2mongod+1arbiter模式)，在A機(jī)房部署2個(gè)mongod節(jié)點(diǎn)，B機(jī)房部署2個(gè)mongod節(jié)點(diǎn)，C機(jī)房部署一個(gè)最低規(guī)格的選舉節(jié)點(diǎn)，如下圖所示：

說明：

• 每個(gè)機(jī)房代理部署2個(gè)mongos代理，保證業(yè)務(wù)訪問代理高可用，任一代理掛掉，對應(yīng)機(jī)房業(yè)務(wù)不受影響;
• 如果機(jī)房A掛掉，則機(jī)房B和機(jī)房C剩余2mongod+1arbiter，則會(huì)在B機(jī)房mongod中從新選舉一個(gè)主節(jié)點(diǎn)。arbiter選舉節(jié)點(diǎn)不消耗資源;
• 客戶端配置nearest ，實(shí)現(xiàn)就近讀，確保請求通過代理轉(zhuǎn)發(fā)的時(shí)候，轉(zhuǎn)發(fā)到最近網(wǎng)絡(luò)時(shí)延節(jié)點(diǎn)，也就是同機(jī)房對應(yīng)存儲(chǔ)節(jié)點(diǎn)讀取數(shù)據(jù);
• 弊端：如果是異地機(jī)房，B機(jī)房和C機(jī)房寫存在跨機(jī)房寫場景。如果A B C為同城機(jī)房，則沒用該弊端，同城機(jī)房時(shí)延可以忽略。

四、業(yè)務(wù)全量+增量遷移方式

遷移過程由業(yè)務(wù)自己完成，通過阿里開源的datax工具實(shí)現(xiàn)，該遷移工具的更多細(xì)節(jié)可以參考：https://github.com/alibaba/DataX

五、性能優(yōu)化過程

該集群優(yōu)化過程按照如下兩個(gè)步驟優(yōu)化：數(shù)據(jù)遷移開始前的提前預(yù)優(yōu)化、遷移過程中瓶頸分析及優(yōu)化、遷移完成后性能優(yōu)化。

1、數(shù)據(jù)遷移開始前的提前預(yù)操作

和業(yè)務(wù)溝通確定，業(yè)務(wù)每條數(shù)據(jù)都攜帶有一個(gè)設(shè)備標(biāo)識(shí)ssoid，同時(shí)業(yè)務(wù)查詢更新等都是根據(jù)ssoid維度查詢該設(shè)備下面的單條或者一批數(shù)據(jù)，因此片建選擇ssoid。

分片方式

為了充分散列數(shù)據(jù)到4個(gè)分片，因此選擇hash分片方式，這樣數(shù)據(jù)可以最大化散列，同時(shí)可以滿足同一個(gè)ssoid數(shù)據(jù)落到同一個(gè)分片，保證查詢效率。

預(yù)分片

MongoDB如果分片片建為hashed分片，則可以提前做預(yù)分片，這樣就可以保證數(shù)據(jù)寫進(jìn)來的時(shí)候比較均衡的寫入多個(gè)分片。預(yù)分片的好處可以規(guī)避非預(yù)分片情況下的chunk遷移問題，最大化提升寫入性能。

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

注意事項(xiàng)：切記提前對ssoid創(chuàng)建hashed索引，否則對后續(xù)分片擴(kuò)容有影響。

就近讀

客戶端增加nearest 配置，從離自己最近的節(jié)點(diǎn)讀，保證了讀的性能。

mongos代理配置

A機(jī)房業(yè)務(wù)只配置A機(jī)房的代理，B機(jī)房業(yè)務(wù)只配置B機(jī)房代理，同時(shí)帶上nearest配置，最大化的實(shí)現(xiàn)本機(jī)房就近讀，同時(shí)避免客戶端跨機(jī)房訪問代理。

禁用enableMajorityReadConcern

禁用該功能后ReadConcern majority將會(huì)報(bào)錯(cuò)，ReadConcern majority功能注意是避免臟讀，和業(yè)務(wù)溝通業(yè)務(wù)沒該需求，因此可以直接關(guān)閉。

存儲(chǔ)引擎cacheSize規(guī)格選擇

單個(gè)容器規(guī)格：16CPU、64G內(nèi)存、7T磁盤，考慮到全量遷移過程中對內(nèi)存壓力，內(nèi)存碎片等壓力會(huì)比較大，為了避免OOM，設(shè)置cacheSize=42G。

2、數(shù)據(jù)全量遷移過程中優(yōu)化過程

全量數(shù)據(jù)遷移過程中，遷移速度較塊，內(nèi)存臟數(shù)據(jù)較多，當(dāng)臟數(shù)據(jù)比例達(dá)到一定比例后用戶讀寫請求對應(yīng)線程將會(huì)阻塞，用戶線程也會(huì)去淘汰內(nèi)存中的臟數(shù)據(jù)page，最終寫性能下降明顯。

wiredtiger存儲(chǔ)引擎cache淘汰策略相關(guān)的幾個(gè)配置如下:

由于業(yè)務(wù)全量遷移數(shù)據(jù)是持續(xù)性的大流量寫，而不是突發(fā)性的大流量寫，因此eviction_target、eviction_trigger、eviction_dirty_target、eviction_dirty_trigger幾個(gè)配置用處不大，這幾個(gè)參數(shù)閥值只是在短時(shí)間突發(fā)流量情況下調(diào)整才有用。

但是，在持續(xù)性長時(shí)間大流量寫的情況下，我們可以通過提高wiredtiger存儲(chǔ)引擎后臺(tái)線程數(shù)來解決臟數(shù)據(jù)比例過高引起的用戶請求阻塞問題，淘汰臟數(shù)據(jù)的任務(wù)最終交由evict模塊后臺(tái)線程來完成。

全量大流量持續(xù)性寫存儲(chǔ)引擎優(yōu)化如下：

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

3、全量遷移完成后，業(yè)務(wù)流量讀寫優(yōu)化

前面章節(jié)我們提到，在容器資源評估的時(shí)候，我們最終確定選擇單個(gè)容器套餐規(guī)格為如下：

• 16CPU、64G內(nèi)存、7T磁盤。

全量遷移過程中為了避免OOM，預(yù)留了約1/3內(nèi)存給MongoDB server層、操作系統(tǒng)開銷等，當(dāng)全量數(shù)據(jù)遷移完后，業(yè)務(wù)寫流量相比全量遷移過程小了很多，峰值讀寫OPS約2-4W/s。

也就是說，前量遷移完成后，cache中臟數(shù)據(jù)比例幾乎很少，基本上不會(huì)達(dá)到20%閥值，業(yè)務(wù)讀流量相比之前多了很多(數(shù)據(jù)遷移過程中讀流量走原MySQL集群)。為了提升讀性能，因此做了如下性能調(diào)整(提前建好索引)：

• 節(jié)點(diǎn)cacheSize從之前的42G調(diào)整到55G，盡量多的緩存熱點(diǎn)數(shù)據(jù)到內(nèi)存，供業(yè)務(wù)讀，最大化提升讀性能;
• 每天凌晨低峰期做一次cache內(nèi)存加速釋放，避免OOM。

上面的內(nèi)核優(yōu)后后，業(yè)務(wù)測時(shí)延監(jiān)控曲線變化，時(shí)延更加平穩(wěn)，平均時(shí)延也有25%左右的性能優(yōu)后，如下圖所示：

六、遷移前后，業(yè)務(wù)測時(shí)延統(tǒng)計(jì)對比(MySQL vs MongoDB)

遷移前業(yè)務(wù)測時(shí)延監(jiān)控曲線(平均時(shí)延7ms, 2月1日數(shù)據(jù)，此時(shí)mysql集群只有300億數(shù)據(jù))： 

遷移MongoDB后并且業(yè)務(wù)流量全部切到MongoDB后業(yè)務(wù)測時(shí)延監(jiān)控曲線(平均6ms, 3月6日數(shù)據(jù)，此時(shí)MongoDB集群已有約500億數(shù)據(jù)) 

總結(jié)：

• MySQL(300億數(shù)據(jù))時(shí)延：7ms
• MongoDB(500億數(shù)據(jù))時(shí)延：6ms

七、遷移成本收益對比

1、MySQL集群規(guī)格及存儲(chǔ)數(shù)據(jù)最大量

原mysql集群一共64套，每套集群4副本，每個(gè)副本容器規(guī)格：4CPU、16G mem、500G磁盤，總共可以存儲(chǔ)400億數(shù)據(jù)，這時(shí)候大部分節(jié)點(diǎn)已經(jīng)開始磁盤90%水位告警，DBA對部分節(jié)點(diǎn)做了磁盤容量提升。

總結(jié)如下：

• 集群總套數(shù)：64
• 單套集群副本數(shù)：4
• 每個(gè)節(jié)點(diǎn)規(guī)格：4CPU、16G mem、500G磁盤
• 該64套集群最大存儲(chǔ)數(shù)據(jù)量：400億

2、MongoDB集群規(guī)格及存儲(chǔ)數(shù)據(jù)最大量

MongoDB從MySQL遷移過來后，數(shù)據(jù)量已從400億增加到1000億，并以每個(gè)月增加200億數(shù)據(jù)。MongoDB集群規(guī)格及存儲(chǔ)數(shù)據(jù)量總結(jié)如下：

• 分片數(shù)：4
• 單分片副本數(shù)：4
• 每個(gè)節(jié)點(diǎn)規(guī)格：16CPU、64G mem、7T磁盤
• 四個(gè)分片存儲(chǔ)數(shù)據(jù)量：當(dāng)前已存1000億，最大可存1500億數(shù)據(jù)。

3、成本對比計(jì)算過程

說明：由于MySQL遷移MongoDB后，數(shù)據(jù)不在往MySQL中寫入，流量切到MongoDB時(shí)候MySQL中大約存儲(chǔ)有400億數(shù)據(jù)，因此我們以這個(gè)時(shí)間點(diǎn)做為對比時(shí)間點(diǎn)。以400億數(shù)據(jù)為基準(zhǔn)，資源消耗對比如下表(每個(gè)分片只計(jì)算主節(jié)點(diǎn)資源消耗，因?yàn)镸ySQL和MongoDB都是4副本)：

由于MongoDB四個(gè)分片還有很多磁盤冗余，該四個(gè)分片相比400億數(shù)據(jù)，還可以寫1100億數(shù)據(jù)。如果按照1500億數(shù)據(jù)計(jì)算，如果還是按照MySQL之前套餐規(guī)格，則MySQL集群數(shù)需要再增加三倍，也就是總集群套數(shù)需要64*4=256套，資源占用對比如下：

4、收益總結(jié)(客觀性對比)

從上面的內(nèi)容可以看出，該業(yè)務(wù)遷移MongoDB后，除了解決了業(yè)務(wù)容量痛點(diǎn)、促進(jìn)業(yè)務(wù)快速迭代開發(fā)、性能提升外，成本還節(jié)省了數(shù)倍。成本節(jié)省總結(jié)如下：

400億維度計(jì)算(mysql和MongoDB都存儲(chǔ)相同的400億數(shù)據(jù))：

CPU和內(nèi)存成本比例：4:1

磁盤成本比例：3.3:1

1500億維度計(jì)算(假設(shè)mysql集群都采用之前規(guī)格等比例換算)：

CPU和內(nèi)存成本比例：16:1

磁盤成本比例：3.3:1

從上面的分析可以看出，數(shù)據(jù)量越大，按照等比例換算原則，MongoDB存儲(chǔ)成本會(huì)更低，原因如下：

CPU/內(nèi)存節(jié)省原因：

主要是因?yàn)镸ongoDB海量數(shù)據(jù)存儲(chǔ)及高性能原因，索引建好后，單實(shí)例單表即使幾百億數(shù)據(jù)，讀寫也是ms級返回(注意：切記查詢更新建好索引)。

此外，由于MongoDB分布式功能，對容量評估更加方便，就無需提前一次性申請很多套mysql，而是根據(jù)實(shí)際需要可以隨時(shí)加分片。

磁盤節(jié)省原因：

MongoDB存儲(chǔ)引擎wiredtiger默認(rèn)高壓縮、高性能。

最后，鑒于客觀性成本評價(jià)，CPU/內(nèi)存成本部分可能會(huì)有爭議，比如mysql內(nèi)存和CPU是否申請的時(shí)候就申請過大。MongoDB對應(yīng)CPU也同樣存在該問題，例如申請的單個(gè)容器是16CPU，實(shí)際上真實(shí)只消耗了幾個(gè)CPU。

但是，磁盤節(jié)省是實(shí)實(shí)在在的，是相同數(shù)據(jù)情況下mysql和MongoDB的真實(shí)磁盤消耗對比。

當(dāng)前該集群總數(shù)據(jù)量已經(jīng)達(dá)到近千億，并以每個(gè)月200億規(guī)模增加，單從容器計(jì)費(fèi)層面上換算，1000億數(shù)據(jù)按照等比例換算，預(yù)計(jì)節(jié)省成本10倍。

八、最后：千億級中等規(guī)模MongoDB集群注意事項(xiàng)

MongoDB無需分庫分表，單表可以無限大，但是單表隨著數(shù)據(jù)量的增多會(huì)引起以下問題：

切記提前建好索引，否則影響查詢更新性能(數(shù)據(jù)越多，無索引查詢掃描會(huì)越慢)。

切記提前評估好業(yè)務(wù)需要那些索引，單節(jié)點(diǎn)單個(gè)表數(shù)百億數(shù)據(jù)，加索引執(zhí)行時(shí)間較長。

服務(wù)器異常情況下節(jié)點(diǎn)替換時(shí)間相比會(huì)更長。

切記數(shù)據(jù)備份不要采用mongodump/mongorestore方式，而是采用熱備或者文件拷貝方式備份。

節(jié)點(diǎn)替換盡量從備份中拷貝數(shù)據(jù)加載方式恢復(fù)，而不是通過主從全量同步方式，全量同步過程較長。

九、未來挑戰(zhàn)(該集群未來萬億級實(shí)時(shí)數(shù)據(jù)規(guī)模挑戰(zhàn))

隨著時(shí)間推移，業(yè)務(wù)數(shù)據(jù)增長也會(huì)越來越多，單月數(shù)據(jù)量增長曲線預(yù)計(jì)會(huì)直線增加(當(dāng)前每月數(shù)據(jù)量增加200億左右)，預(yù)計(jì)未來2-3年該集群總數(shù)據(jù)量會(huì)達(dá)到萬億級，分片數(shù)也會(huì)達(dá)到20個(gè)分片左右，可能會(huì)遇到各自各樣的問題。

• 但是，IOT業(yè)務(wù)數(shù)據(jù)存在明顯的冷數(shù)問題，一年前的數(shù)據(jù)用戶基本上不會(huì)訪問，因此我們考慮做如下優(yōu)后來滿足性能、成本的進(jìn)一步提升：冷數(shù)據(jù)歸檔到低成本SATA盤
• 冷數(shù)據(jù)提升壓縮比，最大化減少磁盤消耗
• 如何解決冷數(shù)據(jù)歸檔sata盤過程中的性能問題

十、最后說明(業(yè)務(wù)場景)

本千億級IOT業(yè)務(wù)使用場景總結(jié)如下：

• 本分享的業(yè)務(wù)數(shù)據(jù)讀、更新、排序等都可以走索引，包括單字段索引、多字段索引、數(shù)組索引，所有查詢和更新都能確定走具體的某個(gè)最優(yōu)索引。
• 查詢都是單表查詢，不涉及多表聯(lián)合查詢。
• 數(shù)據(jù)庫場景非常重要，脫離業(yè)務(wù)場景談數(shù)據(jù)庫優(yōu)劣無任何意義。例如本文的業(yè)務(wù)場景，業(yè)務(wù)能確定需要建那些索引，同時(shí)所有的更新、查詢、排序都可以對應(yīng)具體的最優(yōu)索引，因此該場景就非常適合MongoDB。
• 每種數(shù)據(jù)庫都有其適合的業(yè)務(wù)場景，沒有萬能的數(shù)據(jù)庫。此外，不能因?yàn)槟撤N場景不適合而全盤否定沒數(shù)據(jù)庫，主流數(shù)據(jù)庫都有其存在的意義，千萬不能因?yàn)槟撤N場景下的不合適而全盤否定某個(gè)數(shù)據(jù)庫。

作者介紹

楊亞洲，前滴滴出行專家工程師，現(xiàn)任OPPO文檔數(shù)據(jù)庫MongoDB負(fù)責(zé)人，負(fù)責(zé)數(shù)萬億級數(shù)據(jù)量文檔數(shù)據(jù)庫MongoDB內(nèi)核研發(fā)、性能優(yōu)化及運(yùn)維工作，一直專注于分布式緩存、高性能服務(wù)端、數(shù)據(jù)庫、中間件等相關(guān)研發(fā)。后續(xù)持續(xù)分享《MongoDB內(nèi)核源碼設(shè)計(jì)、性能優(yōu)化、最佳運(yùn)維實(shí)踐》。