暂无图片
暂无图片
暂无图片
暂无图片
暂无图片

冷数据按行归档-原理概述

快点好起来 2024-11-12
309

冷数据按行归档是TTL 2.0方案,先将冷数据自动归档至OSS对象存储,再基于DELETE的DML操作清理在线表中的冷数据。

名词解释

名词

说明

冷数据

在实例中某些数据库表几乎没有更新,且查询频率非常低的数据。

在线表

承载在线流量的业务数据表。

归档表

用于保存已归档数据的表,通常存放在高压缩、低成本的存储介质中,例如OSS。

TTL

全称为“生存时间”(Time To Live),指的是数据在数据库中所能存储的时间长度。在此时间段之后,数据将被自动清理。

TTL表

所有设置了TTL定义的在线表。

TTL列

TTL定义中用于计算数据有效性的时间列。

背景

在实际生产中,有些业务只希望保留最近一段时间的数据(热数据),并对于使用频率很低且不断积累的过期数据(冷数据)采用存储成本更低的方式保存,同时又可以利用这些冷数据进行分析统计业务。综上所述,业务对处理冷数据,主要有以下需求:

  • 可以定时清理冷数据。
  • 更低的冷数据存储成本。
  • 归档后仍然可以供后台业务进行分析统计。

PolarDB-X提供了冷数据归档(TTL)能力,可以有效地解决上述问题。

基于列存索引的冷数据归档

优势

PolarDB-X结合列存索引提供了行级冷数据归档方案,其具有以下明显特点:

  • 高压缩率:列存索引针对表中每个列的数据类型选择最优的数据压缩算法,从而实现整表数据存储的高压缩率。更多信息,请参见列存索引(CCI)
  • 实时性高、强一致性:列存索引通过订阅主实例的增量Binlog,以保持与主表的实时同步。
  • 低存储成本:列存索引支持转存至OSS,其存储成本很低,具有良好的性价比。更多信息,请参见对象存储(OSS)
  • 一体化透明HTAP能力:可以提供完全兼容MySQL的一体化透明HTAP能力,使业务能够在同一系统中同时进行事务处理和数据分析,无需复杂的架构调整。更多信息,请参见混合负载(HTAP)

方案概述

PolarDB-X冷数据归档并没有采用其它云数据库产品常用的“一边归档、一边清理”归档方案,而是采用了“提前归档、定期清理”的归档方案:

  • 提前归档:在线表被TTL定义后,列存节点会基于该表的全量数据生成对应的列存索引,并转存至OSS中。同时,订阅在线表的Binlog,将增量数据也实时存入OSS中。如下图所示:

image

  • 定期清理:在线表的所有数据完成归档后,TTL提供了清理在线表中已归档数据的能力(具体操作,请参见TTL表过期数据清理),清理操作不会对已归档至OSS的数据产生任何影响。

image

方案详述

  • 冷数据归档

在TTL 2.0中,创建TTL表对应的归档表时,其本质是在创建列存索引的过程,期间列存节点不仅会基于快照读将TTL表的存量数据上传至归档表的OSS存储中,还会实时订阅TTL表的Binlog,以此实时执行增量数据的行转列转换,并上传增量更新到归档表的OSS存储中。如下图所示:

image

说明

上图归档阶段运行的具体步骤如下:

检查在线表是否存在TTL定义。

  • 在线表的TTL定义,需要您手动通过DDL设置,该过程主要用于定义过期时间列以及数据过期时间间隔。具体操作,请参见TTL表的定义及创建

为TTL表(当前在线表存在TTL定义)创建用于保存冷数据的归档表。具体操作,请参见归档表语法说明

  1. 系统自动在TTL表之上创建一个归档专用的列存索引(高压缩低成本OSS存储)。
  2. 该列存索引自动将TTL表的存量数据上传到OSS进行存储。
  3. 该列存索引将实时订阅TTL表的Binlog,以实时执行增量数据的行转列转换,并上传增量更新到归档表的OSS存储中。


  • 冷数据清理算法

TTL表采用的是“由远及近分批清理”的清理算法,从最早的数据开始清理,每次只清理固定时间范围的数据。更多信息,请参见TTL表过期数据清理

假设当前时间为2023-10-01,在线表只需要保存最近1个月的数据,清理流程如下图所示:

image

说明

Day 1:

TTL定义的时间列其最小时间值为2022-10-05(MinValue),再根据清理的时间范围(CleanupDataInterval,本例中为3个月。更多信息,请参见调整清理时间范围。)得出本次清理的范围为2022-10-05≤Time<2023-01-01。以此类推其他清理范围分别是2023-01-01≤Time<2023-04-01、2023-04-01≤Time<2023-07-01、2023-07-01≤Time<2023-09-01。

Day 2:

同Day 1,清理时间列满足2023-01-01≤Time<2023-04-01条件的数据,即2023-04-01为本次清理任务的上边界(CleanupUpperBound)。

Day 3:

同Day 1,清理时间列满足2023-04-01≤Time<2023-07-01条件的数据,即2023-07-01为本次清理任务的上边界(CleanupUpperBound)。

Day 4:

与之前略有不同,清理时间列满足2023-07-01≤Time<2023-09-01条件的数据,时间范围为2个月。因为上图中假设的当前时间为2023-10-01(Now),且TTL表被设置为保留最近1个月(ExpiredDataInterval,TTL表的数据存活时间)的数据,所以本次只能清理2023-09-01之前的数据,即2023-09-01为本次清理任务的上边界(CleanupUpperBound)。

综上所述,可以得出每次清理任务的上边界(CleanupUpperBound)的计算公式为CleanupUpperBound=Min(MinValue+CleanupDataInterval,Now−ExpiredDataInterval)。

  • 归档表冷数据清理(可选)

随着时间推移归档表所保存的冷数据越来越多,您可能需要对归档表中的冷数据进行定期清理,以减少存储压力。冷数据被归档后,数据会被转存到归档表的OSS存储中。归档表会按TTL表中的TTL列自动进行Range分区。其原理如下图所示:

image

说明

由于归档表的冷数据都已按归档的TTL定义的列进行了Range分区,所以您可以直接使用分区变更语法(比如,删除分区)来清理归档数据。清理数据操作也可以调整和设置TTL定义来实现。具体操作,请参见删除分区和修改TTL定义调整TTL定义


最后修改时间:2024-11-15 13:13:16
「喜欢这篇文章,您的关注和赞赏是给作者最好的鼓励」
关注作者
【版权声明】本文为墨天轮用户原创内容,转载时必须标注文章的来源(墨天轮),文章链接,文章作者等基本信息,否则作者和墨天轮有权追究责任。如果您发现墨天轮中有涉嫌抄袭或者侵权的内容,欢迎发送邮件至:contact@modb.pro进行举报,并提供相关证据,一经查实,墨天轮将立刻删除相关内容。

评论