实时历史库需求背景
在当今的数字化时代，随着业务的迅速发展，每天产生的数据量会是一个惊人的数量，数据库存储的成本将会越来越大，通常的做法是对历史数据做归档，即将长期不使用的数据迁移至以文件形式存储的廉价存储设备上，比如阿里云OSS或者阿里云数据库DBS服务。
然而在部分核心业务的应用场景下，针对几个月甚至几年前的“旧”数据依旧存在实时的，低频的查询甚至更新需求，比如淘宝/天猫的历史订单查询，企业级办公软件钉钉几年前的聊天信息查询，菜鸟海量物流的历史物流订单详情等。
如果这时从历史备份中还原后查询，那么查询时间将会是以天为单位，可接受度为0
如果将这些低频但实时的查询需求的历史数据与近期活跃存储在同一套分布式数据库集群下，那么又会带来以下两大挑战
-
存储成本巨大，进而导致成本远大于收益，比如钉钉聊天信息数据量在高度压缩后接近50PB，很难想象这些数据不做压缩会带来多大的资金开销
-
性能挑战巨大，随着数据量越来越大，即使针对数据做了分布式存储，单实例容量超过大概5T以后性能也会急剧下滑，进而影响到近期活跃数据的查询性能，拖垮整个集群
-
运维难度巨大，比如针对海量数据下发一个表数据结构变更操作，很难想象全部完成需要多长时间
1
实时历史库场景需求分析
通过上面的分析，不管是冷备份还是在线历史数据混合存储在同一张物理表上的方法都是不可取的，一般实时查询历史数据库的场景，一般需要有以下几个关键特性
-
成本可控，历史数据的存储成本无法接受和在线库一样线性增长
-
实时查询，历史数据的查询RT要做到与在线活跃库几乎一致