實時歷史庫需求背景
在當今的數字化時代，隨着業務的迅速發展，每天產生的數據量會是一個驚人的數量，數據庫存儲的成本將會越來越大，通常的做法是對歷史數據做歸檔，即將長期不使用的數據遷移至以文件形式存儲的廉價存儲設備上，比如阿里雲OSS或者阿里雲數據庫DBS服務。
然而在部分核心業務的應用場景下，針對幾個月甚至幾年前的“舊”數據依舊存在實時的，低頻的查詢甚至更新需求，比如淘寶/天貓的歷史訂單查詢，企業級辦公軟件釘釘幾年前的聊天信息查詢，菜鳥海量物流的歷史物流訂單詳情等。
如果這時從歷史備份中還原後查詢，那麼查詢時間將會是以天爲單位，可接受度爲0
如果將這些低頻但實時的查詢需求的歷史數據與近期活躍存儲在同一套分佈式數據庫集羣下，那麼又會帶來以下兩大挑戰
-
存儲成本巨大，進而導致成本遠大於收益，比如釘釘聊天信息數據量在高度壓縮後接近50PB，很難想象這些數據不做壓縮會帶來多大的資金開銷
-
性能挑戰巨大，隨着數據量越來越大，即使針對數據做了分佈式存儲，單實例容量超過大概5T以後性能也會急劇下滑，進而影響到近期活躍數據的查詢性能，拖垮整個集羣
-
運維難度巨大，比如針對海量數據下發一個表數據結構變更操作，很難想象全部完成需要多長時間
1
實時歷史庫場景需求分析
通過上面的分析，不管是冷備份還是在線歷史數據混合存儲在同一張物理表上的方法都是不可取的，一般實時查詢歷史數據庫的場景，一般需要有以下幾個關鍵特性
-
成本可控，歷史數據的存儲成本無法接受和在線庫一樣線性增長
-
實時查詢，歷史數據的查詢RT要做到與在線活躍庫幾乎一致