[[321912]]

本文轉(zhuǎn)載自微信公眾號「DBAplus社群」

作者介紹

李猛(ynuosoft)，Elastic-stack產(chǎn)品深度用戶，ES認證工程師，2012年接觸Elasticsearch，對Elastic-Stack開發(fā)、架構(gòu)、運維等方面有深入體驗，實踐過多種Elasticsearch項目，最暴力的大數(shù)據(jù)分析應(yīng)用，最復雜的業(yè)務(wù)系統(tǒng)應(yīng)用;業(yè)余為企業(yè)提供Elastic-stack咨詢培訓以及調(diào)優(yōu)實施。

序言

圖示：MongoDB與Elasticsearch熱度排名

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

為什么要從MongoDB遷移到Elasticsearch?

如何從MongoDB遷移到Elasticsearch?

現(xiàn)狀背景

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

1、項目背景

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

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

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

{ 
  "dataId": 1,  
  "traceId": "abc",         
  "moduleCode": "crm_01",            
  "operateTime": "2019-11-11 12:12:12",  
  "operationId": 100, 
  "operationName": "張三", 
  "departmentId": 1000, 
  "departmentName": "客戶部", 
  "operationContent": "拜訪客戶。。。" 
} 

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

[ 
  { 
    "dataId": 1, 
    "traceId": "abc", 
    "moduleCode": "crm_01", 
    "operateTime": "2019-11-11 12:12:12", 
    "operationId": 100, 
    "operationName": "張三", 
    "departmentId": 1000, 
    "departmentName": "客戶部", 
    "operationContent": "拜訪客戶", 
     
    "beforeValue": "20", 
    "afterValue": "30", 
    "columnName": "customerType" 
  }, 
  { 
    "dataId": 1, 
    "traceId": "abc", 
    "moduleCode": "crm_01", 
    "operateTime": "2019-11-11 12:12:12", 
    "operationId": 100, 
    "operationName": "張三", 
    "departmentId": 1000, 
    "departmentName": "客戶部", 
    "operationContent": "拜訪客戶", 
     
    "beforeValue": "2019-11-02", 
    "afterValue": "2019-11-10", 
    "columnName": "lastVisitDate" 
  } 
] 

2、項目架構(gòu)

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

• 業(yè)務(wù)系統(tǒng)新增或者編輯數(shù)據(jù)，產(chǎn)生操作日志記錄發(fā)送到Kafka集群，基于dataid字段作為key;
• 新增或編輯數(shù)據(jù)實際存儲到MySQL數(shù)據(jù)庫;
• canal集群訂閱MySQL集群，按照業(yè)務(wù)系統(tǒng)模塊配置監(jiān)控的數(shù)據(jù)庫與表;
• canal將監(jiān)控到的變更業(yè)務(wù)數(shù)據(jù)發(fā)送到Kafka集群，基于dataid字段作為key;
• 操作日志系統(tǒng)從Kafka獲取主記錄數(shù)據(jù)與從記錄數(shù)據(jù);
• 操作日志系統(tǒng)寫入數(shù)據(jù)到MongoDB，同時需要反查詢。

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

3、MongoDB架構(gòu)

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

• 服務(wù)器配置8c/32gb/500gb ssd;
• Router路由服務(wù)器部署了3個節(jié)點;
• Config配置服務(wù)器部署了3個節(jié)點;
• Shard分片服務(wù)器部署了9個節(jié)點;
• 主操作記錄設(shè)計3個分片;
• 從操作記錄設(shè)計3個分片。

問題說明

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

1、搜索查詢

• MongoDB內(nèi)部采用B-Tree作為索引結(jié)構(gòu)，此索引基于最左優(yōu)先原則，且必須保證查詢順序與索引字段的順序一致才有效，這個即是優(yōu)點，但在現(xiàn)在復雜業(yè)務(wù)場景也是致命的;
• 業(yè)務(wù)系統(tǒng)查詢操作日志記錄會有很多過濾條件，且查詢條件是任意組合的，現(xiàn)有MongoDB是不支持的，或者說所有關(guān)系型數(shù)據(jù)庫都不支持，如果要支持，得創(chuàng)建好多組合的B+數(shù)索引，想法很不理智，這個我們已經(jīng)在《DB與ES混合之應(yīng)用系統(tǒng)場景分析探討》文中探討過，詳細可以閱讀;
• 同時主記錄與從記錄中有很多字符類的數(shù)據(jù)，這些數(shù)據(jù)查詢即要支持精確查詢，也要支持全文檢索，這幾個方面MongoDB功能很單一，性能也很糟糕，業(yè)務(wù)系統(tǒng)查詢時經(jīng)常超時，反倒是Elasticsearch非常合適。

2、技術(shù)棧成熟度

• 分片與副本實現(xiàn)問題，MongoDB集合數(shù)據(jù)在設(shè)計時是需要綁定到具體的機器實例的，哪些分片分布在哪些節(jié)點上，哪些副本分布在哪些節(jié)點上，這些都需要在配置集群時就要綁定死，跟傳統(tǒng)的關(guān)系型數(shù)據(jù)庫做分庫分表本質(zhì)上沒有什么兩樣，其實現(xiàn)在很多數(shù)據(jù)產(chǎn)品的集群還是這種模式偏多，比如Redis-cluster，ClickHouse等。而Elasticsearc的集群與分片和副本沒有直接的綁定關(guān)系，可以任意的平衡調(diào)整，且節(jié)點的性能配置也可以很容易差異化;
• 操作日志數(shù)據(jù)量增加很快，單日寫入超過千萬條，不用多久，運維人員就需要對服務(wù)器進行擴容，且相對Elasticsearch復雜很多;
• MongoDB單集合數(shù)據(jù)量超過10億條，此情況下即使簡單條件查詢性能也不理想，不如Elasticsearch倒排索引快;
• 公司對于ES與MongoDB技術(shù)棧的經(jīng)驗積累不同，Elasticsearc在很多項目中運用，非常核心的項目也是大量運用，對于其技術(shù)與運維經(jīng)驗更豐富，而MongoDB如果除去核心業(yè)務(wù)場景，幾乎找不到合適的切入口，實際沒有人敢在核心項目中使用MongoDB，這就很尷尬。

3、文檔格式相同

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

遷移方案

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

• 上層應(yīng)用系統(tǒng)遷移，原來是針對MongoDB的語法規(guī)則，現(xiàn)在要修改為面向Elasticsearch語法規(guī)則;
• 下層MongoDB數(shù)據(jù)遷移到Elasticsearch。

1、Elastic容量評估

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

2、Elastic索引規(guī)則

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

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

3、核心實現(xiàn)邏輯設(shè)計

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

• 主數(shù)據(jù)先到操作日志系統(tǒng)，從數(shù)據(jù)后到，從數(shù)據(jù)寫的時候先拼湊主數(shù)據(jù)記錄和Binlog字段數(shù)據(jù);
• 從數(shù)據(jù)先到操作日志系統(tǒng)，主數(shù)據(jù)后到，主數(shù)據(jù)更新從索引的相關(guān)的索引字段。

Elasticsearch索引數(shù)據(jù)更新是近實時的刷新機制，數(shù)據(jù)提交后不能馬上通過Search-Api查詢到，主記錄的數(shù)據(jù)如何更新到從記錄呢?而且業(yè)務(wù)部門不規(guī)范的使用，多條主記錄的dataId和tracId可能一樣。

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

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

{ 
  "dataId": 1, 
  "traceId": "abc", 
  "moduleCode": "crm_01", 
  "operationId": 100, 
  "operationName": "張三", 
  "departmentId": 1000, 
  "departmentName": "客戶部", 
  "operationContent": "拜訪客戶", 
  "detailId": [ 
    1, 
    2, 
    3, 
    4, 
    5, 
    6 
  ] 
} 

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

#批量獲取從索引的記錄 
_mget  
#批量插入 
bulk 
#批量刪除中間臨時索引 
_delete_by_query  

遷移過程

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

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

• 歷史型數(shù)據(jù)。操作日志記錄數(shù)據(jù)屬于歷史性的數(shù)據(jù)，記錄產(chǎn)生之后幾乎無需二次修改，等同于離線數(shù)據(jù);
• 非持續(xù)性遷移。項目全部完工之后，原有的MongoDB集群會全部銷毀，不會有二次遷移需求;
• 數(shù)據(jù)量問題。原有MongoDB操作日志數(shù)據(jù)量有幾十億條，遷移過程不能太快也不能太慢，速度太快，MongoDB集群會出現(xiàn)性能問題，速度太慢，項目周期太長，增加運維的成本與復雜度。否則可以選擇Hadoop作為中轉(zhuǎn)平臺的遷移;
• DataX源碼特定場景改造。如日期類型的轉(zhuǎn)換、索引主鍵_id的生成、索引主鍵_id映射，支持重復同步;
• 多實例多線程并行。主數(shù)據(jù)同步部署多個實例，從數(shù)據(jù)同步也部署多個實例，單實例中配置多個Channel。

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

2、遷移索引設(shè)置

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

"index.number_of_replicas": 0, 
 "index.refresh_interval": "30s", 
 "index.translog.flush_threshold_size": "1024M" 
 "index.translog.durability": "async", 
 "index.translog.sync_interval": "5s" 

3、應(yīng)用遷移

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

#應(yīng)用寫入mongodb標識 
writeflag.mongodb: true 
#應(yīng)用寫入elasticsearch標識 
writeflag.elasticsearch: true 

項目改造說明：

• 第一次上線的時候，先將2個寫入標識設(shè)置為true，雙寫MongoDB和ES;
• 對于讀，提供2個不同接口，前端自由的切換;
• 等數(shù)據(jù)遷移完，沒有差異的時候，重新更改flag的值。

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

結(jié)語

1、遷移效果

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

2、經(jīng)驗總結(jié)

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

從過去40年至今，數(shù)據(jù)庫的形態(tài)基本經(jīng)歷了傳統(tǒng)商業(yè)數(shù)據(jù)庫、開源數(shù)據(jù)庫到云原生數(shù)據(jù)庫的演進過程。云時代下數(shù)據(jù)庫將如何革新與創(chuàng)變?金融行業(yè)核心數(shù)據(jù)庫遷移與建設(shè)如何安全平穩(wěn)展開?來Gdevops全球敏捷運維峰會北京站尋找答案：

• 《All in Cloud 時代，下一代云原生數(shù)據(jù)庫技術(shù)與趨勢》阿里巴巴集團副總裁/達摩院首席數(shù)據(jù)庫科學家 李飛飛(飛刀)
• 《AI和云原生時代的數(shù)據(jù)庫進化之路》騰訊數(shù)據(jù)庫產(chǎn)品中心總經(jīng)理 林曉斌(丁奇)
• 《ICBC的MySQL探索之路》工商銀行軟件開發(fā)中心 魏亞東
• 《金融行業(yè)MySQL高可用實踐》愛可生技術(shù)總監(jiān) 明溪源
• 《民生銀行在SQL審核方面的探索和實踐》民生銀行 資深數(shù)據(jù)庫專家 李寧寧
• 《OceanBase分布式數(shù)據(jù)庫在西安銀行的落地和實踐》螞蟻金服P9資深專家/OceanBase核心負責人 蔣志勇

作者介紹

李猛(ynuosoft)，Elastic-stack產(chǎn)品深度用戶，ES認證工程師，2012年接觸Elasticsearch，對Elastic-Stack開發(fā)、架構(gòu)、運維等方面有深入體驗，實踐過多種Elasticsearch項目，最暴力的大數(shù)據(jù)分析應(yīng)用，最復雜的業(yè)務(wù)系統(tǒng)應(yīng)用;業(yè)余為企業(yè)提供Elastic-stack咨詢培訓以及調(diào)優(yōu)實施。