實時歷史庫需求背景

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

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

 

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

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

 

• 存儲成本巨大，進而導致成本遠大于收益，比如釘釘聊天信息數據量在高度壓縮后接近50PB，很難想象這些數據不做壓縮會帶來多大的資金開銷

• 性能挑戰巨大，隨著數據量越來越大，即使針對數據做了分布式存儲，單實例容量超過大概5T以后性能也會急劇下滑，進而影響到近期活躍數據的查詢性能，拖垮整個集群

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

 

1

 

實時歷史庫場景需求分析

 

通過上面的分析，不管是冷備份還是在線歷史數據混合存儲在同一張物理表上的方法都是不可取的，一般實時

總結

以上是生活随笔為你收集整理的如何解决实时历史数据库存储成本问题？的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。