Categories
程式開發

從MongoDB遷移到ES後,我們減少了80%的服務器


本文由 dbaplus 社群授權轉載。

序言

從MongoDB遷移到ES後,我們減少了80%的服務器 1

圖示:MongoDB與Elasticsearch熱度排名

本文內容涉及到MongoDB與Elasticsearch兩大陣營,可能會引起口水之爭,僅代表個人經驗之談,非陣營之說,圍繞兩個話題展開:

  • 為什麼要從MongoDB遷移到Elasticsearch?
  • 如何從MongoDB遷移到Elasticsearch?

現狀背景

MongoDB本身定位與關係型數據庫競爭,但工作中幾乎沒有見到哪個項目會將核心業務系統的數據放在上面,依然選擇傳統的關係型數據庫。

1、項目背景項目背景

公司所在物流速運行業,業務系統複雜且龐大,用戶操作者很多,每日有大量業務數據產生,同時業務數據會有很多次流轉狀態變化,為了便於記錄追踪分析,系統操作日誌記錄項目應運而生,考慮到原有的日均數據量,操作日誌數據基於MongoDB存儲。

操作日誌記錄系統需要記錄兩種數據,如下說明:

1)變更主數據,什麼人在什麼時間在系統哪個模塊做了什麼操作,數據編號是什麼,操作跟踪編號是什麼。

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

2)變更從數據,實際變更數據的變化前後,此類數據條數很多,一行數據多個字段變更就記錄多條。

[
  {
    "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、項目架構項目背景

項目架構描述如下:

  • 業務系統新增或者編輯數據,產生操作日誌記錄發送到Kafka集群,基於dataid字段作為key;
  • 新增或編輯數據實際存儲到MySQL數據庫;
  • canal集群訂閱MySQL集群,按照業務系統模塊配置監控的數據庫與表;
  • canal將監控到的變更業務數據發送到Kafka集群,基於dataid字段作為key;
  • 操作日誌系統從Kafka獲取主記錄數據與從記錄數據;
  • 操作日誌系統寫入數據到MongoDB,同時需要反查詢。

從MongoDB遷移到ES後,我們減少了80%的服務器 2

圖示:操作日誌記錄業務流程說明

3、MongoDB架構項目背景

集群架構說明:

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

從MongoDB遷移到ES後,我們減少了80%的服務器 3

問題說明

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

1、搜索查詢項目背景

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

2、技術棧成熟度項目背景

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

3、文檔格式相同項目背景

MongoDB與Elasticsearch都屬於文檔型數據庫 ,Bson類同與Json,_objectid與_id原理一樣,所以主數據與從數據遷移到Elasticsearch平台,數據模型幾乎無需變化。

遷移方案

異構數據系統遷移,主要圍繞這兩大塊內容展開:

  • 上層應用系統遷移,原來是針對MongoDB的語法規則,現在要修改為面向Elasticsearch語法規則;
  • 下層MongoDB數據遷移到Elasticsearch。

1、Elastic容量評估項目背景

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

2、Elastic索引規則項目背景

系統操作日誌是時序性數據,寫完整後基本上無需再次修改。操作日誌記錄查詢主要是當月的居多,後續的歷史性數據查詢頻率很低,根據評估,核心數據索引按月創建生成, 業務查詢時候必須帶上操作時間範圍,後端根據時間反推需要查詢哪些索引,Elastic-Api支持多索引匹配查詢,完美利用Elastic的特性解決跨多個月份的查詢合併。對於非核心數據索引,按年創建索引生成足以。

從MongoDB遷移到ES後,我們減少了80%的服務器 4

圖示:Elastic操作日誌索引創建規則

3、核心實現邏輯設計項目背景

Elasticsearch不是關係型數據庫,不具備事務的機制。操作日誌系統的數據來源都是Kafka,消費數據是有順序機制的,有2種場景特別注意,如下:

  • 主數據先到操作日誌系統,從數據後到,從數據寫的時候先拼湊主數據記錄和Binlog字段數據;
  • 從數據先到操作日誌系統,主數據後到,主數據更新從索引的相關的索引字段。

Elasticsearch索引數據更新是近實時的刷新機制,數據提交後不能馬上通過Search-Api查詢到,主記錄的數據如何更新到從記錄呢?而且業務部門不規範的使用,多條主記錄的dataId和tracId可能一樣。

由於主數據與從數據關聯字段是dataId和traceId。如果主數據與從數據在同時達到操作日誌系統,基於update_by_query 命令肯定失效不 準確, 主從數據也可能是多對多的關聯關係,dataId 和traceId不能唯一決定一條記錄。

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

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

前面我們講過主記錄和從記錄都是一個Kafka的分區上,我們拉一批數據的時候,操作ES用的用到的核心API:

#批量获取从索引的记录
_mget
#批量插入
bulk
#批量删除中间临时索引
_delete_by_query

遷移過程

1、數據遷移項目背景

選擇DataX作為數據同步工具由以下幾個因素:

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

從MongoDB遷移到ES後,我們減少了80%的服務器 5

圖示:DataX同步數據示意圖

2、遷移索引設置項目背景

臨時修改索引的一些設置,當數據同步完之後再修改回來,如下:

  "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、應用遷移項目背景

操作日誌項目採用Springboot構建,增加了自定義配置項,如下:

#应用写入mongodb标识
writeflag.mongodb: true
#应用写入elasticsearch标识
writeflag.elasticsearch: true

項目改造說明:

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

從MongoDB遷移到ES後,我們減少了80%的服務器 6

圖示:應用平衡遷移

結語

1、遷移效果項目背景

棄用MongoDB使用ElasticSearch作為存儲數據庫,服務器從原來的15台MongoDB,變成了3台ElasticSearch,每月為公司節約了一大筆費用。同時查詢性能提高了10倍以上,而且更好的支持了各種查詢,得到了業務部門的使用者,運維團隊和領導的一致讚賞。

2、經驗總結項目背景

整個項目前後歷經幾個月,多位同事參與,設計、研發,數據遷移、測試、數據驗證、壓測等各個環節。技術方案不是一步到位,中間也踩了很多坑,最終上線了。 ES的技術優秀特點很多,靈活的使用,才能發揮最大的威力。

作者介紹

李猛(ynuosoft),Elastic-stack產品深度用戶,ES認證工程師,2012年接觸Elasticsearch,對Elastic-Stack開發、架構、運維等方面有深入體驗,實踐過多種Elasticsearch項目,最暴力的大數據分析應用,最複雜的業務系統應用;業餘為企業提供Elastic-stack諮詢培訓以及調優實施。

原文鏈接

https://mp.weixin.qq.com/s?__biz=MzI4NTA1MDEwNg==&mid=2650787182&idx=1&sn=d3543f9a62ec56c58fe72a0d63e35999&chksm=f3f978fbc48ef1ed23736de22fd812ca195acdb16c3869ddab8b2c29aa3ca50f0f35042f5d71&scene=27#wechat_redirect