作者：胡刀 阿里雲運維專家

        舟濟 阿里雲解決方案架構師

實時歷史庫需求背景

在當今 的數字化時代，隨著業務的迅速發展，每天產生的資料量會是一個驚人的數量，資料庫儲存的成本將會越來越大，通常的做法是對歷史資料做歸檔，即將長期不使用的資料遷移至以檔案形式儲存的廉價儲存裝置上，比如阿里雲OSS或者阿里雲資料庫DBS服務 。

然而在部分核心業務的應用場景下，針對幾個月甚至幾年前的“舊”資料依舊存在實時的，低頻的查詢甚至更新需求，比如淘寶/天貓的歷史訂單查詢，企業級辦公軟體釘釘幾年前的聊天資訊查詢，菜鳥海量物流的歷史物流 訂單詳情等。

如果這時從歷史備份中還原後查詢，那麼查詢時間將會是以天為單位，可接受度為0

如果將這些低頻但實時的查詢需求的歷史資料與近期活躍儲存在同一套分散式資料庫叢集下，那麼又會帶來以下兩大挑戰

• 儲存成本巨大 ，進而導致成本遠大於收益，比如釘釘聊天資訊資料量在高度壓縮後接近50PB，很難想象這些資料不做壓縮會帶來多大的資金開銷
• 效能挑戰巨大 ，隨著資料量越來越大，即使針對資料做了分散式儲存，單例項容量超過大概5T以後效能也會急劇下滑，進而影響到近期活躍資料的查詢效能，拖垮整個叢集

• 運維難度巨大 ，比如針對海量資料下發一個表資料結構變更操作，很難想象全部完成需要多長時間

1

實時歷史庫場景需求分析

透過上面的分析，不管是冷備份還是線上歷史資料混合儲存在同一張物理表上的方法都是不可取的，一般實時查詢歷史資料庫的場景，一般需要有以下幾個關鍵特性

• 成本可控 ，歷史資料的儲存成本無法接受和線上庫一樣線性增長

• 實時查詢 ，歷史資料的查詢RT要做到與線上活躍庫幾乎一致

• 查詢頻次較低 ，一般來說，越“舊”的資料查詢頻率越低

• 統一查詢入口 ，不管是活躍資料還是歷史資料，查詢入口保持一致

• 改造成本需要儘可能低 ，最好能做到不做任何應用程式碼修改，可以認為歷史庫對程式開發人員來說是完全透明的

• 可能存在歷史資料更新需求

• 資料規模較大 ，一般在100TB以上

2

X-Engine引擎介紹

01

X-Engine簡介

X-Engine是阿里雲資料庫產品事業部 自研 的聯機事務處理OLTP（On-Line Transaction Processing）資料庫儲存引擎。作為自研資料庫PolarDB 的儲存引擎之一，已經廣泛應用在阿里集團內部諸多業務系統中，包括交易歷史庫、釘釘歷史庫等核心應用，大幅縮減了業務成本，同時也作為雙十一大促的關鍵資料庫技術，挺過了數百倍平時流量的衝擊。

與傳統的InnoDB引擎不同，X-Engine使用分層儲存架構（LSM-Tree）。分層儲存有兩個比較顯著的優點：

• 需要索引的熱點資料集更小，寫入效能更高 。

• 底層持久化的資料頁是隻讀的，資料頁採用緊湊儲存格式，同時預設進行壓縮，儲存成本更低。

相比InnoDB引擎，依據資料特徵，使用X-Engine儲存空間可降低至 10%~50% ，我們在著名的Link-Bench和阿里巴巴內部交易業務兩個資料集上測試了X-Engine的儲存空間效率。在測試中，對比開壓縮的InnoDB引擎，X-Engine有著 2倍 空間優勢，而對比未開壓縮的InnoDB，X-Engine則有著 3~5倍 的優勢。

02

實時歷史庫方案，為何選擇 X-Engine

1.通常我們預設MySQL是當今最流行的開源資料庫，大機率是線上核心資料庫叢集的首選。相比其他高壓縮的儲存引擎，引入X-Engine完全無需做任何SQL程式碼改造，並且支援事務，接入成本最低，學習成本幾乎為0

2.寫入效能更強，X-Engine相比同為LSM-tree架構的Rocksdb，有超過10倍的效能提升。

3.在儲存層引入資料複用技術等，最佳化Compaction的效能，降低傳統LSM-tree架構中Compaction動作對系統資源的衝擊，保持系統效能平穩

4.引入多個層級Cache，同時結合Cach回填和預取機制，利用精細化訪問機制和快取技術，彌補傳統LSM-tree引擎的讀效能短板，X-Engine的點查詢能力幾乎與Innodb持平

下圖是X-Engine與主流歷史資料儲存方案對比

3

實時歷史資料庫架構設計和實現

01

總體 架構思路

基於上文對實時歷史庫和X-Engine的介紹，阿里雲資料庫團隊推出以X-Engine引擎為歷史資料儲存核心，同時生態工具DTS作為線上/歷史資料流轉通道，DMS作為歷史資料無風險刪除的完整“實時線上-歷史庫”方案，針對不同的業務場景和客戶需求，在具體實現上可能會有所不同，我們提供了多種實時歷史庫方案的具體實現。主體架構圖如下，核心思路為：

• 久經考驗的Innodb引擎作為OLTP線上庫核心引擎，主要處理高頻查詢/更新請求，滿足線上活躍資料高併發，高效能，強範圍查詢的業務需求

• 阿里巴巴資料庫團隊自研的高壓測儲存引擎X-Engine作為歷史庫核心引擎，主要響應歷史資料入庫/查詢/更新請求，滿足歷史資料冷熱資料頻次不一，低儲存成本，高效能的業務需求(範圍查詢可能效能受限)

• 統一DB接入層，根據設定的業務時間屬性將請求分別轉發至不同的儲存引擎。針對特殊場景下的跨引擎訪問，在應用層做聚合展示

• 線上-歷史資料透過阿里雲提供的生態體系工具做歷史資料遷移和過期資料刪除，確保鏈路更為穩定可靠

02

線上庫/歷史庫拆分方案

一般來說，需要使用到實時歷史庫的場景，資料量都足夠大到單臺宿主機存放不了。線上資料庫可能是根據業務水平或垂直拆分的多個RDS，也可能是一個規模較大的DRDS叢集。為了儘可能地保證線上庫的效能，推薦將線上庫/歷史庫完全拆分解耦

•  歷史庫叢集儲存全量資料

•  透過DTS鏈路打通線上庫和歷史庫，實時同步

•  DTS鏈路過濾Delete操作

•  可直接使用新版DMS配置歷史資料定期刪除

源端為DRDS叢集

a.資料同步鏈路走RDS

• 多條DTS鏈路打通底層RDS節點，同步效能強
• RDS數量較多可支援API批次建立和配置
• 鏈路穩定性更好
• 需要保證源端目標端庫表數量一致，資料路由規則一致

b.資料同步鏈路走DRDS

• 只需要配置一條DTS鏈路，方便省錢
• 資料同步效能較差
• 源端DRDS擴容會影響到DTS同步鏈路
• 源端目標端的例項數量和資料路由規則可自由配置

源端為多個RDS

a.目標端為多個RDS

• 業務程式碼無需任何改造
• 執行後期歷史庫節點磁碟容量存在風險

b.目標端為DRDS叢集

• 可能涉及到業務程式碼輕量改造，目標端不走分庫分表鍵效能無法保證

• 可將多個線上庫業務合併至一套歷史庫叢集，架構更加簡潔

• DTS鏈路也分為走RDS和DRDS兩種

資料同步鏈路走RDS

資料同步鏈路走DRDS

03

同例項混用儲存引擎方案

線上庫/歷史庫拆分方案相對較為複雜，RDS支援同一例項混用儲存引擎。針對總資料量不是特別大的場景，可以考慮同一例項下Innodb&X-Engine引擎混合使用

使用DMS-->資料工廠-->資料編排功能可以輕鬆地實現同一例項內的資料流動和過期資料刪除，架構示意圖如下。

• 實現簡單靈活

• 混用儲存引擎，在資料庫核心引數最佳化上難以兼顧兩者效能

• 歷史資料compact階段可能對整個例項產生效能抖動

• 同一例項下的庫或者表無法重名，涉及到輕量業務改造

04

DTS賦能線上/歷史資料流轉

DTS不僅支援全量&增量同步，支援不同資料庫產品之間的資料同步，在線上/歷史庫解決方案中，DTS強大的"條件過濾"功能是非常重要的一環，透過配置DTS任務可以非常便捷地實現過濾Delete操作，動動滑鼠點兩下即可實現自定義的資料同步策略。

05

DMS賦能線上庫過期資料刪除

線上庫的過期資料刪除既要保障刪除效率，也要保證刪除過程中對線上庫不會造成效能上的抖動，新版DMS支援建立“歷史資料清理”的資料變更任務，透過該任務可以非常方便地完成以下工作

• 歷史資料定期刪除，指定排程時間和一次排程時長
• 大事務拆分，減少事務執行過程中鎖表時間過長，避免主備延遲
• 清理遭遇異常中斷可重試
• 支援檢視任務執行狀態和失敗原因分析
• 配置方面簡潔

過期資料清理思路

如果沒有使用DMS生態工具，也自行實現過期資料刪除，但實現較為複雜。一般較為通用的設計思路為將表的主鍵按照大小做拆分，保證一次刪除"恰當數量"的資料，既保證刪除效率又不影響線上服務

• 線上庫的歷史資料刪除策略(假設主鍵為id，資料儲存180天，時間屬性列為date_col)

1. 初始化數值Y=select min(id) from $table_name

2. 到了業務低峰期以後，DELETE FROM $table_name WHERE date_col< SUBDATE(CURDATE(),INTERVAL 180 DAY) and id >= Y and id <=
   Y+100000 ,執行成功後程式碼層重新賦值 Y=Y+100000

3. 程式sleep 3s,重複步驟b

4. 時間到了業務高峰期以後，停止執行，記錄下當前的數值Y，第二天執行時直接從Y開始注意

• 線上庫歷史資料清理注意點

• 程式碼上注意不要出現高併發刪除的情況，即步驟b還沒跑完，新的步驟b又進來了
• 程式sleep的具體秒數，要透過測試，取一個最合適的數值，主要看主備是否存在較大延遲，3只是估值
• 100000也是一個估值，實際取值最好也透過測試，取一個效率最高，對業務影響最小的數值。因為drds的序列不是單點遞增1的，所以這裡的10w不代表10w條記錄。
• 假設刪除程式中途崩潰了，或者執行很多天後發現部分資料沒有刪除。 那麼可以手工先刪除一小部分殘留的資料，比如預估下id<100w的記錄還有多少條，不多的話直接執行DELETE FROM  logs_trans WHERE reqdate < SUBDATE(CURDATE(),INTERVAL 30 DAY) and id<100w 然後初始化整個程式,這樣保證重新初始化以後不會做很多無用功，即反覆執行刪除條目很少的sql

06

極端場景分析

在臨界時間處理上，實時歷史庫方案可能遭遇極端場景導致業務可能存在歷史庫的髒讀問題，假設線上庫資料儲存180天

1. 更新179天前23時59分59秒的資料，請求路由至線上庫

2. 資料同步鏈路異常中斷或鏈路存在延遲，該更新請求未能及時到達歷史庫

3. 這時業務查詢該資料時，由於已經資料已經"舊"到超過180天，請求路由至歷史庫，由於鏈路異常，歷史庫查到了髒資料

解決方法

• 配置鏈路異常告警，及時發現及時處理

• 預計影響的資料範圍為DTS鏈路恢復前的臨界時間點附近資料，建議從業務邏輯上訂正資料

• 建議過期資料刪除設定保守一點，比如臨界時間為180天，過期資料只刪除190天以後的資料，方便在極端場景下對比源端目標端的資料情況進行資料訂正

4

最佳實踐參考

1.X-Engine如何支撐釘釘躍居AppStore第一

2.淘寶萬億級交易訂單背後的儲存引擎

3.將DRDS中的InnoDB引擎轉換為X-Engine引擎

連結： https://help.aliyun.com/document_detail/161316.html