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

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

創(chuàng)新互聯(lián)服務(wù)緊隨時代發(fā)展步伐，進行技術(shù)革新和技術(shù)進步，經(jīng)過十多年的發(fā)展和積累，已經(jīng)匯集了一批資深網(wǎng)站策劃師、設(shè)計師、專業(yè)的網(wǎng)站實施團隊以及高素質(zhì)售后服務(wù)人員，并且完全形成了一套成熟的業(yè)務(wù)流程，能夠完全依照客戶要求對網(wǎng)站進行成都網(wǎng)站建設(shè)、網(wǎng)站制作、建設(shè)、維護、更新和改版，實現(xiàn)客戶網(wǎng)站對外宣傳展示的首要目的，并為客戶企業(yè)品牌互聯(lián)網(wǎng)化提供全面的解決方案。

舟濟阿里云解決方案架構(gòu)師

實時歷史庫需求背景

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

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

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

如果將這些低頻但實時的查詢需求的歷史數(shù)據(jù)與近期活躍存儲在同一套分布式數(shù)據(jù)庫集群下，那么又會帶來以下兩大挑戰(zhàn)

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

運維難度巨大 ，比如針對海量數(shù)據(jù)下發(fā)一個表數(shù)據(jù)結(jié)構(gòu)變更操作，很難想象全部完成需要多長時間

實時歷史庫場景需求分析

通過上面的分析，不管是冷備份還是在線歷史數(shù)據(jù)混合存儲在同一張物理表上的方法都是不可取的，一般實時查詢歷史數(shù)據(jù)庫的場景，一般需要有以下幾個關(guān)鍵特性

成本可控 ，歷史數(shù)據(jù)的存儲成本無法接受和在線庫一樣線性增長
實時查詢 ，歷史數(shù)據(jù)的查詢RT要做到與在線活躍庫幾乎一致
查詢頻次較低 ，一般來說，越“舊”的數(shù)據(jù)查詢頻率越低
統(tǒng)一查詢?nèi)肟?/strong> ，不管是活躍數(shù)據(jù)還是歷史數(shù)據(jù)，查詢?nèi)肟诒３忠恢?/p>
改造成本需要盡可能低 ，最好能做到不做任何應(yīng)用代碼修改，可以認為歷史庫對程序開發(fā)人員來說是完全透明的
可能存在歷史數(shù)據(jù)更新需求
數(shù)據(jù)規(guī)模較大 ，一般在100TB以上

2

X-Engine引擎介紹

01

X-Engine簡介

X-Engine是阿里云數(shù)據(jù)庫產(chǎn)品事業(yè)部自研的聯(lián)機事務(wù)處理OLTP（On-Line Transaction Processing）數(shù)據(jù)庫存儲引擎。作為自研數(shù)據(jù)庫PolarDB 的存儲引擎之一，已經(jīng)廣泛應(yīng)用在阿里集團內(nèi)部諸多業(yè)務(wù)系統(tǒng)中，包括交易歷史庫、釘釘歷史庫等核心應(yīng)用，大幅縮減了業(yè)務(wù)成本，同時也作為雙十一大促的關(guān)鍵數(shù)據(jù)庫技術(shù)，挺過了數(shù)百倍平時流量的沖擊。

與傳統(tǒng)的InnoDB引擎不同，X-Engine使用分層存儲架構(gòu)（LSM-Tree）。分層存儲有兩個比較顯著的優(yōu)點：

需要索引的熱點數(shù)據(jù)集更小，寫入性能更高 。
底層持久化的數(shù)據(jù)頁是只讀的，數(shù)據(jù)頁采用緊湊存儲格式，同時默認進行壓縮，存儲成本更低。

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

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

1.通常我們默認MySQL是當今最流行的開源數(shù)據(jù)庫，大概率是在線核心數(shù)據(jù)庫集群的首選。相比其他高壓縮的存儲引擎，引入X-Engine完全無需做任何SQL代碼改造，并且支持事務(wù)，接入成本最低，學習成本幾乎為0

2.寫入性能更強，X-Engine相比同為LSM-tree架構(gòu)的Rocksdb，有超過10倍的性能提升。
3.在存儲層引入數(shù)據(jù)復(fù)用技術(shù)等，優(yōu)化Compaction的性能，降低傳統(tǒng)LSM-tree架構(gòu)中Compaction動作對系統(tǒng)資源的沖擊，保持系統(tǒng)性能平穩(wěn)
4.引入多個層級Cache，同時結(jié)合Cach回填和預(yù)取機制，利用精細化訪問機制和緩存技術(shù)，彌補傳統(tǒng)LSM-tree引擎的讀性能短板，X-Engine的點查詢能力幾乎與Innodb持平
下圖是X-Engine與主流歷史數(shù)據(jù)存儲方案對比

3

實時歷史數(shù)據(jù)庫架構(gòu)設(shè)計和實現(xiàn)

01
總體架構(gòu)思路

基于上文對實時歷史庫和X-Engine的介紹，阿里云數(shù)據(jù)庫團隊推出以X-Engine引擎為歷史數(shù)據(jù)存儲核心，同時生態(tài)工具DTS作為在線/歷史數(shù)據(jù)流轉(zhuǎn)通道，DMS作為歷史數(shù)據(jù)無風險刪除的完整“實時在線-歷史庫”方案，針對不同的業(yè)務(wù)場景和客戶需求，在具體實現(xiàn)上可能會有所不同，我們提供了多種實時歷史庫方案的具體實現(xiàn)。主體架構(gòu)圖如下，核心思路為：
久經(jīng)考驗的Innodb引擎作為OLTP在線庫核心引擎，主要處理高頻查詢/更新請求，滿足在線活躍數(shù)據(jù)高并發(fā)，高性能，強范圍查詢的業(yè)務(wù)需求
阿里巴巴數(shù)據(jù)庫團隊自研的高壓測存儲引擎X-Engine作為歷史庫核心引擎，主要響應(yīng)歷史數(shù)據(jù)入庫/查詢/更新請求，滿足歷史數(shù)據(jù)冷熱數(shù)據(jù)頻次不一，低存儲成本，高性能的業(yè)務(wù)需求(范圍查詢可能性能受限)
統(tǒng)一DB接入層，根據(jù)設(shè)置的業(yè)務(wù)時間屬性將請求分別轉(zhuǎn)發(fā)至不同的存儲引擎。針對特殊場景下的跨引擎訪問，在應(yīng)用層做聚合展示
在線-歷史數(shù)據(jù)通過阿里云提供的生態(tài)體系工具做歷史數(shù)據(jù)遷移和過期數(shù)據(jù)刪除，確保鏈路更為穩(wěn)定可靠

02
在線庫/歷史庫拆分方案

一般來說，需要使用到實時歷史庫的場景，數(shù)據(jù)量都足夠大到單臺宿主機存放不了。在線數(shù)據(jù)庫可能是根據(jù)業(yè)務(wù)水平或垂直拆分的多個RDS，也可能是一個規(guī)模較大的DRDS集群。為了盡可能地保證在線庫的性能，推薦將在線庫/歷史庫完全拆分解耦

? 歷史庫集群存儲全量數(shù)據(jù)

? 通過DTS鏈路打通在線庫和歷史庫，實時同步

? DTS鏈路過濾Delete操作

? 可直接使用新版DMS配置歷史數(shù)據(jù)定期刪除

源端為DRDS集群

a.數(shù)據(jù)同步鏈路走RDS

? 多條DTS鏈路打通底層RDS節(jié)點，同步性能強
? RDS數(shù)量較多可支持API批量創(chuàng)建和配置
? 鏈路穩(wěn)定性更好
? 需要保證源端目標端庫表數(shù)量一致，數(shù)據(jù)路由規(guī)則一致

b.數(shù)據(jù)同步鏈路走DRDS

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

源端為多個RDS

a.目標端為多個RDS

? 業(yè)務(wù)代碼無需任何改造
? 運行后期歷史庫節(jié)點磁盤容量存在風險

b.目標端為DRDS集群

可能涉及到業(yè)務(wù)代碼輕量改造，目標端不走分庫分表鍵性能無法保證
可將多個在線庫業(yè)務(wù)合并至一套歷史庫集群，架構(gòu)更加簡潔
DTS鏈路也分為走RDS和DRDS兩種

數(shù)據(jù)同步鏈路走RDS

數(shù)據(jù)同步鏈路走DRDS

03

同實例混用存儲引擎方案

在線庫/歷史庫拆分方案相對較為復(fù)雜，RDS支持同一實例混用存儲引擎。針對總數(shù)據(jù)量不是特別大的場景，可以考慮同一實例下Innodb&X-Engine引擎混合使用

使用DMS-->數(shù)據(jù)工廠-->數(shù)據(jù)編排功能可以輕松地實現(xiàn)同一實例內(nèi)的數(shù)據(jù)流動和過期數(shù)據(jù)刪除，架構(gòu)示意圖如下。

實現(xiàn)簡單靈活
混用存儲引擎，在數(shù)據(jù)庫內(nèi)核參數(shù)優(yōu)化上難以兼顧兩者性能
歷史數(shù)據(jù)compact階段可能對整個實例產(chǎn)生性能抖動
同一實例下的庫或者表無法重名，涉及到輕量業(yè)務(wù)改造

04

DTS賦能在線/歷史數(shù)據(jù)流轉(zhuǎn)

DTS不僅支持全量&增量同步，支持不同數(shù)據(jù)庫產(chǎn)品之間的數(shù)據(jù)同步，在在線/歷史庫解決方案中，DTS強大的"條件過濾"功能是非常重要的一環(huán)，通過配置DTS任務(wù)可以非常便捷地實現(xiàn)過濾Delete操作，動動鼠標點兩下即可實現(xiàn)自定義的數(shù)據(jù)同步策略。

05
DMS賦能在線庫過期數(shù)據(jù)刪除

在線庫的過期數(shù)據(jù)刪除既要保障刪除效率，也要保證刪除過程中對在線庫不會造成性能上的抖動，新版DMS支持創(chuàng)建“歷史數(shù)據(jù)清理”的數(shù)據(jù)變更任務(wù)，通過該任務(wù)可以非常方便地完成以下工作
? 歷史數(shù)據(jù)定期刪除，指定調(diào)度時間和一次調(diào)度時長
? 大事務(wù)拆分，減少事務(wù)執(zhí)行過程中鎖表時間過長，避免主備延遲
? 清理遭遇異常中斷可重試
? 支持查看任務(wù)運行狀態(tài)和失敗原因分析
? 配置方面簡潔

過期數(shù)據(jù)清理思路

如果沒有使用DMS生態(tài)工具，也自行實現(xiàn)過期數(shù)據(jù)刪除，但實現(xiàn)較為復(fù)雜。一般較為通用的設(shè)計思路為將表的主鍵按照大小做拆分，保證一次刪除"恰當數(shù)量"的數(shù)據(jù)，既保證刪除效率又不影響線上服務(wù)
? 在線庫的歷史數(shù)據(jù)刪除策略(假設(shè)主鍵為id，數(shù)據(jù)保存180天，時間屬性列為date_col)

初始化數(shù)值Y=select min(id) from $table_name
到了業(yè)務(wù)低峰期以后，DELETE FROM $table_name WHERE date_col< SUBDATE(CURDATE(),INTERVAL 180 DAY) and id >= Y and id <=
Y+100000 ,執(zhí)行成功后代碼層重新賦值 Y=Y+100000
程序sleep 3s,重復(fù)步驟b
時間到了業(yè)務(wù)高峰期以后，停止執(zhí)行，記錄下當前的數(shù)值Y，第二天執(zhí)行時直接從Y開始注意

? 在線庫歷史數(shù)據(jù)清理注意點

代碼上注意不要出現(xiàn)高并發(fā)刪除的情況，即步驟b還沒跑完，新的步驟b又進來了

程序sleep的具體秒數(shù)，要通過測試，取一個最合適的數(shù)值，主要看主備是否存在較大延遲，3只是估值

100000也是一個估值，實際取值最好也通過測試，取一個效率最高，對業(yè)務(wù)影響最小的數(shù)值。因為drds的序列不是單點遞增1的，所以這里的10w不代表10w條記錄。

假設(shè)刪除程序中途崩潰了，或者執(zhí)行很多天后發(fā)現(xiàn)部分數(shù)據(jù)沒有刪除。那么可以手工先刪除一小部分殘留的數(shù)據(jù)，比如預(yù)估下id<100w的記錄還有多少條，不多的話直接執(zhí)行DELETE FROM logs_trans WHERE reqdate < SUBDATE(CURDATE(),INTERVAL 30 DAY) and id<100w 然后初始化整個程序,這樣保證重新初始化以后不會做很多無用功，即反復(fù)執(zhí)行刪除條目很少的sql

06
極端場景分析

在臨界時間處理上，實時歷史庫方案可能遭遇極端場景導致業(yè)務(wù)可能存在歷史庫的臟讀問題，假設(shè)在線庫數(shù)據(jù)保存180天
更新179天前23時59分59秒的數(shù)據(jù)，請求路由至在線庫
數(shù)據(jù)同步鏈路異常中斷或鏈路存在延遲，該更新請求未能及時到達歷史庫
這時業(yè)務(wù)查詢該數(shù)據(jù)時，由于已經(jīng)數(shù)據(jù)已經(jīng)"舊"到超過180天，請求路由至歷史庫，由于鏈路異常，歷史庫查到了臟數(shù)據(jù)

解決方法

? 配置鏈路異常告警，及時發(fā)現(xiàn)及時處理

? 預(yù)計影響的數(shù)據(jù)范圍為DTS鏈路恢復(fù)前的臨界時間點附近數(shù)據(jù)，建議從業(yè)務(wù)邏輯上訂正數(shù)據(jù)

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

4

最佳實踐參考
1.X-Engine如何支撐釘釘躍居AppStore第一
2.淘寶萬億級交易訂單背后的存儲引擎
3.將DRDS中的InnoDB引擎轉(zhuǎn)換為X-Engine引擎
鏈接： https://help.aliyun.com/document_detail/161316.html

本文名稱：深度|實時歷史數(shù)據(jù)庫存儲成本驚人，怎么破？
文章地址：http://weahome.cn/article/pdepdc.html