深度 | 實時歷史數據庫存儲成本驚人，怎么破？

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

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

實時歷史庫需求背景

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

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

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

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

實時歷史庫場景需求分析

• 成本可控 ，歷史數據的存儲成本無法接受和在線庫一樣線性增長

• 實時查詢 ，歷史數據的查詢RT要做到與在線活躍庫幾乎一致

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

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

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

• 可能存在歷史數據更新需求

• 數據規模較大 ，一般在100TB以上

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倍 的優勢。

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

3.在存儲層引入數據復用技術等，優化Compaction的性能，降低傳統LSM-tree架構中Compaction動作對系統資源的沖擊，保持系統性能平穩

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

實時歷史數據庫架構設計和實現

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

• 久經考驗的Innodb引擎作為OLTP在線庫核心引擎，主要處理高頻查詢/更新請求，滿足在線活躍數據高并發，高性能，強范圍查詢的業務需求

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

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

• 在線-歷史數據通過阿里云提供的生態體系工具做歷史數據遷移和過期數據刪除，確保鏈路更為穩定可靠

源端為DRDS集群

a.數據同步鏈路走RDS

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

b.數據同步鏈路走DRDS

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

源端為多個RDS

a.目標端為多個RDS

? 業務代碼無需任何改造
? 運行后期歷史庫節點磁盤容量存在風險

b.目標端為DRDS集群

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

• 可將多個在線庫業務合并至一套歷史庫集群，架構更加簡潔

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

數據同步鏈路走RDS

• 實現簡單靈活

• 混用存儲引擎，在數據庫內核參數優化上難以兼顧兩者性能

• 歷史數據compact階段可能對整個實例產生性能抖動

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

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

? 歷史數據定期刪除，指定調度時間和一次調度時長
? 大事務拆分，減少事務執行過程中鎖表時間過長，避免主備延遲
? 清理遭遇異常中斷可重試
? 支持查看任務運行狀態和失敗原因分析
? 配置方面簡潔

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

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

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

1. 更新179天前23時59分59秒的數據，請求路由至在線庫

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

3. 這時業務查詢該數據時，由于已經數據已經"舊"到超過180天，請求路由至歷史庫，由于鏈路異常，歷史庫查到了臟數據

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

最佳實踐參考

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

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

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

鏈接： https://help.aliyun.com/document_detail/161316.html