數(shù)億MySQL數(shù)據(jù)七步走到MongoDB的操作過程

這篇文章給大家介紹數(shù)億MySQL數(shù)據(jù)七步走到MongoDB的操作過程，內(nèi)容非常詳細(xì)，感興趣的小伙伴們可以參考借鑒，希望對大家能有所幫助。

 一、問題

在好大夫在線內(nèi)部，S3系統(tǒng)負(fù)責(zé)各業(yè)務(wù)方操作日志的集中存儲(chǔ)、查詢和管理。目前，該系統(tǒng)日均查詢量數(shù)千萬次，插入量數(shù)十萬次。隨著日志量的不斷累積，主表已經(jīng)達(dá)到數(shù)十億，單表占用磁盤空間400G+。S3是業(yè)務(wù)早期就存在的系統(tǒng)，當(dāng)時(shí)為了簡單快速落地，使用了MySQL來存儲(chǔ)，隨著業(yè)務(wù)的不斷增長，同時(shí)也要兼顧性能和可擴(kuò)展性，到了必須要重新選型的時(shí)候了。

新項(xiàng)目命名為：LogStore。

二、目標(biāo)

1、安全性

S3系統(tǒng)在設(shè)計(jì)之初，沒有按業(yè)務(wù)系統(tǒng)考慮數(shù)據(jù)隔離，而是直接采用 key(系統(tǒng) + 類名 + id) + 有限固定字段 + 序列化value 的方式進(jìn)行存儲(chǔ)，這種方式顯然不便于后續(xù)集群拆分和管理。LogStore系統(tǒng)要在邏輯上進(jìn)行數(shù)據(jù)區(qū)域劃分，業(yè)務(wù)方在接入時(shí)要指定app進(jìn)行必要的權(quán)限驗(yàn)證，以區(qū)分不同業(yè)務(wù)數(shù)據(jù)，進(jìn)而再進(jìn)行插入和查詢操作。

2、通用性

S3主要提供一種3層結(jié)構(gòu)，采用MySQL固定字段進(jìn)行存儲(chǔ)，這就不可避免的會(huì)造成字段空間的浪費(fèi)。LogStore系統(tǒng)需要提供一種通用的日志存儲(chǔ)格式，由業(yè)務(wù)方自行規(guī)定字段含義，并且保留一定程度的可查詢維度。

3、高性能

S3系統(tǒng)的QPS在300+，單條數(shù)據(jù)最大1KB左右。LogStore系統(tǒng)要支持當(dāng)前QPS 10倍以上的寫入和讀取速度。

4、可審計(jì)

要滿足內(nèi)部安全審計(jì)的要求，LogStore系統(tǒng)不提供對數(shù)據(jù)的更新，只允許數(shù)據(jù)的插入和查詢。

5、易擴(kuò)展

LogStore系統(tǒng)以及底層存儲(chǔ)要滿足可擴(kuò)展特性，可以在線擴(kuò)容，滿足公司未來5年甚至更長時(shí)間的日志存儲(chǔ)需求，并且要最大化節(jié)省磁盤空間。

三、方案選型

為了達(dá)成改造目標(biāo)，本次調(diào)研了四種存儲(chǔ)改造方案，各種方案對比如下：

1、我們不合適—分庫分表

分庫分表主要分為應(yīng)用層依賴類中間件和代理中間件，無論哪種均需要修改現(xiàn)有PHP和Java框架，同時(shí)對DBA管理數(shù)據(jù)也帶來一定的操作困難。為了降低架構(gòu)復(fù)雜度，架構(gòu)團(tuán)隊(duì)否定了引入DB中間件的方案，還是要求運(yùn)維簡單、成本低的方案。

2、我們不合適—TiDB

TiDB也曾一度進(jìn)入了我們重點(diǎn)調(diào)研對象，只是由于目前公司的DB生態(tài)主要還是在MGR、MongoDB、MySQL上，在可預(yù)見的需求中，也沒有能充分發(fā)揮TiDB的場景，所以就暫時(shí)擱置了。

3、我們不合適—ElasticSearch

ELK-stack提供的套件確實(shí)讓ES很有吸引力，公司用ES集群也有較長時(shí)間了。ES優(yōu)勢在于檢索和數(shù)據(jù)分析領(lǐng)域，也正是因?yàn)槠錂z索和分析的功能的強(qiáng)大，無論寫入、查詢和存儲(chǔ)成本都比較高，在日志處理的這個(gè)場景下，性價(jià)比略低，所以也被pass了。

4、適合的選擇—MongoDB

業(yè)務(wù)操作日志讀多寫少，很適合文檔型數(shù)據(jù)庫MongoDB的特點(diǎn)。同時(shí)，MongoDB在業(yè)界得到了廣泛的使用，公司也有很多業(yè)務(wù)在使用，在MongoDB上積累了一定的運(yùn)維經(jīng)驗(yàn)，最終決定選擇MongoDB作為新日志系統(tǒng)存儲(chǔ)方案。

四、性能測試

為了驗(yàn)證MongoDB的性能能否達(dá)到要求，我們搭建了MongoDB集群，機(jī)器配置、架構(gòu)圖和測試結(jié)果如下：

1、機(jī)器配置

MongoDB集群3臺(tái)機(jī)器配置如下：

2、架構(gòu)圖架構(gòu)圖

3、測試場景架構(gòu)圖

本次MongoDB測試采用YCSB（https://github.com/brianfrankcooper/YCSB）性能測試工具，ycsb的workloads目錄下保存了6種不同的workload類型，代表了不同的壓測負(fù)載類型，本次我們只用到了其中5種，具體場景和測試結(jié)果如下。

(1) 插入平均文檔大小為5K，數(shù)據(jù)量為100萬，并發(fā)100，數(shù)據(jù)量總共5.265G 左右，執(zhí)行的時(shí)間以及磁盤壓力：

結(jié)論：插入100w數(shù)據(jù)，總耗時(shí)219s，平均insert耗時(shí)21.8ms，吞吐量4568/s。

(2) 測試90%讀，10%更新，并發(fā)100的場景：

結(jié)論：總耗時(shí)236s，read平均耗時(shí)23.6ms，update平均耗時(shí)23.56ms，吞吐量達(dá)到4225/s。

(3) 測試讀多寫少，100%讀 ，并發(fā)100場景：

結(jié)論：總耗時(shí)123s，平均read耗時(shí)12.3ms，吞吐量達(dá)到8090/s。

(4) 測試讀多寫少，90%讀，10%插入，并發(fā)100的場景：

結(jié)論：總耗時(shí)220s，read平均耗時(shí)21.9ms，insert平均耗時(shí)21.9ms，吞吐量達(dá)到4541/s。

(5) 測試混合讀寫，50%讀，25%插入、25%更新，并發(fā)100的場景：

結(jié)論：總耗時(shí)267s，read平均耗時(shí)26.7ms，update平均耗時(shí)26.7ms，insert平均耗時(shí)26.6ms，吞吐量為3739/s。

4、測試結(jié)果對比架構(gòu)圖

可以看出MongoDB適合讀多寫少的時(shí)候，性能最好，讀寫速率能滿足生產(chǎn)需求。

五、無縫遷移實(shí)踐

為了保障業(yè)務(wù)的無縫遷移，也為了最大化降低業(yè)務(wù)研發(fā)同學(xué)的投入成本，我們決定采用分階段切換的方案。

第一步：系統(tǒng)應(yīng)用層改造+LogStore系統(tǒng)搭建

首先，在S3系統(tǒng)中內(nèi)置讀開關(guān)和寫開關(guān)，可將讀寫流量分別引入到LogStore系統(tǒng)中，而新應(yīng)用的接入可以直接調(diào)用LogStore系統(tǒng)，此時(shí)結(jié)構(gòu)示意圖如下。

第二步：增量數(shù)據(jù)同步

為了讓S3系統(tǒng)和LogStore系統(tǒng)中新增數(shù)據(jù)達(dá)到一致，在底層數(shù)據(jù)庫采用Maxwell訂閱MySQL Binlog的方式同步到MongoDB中，示意圖如下：

Maxwell（http://maxwells-daemon.io）實(shí)時(shí)讀取MySQL二進(jìn)制日志binlog，并生成 JSON 格式的消息，作為生產(chǎn)者發(fā)送給 Kafka，Logstore系統(tǒng)消費(fèi)Kafka中的數(shù)據(jù)寫入到mongodb數(shù)據(jù)庫中。

至此，對于業(yè)務(wù)方現(xiàn)有日志類型，新增數(shù)據(jù)在底層達(dá)到雙寫目的，S3系統(tǒng)和LogStore系統(tǒng)存儲(chǔ)兩份數(shù)據(jù)；如果業(yè)務(wù)方新增日志類型，則直接調(diào)用LogStore系統(tǒng)接口即可。接下來，我們將對已有日志類型老數(shù)據(jù)進(jìn)行遷移。

第三步：存量數(shù)據(jù)遷移

此次遷移S3老數(shù)據(jù)采用php定時(shí)任務(wù)腳本(多個(gè))查詢數(shù)據(jù)，將數(shù)據(jù)投遞到RabbitMQ隊(duì)列中，LogStore系統(tǒng)從RabbitMQ隊(duì)列拉取消息進(jìn)行消費(fèi)存儲(chǔ)到MongoDB中，示意圖如下：

(1) 由于原mysql表中id為varchar類型并且非主鍵索引，只能利用ctime索引分批次進(jìn)行查詢，數(shù)據(jù)密集處進(jìn)行chunk投遞到mq隊(duì)列中。

(2) 數(shù)據(jù)無法一天就遷移完，遷移過程中可能存在中斷的情況。腳本采用定時(shí)任務(wù)每天執(zhí)行20h, 在上線時(shí)間停止執(zhí)行，同時(shí)將停止時(shí)間記錄到Redis中。

(3) 由于需要遷移數(shù)據(jù)量較大，在mq和消費(fèi)者能承受的情況下，盡可能多地增加腳本數(shù)量，縮短導(dǎo)數(shù)據(jù)的時(shí)間。

(4) 腳本執(zhí)行期間，觀察業(yè)務(wù)延時(shí)情況和MySQL監(jiān)控情況，發(fā)現(xiàn)有影響立即進(jìn)行調(diào)整，以保障不影響正常業(yè)務(wù)。

第四步：校驗(yàn)數(shù)據(jù)

老數(shù)據(jù)導(dǎo)入完成后，下面就要對老數(shù)據(jù)進(jìn)行校驗(yàn)，校驗(yàn)從兩個(gè)方面進(jìn)行: 數(shù)據(jù)量和數(shù)據(jù)完整性。

•  數(shù)據(jù)量：基于S3系統(tǒng)老數(shù)據(jù)的id, 查詢在MongoDB中是否存在，如果不存在則進(jìn)行補(bǔ)償重發(fā)；

•  數(shù)據(jù)完整性：對于S3和MongoDB中的數(shù)據(jù)按照相同規(guī)則進(jìn)行md5校驗(yàn)，校驗(yàn)不通過則進(jìn)行補(bǔ)償重發(fā)。

第五步：數(shù)據(jù)雙寫

將應(yīng)用層預(yù)制的寫開關(guān)打開，將流量導(dǎo)入到LogStore中，此時(shí)MySQL的流量并沒有停掉，繼續(xù)執(zhí)行binlog同步。結(jié)構(gòu)如下：

從圖中可以看到，從S3調(diào)用點(diǎn)的寫接口的流量都寫入到MongoDB數(shù)據(jù)庫backuplogs集合中，為什么不直接寫入到logs表中呢？留個(gè)小懸念，在后文中有解釋。

第六步：灰度切換S3讀到LogStore系統(tǒng)

上文我們提到，對于S3系統(tǒng)應(yīng)用層讀寫調(diào)用點(diǎn)均分別內(nèi)置了切換開關(guān)，打開應(yīng)用層讀開關(guān)，所有的讀操作全部走LogStore, 切換后示意圖如下所示：

第七步：灰度切換寫接口到LogStore系統(tǒng)

打開應(yīng)用層寫開關(guān)，所有寫操作會(huì)通過mq異步寫到MongoDB中，那如何證明應(yīng)用層寫調(diào)用點(diǎn)修改完全了呢？

上文中雙寫數(shù)據(jù)一份到logs表中，一份到backuplogs表中，通過Maxwell的Binlog同步的數(shù)據(jù)肯定是最全的，數(shù)據(jù)量上按理來說 count( logs) >= count(backuplogs), 如果兩個(gè)集合一段時(shí)間內(nèi)的數(shù)據(jù)增量相同，則證明寫調(diào)用點(diǎn)修改完全，可以去掉雙寫，只保留LogStore這條線，反之需要檢查修改再次驗(yàn)證。切換寫完成后，示意圖如下：

六、MongoDB與故障演練

故障演練能夠檢測服務(wù)是否真正高可用，及時(shí)發(fā)現(xiàn)系統(tǒng)薄弱的環(huán)節(jié)，提前準(zhǔn)備好預(yù)案減少故障恢復(fù)時(shí)間。為了驗(yàn)證MongoDB是否真正高可用，我們在線下搭建了MongoDB集群：

同時(shí)，我們編寫腳本模擬用戶MongoDB數(shù)據(jù)插入和讀取，基于好大夫在線自研故障演練平臺(tái)，對機(jī)器進(jìn)行故障注入，查看各種故障對用戶的影響。故障演練內(nèi)容CPU、內(nèi)存、磁盤、網(wǎng)絡(luò)和進(jìn)程Kill等操作，詳情如下圖所示：

實(shí)驗(yàn)結(jié)果：

•  CPU、磁盤填充和磁盤負(fù)載對MongoDB集群影響較小；

•  內(nèi)存滿載可能會(huì)發(fā)生系統(tǒng)OOM，導(dǎo)致MongoDB進(jìn)程被操作系統(tǒng)Kill，由于MongoDB存在數(shù)據(jù)副本和自動(dòng)主從切換，對用戶影響較?。?/p>

•  網(wǎng)絡(luò)抖動(dòng)、延遲和丟包會(huì)導(dǎo)致mongos連接服務(wù)器時(shí)間變長，客戶端卡頓的現(xiàn)象發(fā)生，可通過網(wǎng)絡(luò)監(jiān)控的手段監(jiān)測；

•  分別主動(dòng)Kill掉MongoDB的主節(jié)點(diǎn)、從節(jié)點(diǎn)、仲裁節(jié)點(diǎn)、mongos、config節(jié)點(diǎn)，對整個(gè)集群影響較小。

整體而言，MongoDB存在副本和自動(dòng)主從切換，客戶端存在自動(dòng)檢測重連機(jī)制，單個(gè)機(jī)器發(fā)生故障時(shí)對整體集群可用性影響較小。同時(shí)，可增加對單機(jī)器的資源進(jìn)行監(jiān)控，達(dá)到閾值進(jìn)行報(bào)警，減小故障發(fā)現(xiàn)和恢復(fù)時(shí)間。

1、MongoDB的使用

•  MongoDB數(shù)據(jù)寫入可能各個(gè)分片不均勻，此時(shí)可以開啟塊均衡策略；由于均衡器會(huì)增加系統(tǒng)負(fù)載，最好選擇在業(yè)務(wù)量較小的時(shí)候進(jìn)行；

•  合理選擇分片鍵和建立索引，會(huì)使你的查詢速度更快，這個(gè)要具體場景具體分析。

2、遷移數(shù)據(jù)

•  必須保留唯一標(biāo)識(shí)數(shù)據(jù)的字段，最好是主鍵id，方便校驗(yàn)數(shù)據(jù)；

•  一定要考慮多進(jìn)程，腳本要自動(dòng)化，縮短遷移時(shí)間和減小人工介入；

•  遷移過程中，要時(shí)刻關(guān)注數(shù)據(jù)庫、中間件及應(yīng)用相關(guān)指標(biāo)，防止導(dǎo)出導(dǎo)入數(shù)據(jù)影響正常業(yè)務(wù)；

•  要在同樣配置的環(huán)境下充分演練，提前制定數(shù)據(jù)比對測試用例，以防止數(shù)據(jù)丟失；

•  每一步線上操作（如切換讀寫），都要有對應(yīng)的回滾計(jì)劃，最大限度降低對業(yè)務(wù)的影響。 

關(guān)于數(shù)億MySQL數(shù)據(jù)七步走到MongoDB的操作過程就分享到這里了，希望以上內(nèi)容可以對大家有一定的幫助，可以學(xué)到更多知識(shí)。如果覺得文章不錯(cuò)，可以把它分享出去讓更多的人看到。