如何解决实时历史数据库存储成本问题?

实时历史库需求背景

在当今的数字化时代,随着业务的迅速发展,每天产生的数据量会是一个惊人的数量,数据库存储的成本将会越来越大,通常的做法是对历史数据做归档,即将长期不使用的数据迁移至以文件形式存储的廉价存储设备上,比如阿里云OSS或者阿里云数据库DBS服务。

然而在部分核心业务的应用场景下,针对几个月甚至几年前的“旧”数据依旧存在实时的,低频的查询甚至更新需求,比如淘宝/天猫的历史订单查询,企业级办公软件钉钉几年前的聊天信息查询,菜鸟海量物流的历史物流订单详情等。

 

如果这时从历史备份中还原后查询,那么查询时间将会是以天为单位,可接受度为0

如果将这些低频但实时的查询需求的历史数据与近期活跃存储在同一套分布式数据库集群下,那么又会带来以下两大挑战

 

  • 存储成本巨大,进而导致成本远大于收益,比如钉钉聊天信息数据量在高度压缩后接近50PB,很难想象这些数据不做压缩会带来多大的资金开销

  • 性能挑战巨大,随着数据量越来越大,即使针对数据做了分布式存储,单实例容量超过大概5T以后性能也会急剧下滑,进而影响到近期活跃数据的查询性能,拖垮整个集群

  • 运维难度巨大,比如针对海量数据下发一个表数据结构变更操作,很难想象全部完成需要多长时间

 

1

 

实时历史库场景需求分析

 

通过上面的分析,不管是冷备份还是在线历史数据混合存储在同一张物理表上的方法都是不可取的,一般实时

  • 0
    点赞
  • 0
    评论
  • 1
    收藏
  • 一键三连
    一键三连
  • 扫一扫,分享海报

©️2021 CSDN 皮肤主题: 代码科技 设计师:Amelia_0503 返回首页
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、C币套餐、付费专栏及课程。

余额充值