來(lái)自：DBAplus社群

作者介紹

圖示：MongoDB與Elasticsearch熱度排名

本文內(nèi)容涉及到MongoDB與Elasticsearch兩大陣營(yíng)，可能會(huì)引起口水之爭(zhēng)，僅代表個(gè)人經(jīng)驗(yàn)之談，非陣營(yíng)之說(shuō)，圍繞兩個(gè)話題展開(kāi)：

MongoDB本身定位與關(guān)系型數(shù)據(jù)庫(kù)競(jìng)爭(zhēng)，但工作中幾乎沒(méi)有見(jiàn)到哪個(gè)項(xiàng)目會(huì)將核心業(yè)務(wù)系統(tǒng)的數(shù)據(jù)放在上面，依然選擇傳統(tǒng)的關(guān)系型數(shù)據(jù)庫(kù)。

公司所在物流速運(yùn)行業(yè)，業(yè)務(wù)系統(tǒng)復(fù)雜且龐大，用戶操作者很多，每日有大量業(yè)務(wù)數(shù)據(jù)產(chǎn)生，同時(shí)業(yè)務(wù)數(shù)據(jù)會(huì)有很多次流轉(zhuǎn)狀態(tài)變化，為了便于記錄追蹤分析，系統(tǒng)操作日志記錄項(xiàng)目應(yīng)運(yùn)而生，考慮到原有的日均數(shù)據(jù)量，操作日志數(shù)據(jù)基于MongoDB存儲(chǔ)。

操作日志記錄系統(tǒng)需要記錄兩種數(shù)據(jù)，如下說(shuō)明：

1）變更主數(shù)據(jù)，什么人在什么時(shí)間在系統(tǒng)哪個(gè)模塊做了什么操作，數(shù)據(jù)編號(hào)是什么，操作跟蹤編號(hào)是什么。

2）變更從數(shù)據(jù)，實(shí)際變更數(shù)據(jù)的變化前后，此類(lèi)數(shù)據(jù)條數(shù)很多，一行數(shù)據(jù)多個(gè)字段變更就記錄多條。

項(xiàng)目架構(gòu)描述如下：

圖示：操作日志記錄業(yè)務(wù)流程說(shuō)明

集群架構(gòu)說(shuō)明：

MongoDB的信徒們可能懷疑我們沒(méi)有使用好，或者我們的運(yùn)維能力欠缺，或者認(rèn)為我們有Elasticsearch的高手在。不是這樣的，棄用MongoDB選擇Elasticsearch其實(shí)并非技術(shù)偏見(jiàn)問(wèn)題，而是我們的實(shí)際場(chǎng)景需求，原因如下：

MongoDB與Elasticsearch都屬于文檔型數(shù)據(jù)庫(kù) ，Bson類(lèi)同與Json，_objectid與_id原理一樣，所以主數(shù)據(jù)與從數(shù)據(jù)遷移到Elasticsearch平臺(tái)，數(shù)據(jù)模型幾乎無(wú)需變化。

異構(gòu)數(shù)據(jù)系統(tǒng)遷移，主要圍繞這兩大塊內(nèi)容展開(kāi)：

原有MongoDB集群采用了15臺(tái)服務(wù)器，其中9臺(tái)是數(shù)據(jù)服務(wù)器，遷移到Elastic集群需要多少臺(tái)服務(wù)器？我們采取簡(jiǎn)單推算辦法，如假設(shè)生產(chǎn)環(huán)境上某個(gè)MongoDB集合的數(shù)據(jù)有10億條數(shù)據(jù), 我們先在測(cè)試環(huán)境上從MongoDB到ES上同步100萬(wàn)條數(shù)據(jù)，假設(shè)這100萬(wàn)條數(shù)據(jù)占用磁盤(pán)10G，那生產(chǎn)上環(huán)境上需要1個(gè)T磁盤(pán)空間，然后根據(jù)業(yè)務(wù)預(yù)期增加量擴(kuò)展一定冗余。根據(jù)初步評(píng)估，Elastic集群設(shè)置3臺(tái)服務(wù)器， 配置8c/16g內(nèi)存/2T機(jī)械磁盤(pán)。服務(wù)器數(shù)量一下從15臺(tái)縮減到3臺(tái)，且配置也降低不少。

系統(tǒng)操作日志是時(shí)序性數(shù)據(jù)，寫(xiě)完整后基本上無(wú)需再次修改。操作日志記錄查詢主要是當(dāng)月的居多，后續(xù)的歷史性數(shù)據(jù)查詢頻率很低，根據(jù)評(píng)估，核心數(shù)據(jù)索引按月創(chuàng)建生成， 業(yè)務(wù)查詢時(shí)候必須帶上操作時(shí)間范圍，后端根據(jù)時(shí)間反推需要查詢哪些索引，Elastic-Api支持多索引匹配查詢，完美利用Elastic的特性解決跨多個(gè)月份的查詢合并。對(duì)于非核心數(shù)據(jù)索引，按年創(chuàng)建索引生成足以。

圖示：Elastic操作日志索引創(chuàng)建規(guī)則

Elasticsearch不是關(guān)系型數(shù)據(jù)庫(kù)，不具備事務(wù)的機(jī)制。操作日志系統(tǒng)的數(shù)據(jù)來(lái)源都是Kafka，消費(fèi)數(shù)據(jù)是有順序機(jī)制的，有2種場(chǎng)景特別注意，如下：

由于主數(shù)據(jù)與從數(shù)據(jù)關(guān)聯(lián)字段是dataId和traceId。如果主數(shù)據(jù)與從數(shù)據(jù)在同時(shí)達(dá)到操作日志系統(tǒng)，基于update_by_query 命令肯定失效不 準(zhǔn)確， 主從數(shù)據(jù)也可能是多對(duì)多的關(guān)聯(lián)關(guān)系，dataId 和traceId不能唯一決定一條記錄。

Elasticsearch其實(shí)也是一個(gè)NoSQL數(shù)據(jù)庫(kù)， 可以做key-value緩存。這時(shí)新建一個(gè)Elastic索引作為中間緩存， 原則是主數(shù)據(jù)與從數(shù)據(jù)誰(shuí)先到緩存誰(shuí)，索引的 _id=（dataId+traceId） ， 通過(guò)這個(gè)中間索引可以找到主數(shù)據(jù)記錄的Id或者從記錄Id， 索引數(shù)據(jù)模型多如下，detailId為從索引的_id的數(shù)組記錄。

前面我們講過(guò)主記錄和從記錄都是一個(gè)Kafka的分區(qū)上，我們拉一批數(shù)據(jù)的時(shí)候，操作ES用的用到的核心API：

選擇DataX作為數(shù)據(jù)同步工具由以下幾個(gè)因素：

圖示：DataX同步數(shù)據(jù)示意圖

臨時(shí)修改索引的一些設(shè)置，當(dāng)數(shù)據(jù)同步完之后再修改回來(lái)，如下：

操作日志項(xiàng)目采用Springboot構(gòu)建，增加了自定義配置項(xiàng)，如下：

項(xiàng)目改造說(shuō)明：

圖示：應(yīng)用平衡遷移

棄用MongoDB使用ElasticSearch作為存儲(chǔ)數(shù)據(jù)庫(kù)，服務(wù)器從原來(lái)的15臺(tái)MongoDB，變成了3臺(tái)ElasticSearch，每月為公司節(jié)約了一大筆費(fèi)用。同時(shí)查詢性能提高了10倍以上，而且更好的支持了各種查詢，得到了業(yè)務(wù)部門(mén)的使用者，運(yùn)維團(tuán)隊(duì)和領(lǐng)導(dǎo)的一致贊賞。

整個(gè)項(xiàng)目前后歷經(jīng)幾個(gè)月，多位同事參與，設(shè)計(jì)、研發(fā)，數(shù)據(jù)遷移、測(cè)試、數(shù)據(jù)驗(yàn)證、壓測(cè)等各個(gè)環(huán)節(jié)。技術(shù)方案不是一步到位，中間也踩了很多坑，最終上線了。ES的技術(shù)優(yōu)秀特點(diǎn)很多，靈活的使用，才能發(fā)揮最大的威力。

特別推薦一個(gè)分享架構(gòu)+算法的優(yōu)質(zhì)內(nèi)容，還沒(méi)關(guān)注的小伙伴，可以長(zhǎng)按關(guān)注一下：
長(zhǎng)按訂閱更多精彩▼
如有收獲，點(diǎn)個(gè)在看，誠(chéng)摯感謝