数据存储冷热分离
云原生数据仓库 AnalyticDB MySQL 版数据冷热分离功能会将冷热数据分别存储在不同的介质上,在保证热数据查询性能的同时,降低冷数据的存储成本。
为什么要使用数据冷热分离
在海量大数据场景下,一张业务表中可能存储着大量的业务数据(例如日志数据、订单数据或监控数据)。随着时间的推移,部分数据的访问频率会逐渐降低,最终被搁置。但是这部分数据依旧会占用存储空间,导致存储成本增加。
AnalyticDB for MySQL数据冷热分离主要适用于按时间日期分区的表。集群会根据指定的热分区数量,按照分区的大小(分区键值的大小)降序排序,最大的N个分区为热分区,其余分区为冷分区。冷分区的数据会移动到成本更低的对象存储服务OSS中,降低存储成本;与此同时,热分区的数据仍然存储在SSD盘中,保证数据查询的高性能。
前提条件
AnalyticDB for MySQL集群需要同时满足以下条件:
集群的产品系列为企业版、基础版、湖仓版或数仓版弹性模式。
集群内核版本需为3.1.3.3及以上。
查看企业版、基础版或湖仓版集群的内核版本,请执行
SELECT adb_version();
。如需升级内核版本,请联系技术支持。查看和升级数仓版集群的内核版本,请参见查看和升级版本。
费用说明
集群在使用过程中,存储热数据和冷数据占用的存储空间会按量收费。详情请参见产品定价。
支持使用存储资源包抵扣存储空间。详情请参见存储资源包。
冷热存储策略
AnalyticDB for MySQL冷热存储策略分为全冷存储、全热存储、冷热混合存储。
全冷存储指数据全部存储在OSS中,采用本地冗余存储(单AZ),是一种较为经济的存储策略。
全热存储指数据全部存储在SSD盘,满足高性能访问的需求,查询性能最好,但存储成本最高。
冷热混合存储指热分区数据存储在SSD盘,冷分区数据存储在OSS。既保证热分区数据的查询性能,又节省冷分区数据的存储成本。其原理如下:
冷热混合存储需指定热分区数。假设热分区数为N,在按照分区的大小(分区键值的大小)降序排序后,最大的N个分区为热分区,存储在SSD盘,其余分区为冷分区,存储在OSS中,形成冷热分区布局。冷热分区布局不是固定不变的,当分区数量变更时,会重新调整冷热分区布局。详细说明,请参见分区数量变更对冷热分区布局的影响。
分区数量变更对冷热分区布局的影响
假设当前热分区数为N,在有新的分区数据写入时,冷热存储策略会对所有分区重新排序,超过N的旧数据会迁移到冷分区。
假设当前热分区数为N,修改热分区的数量为M。
当热分区数增加,即M>N时,会从冷分区迁移
M-N
个分区数据到热分区。当热分区数减少,即M<N时,会从热分区迁移
N-M
个分区数据到冷分区。
指定冷热存储策略
创建表时指定冷热存储策略:您可以在建表时通过
storage_policy
参数来指定表的冷热存储策略。详情请参见CREATE TABLE。为已有的表指定冷热存储策略:您可以通过
ALTER TABLE
语句指定表的冷热存储策略。详情请参见变更冷热存储策略。
查询表的冷热存储策略
语法
查询所有表的冷热存储策略:
SELECT * FROM information_schema.table_usage;
查询单个表的冷热存储策略:
SELECT * FROM information_schema.table_usage WHERE table_schema='<schema_name>' AND table_name='<table_name>';
返回值说明
参数 | 说明 |
参数 | 说明 |
table_schema | 数据库名。 |
table_name | 表名。 |
storage_policy | 存储策略。取值如下:
|
hot_partition_count | 热分区数量。 |
cold_partition_count | 冷分区数量。 |
rt_total_size | 实时数据总量(单位:Byte),是rt_data_size和rt_index_size的总和。 |
rt_data_size | 实时数据量(单位:Byte)。 |
rt_index_size | 实时数据的主键和索引大小(单位:Byte)。 |
hot_total_size | 热分区总数据量(单位:Byte),是hot_data_size和hot_index_size的总和。 |
hot_data_size | 热分区的数据量(单位:Byte)。 |
hot_index_size | 热分区数据的主键和索引大小(单位:Byte)。 |
cold_total_size | 冷分区总数据量(单位:Byte),是cold_data_size和cold_index_size的总和。 |
cold_data_size | 冷分区的数据量(单位:Byte)。 |
cold_index_size | 冷分区数据的主键和索引大小(单位:Byte)。 |
返回值注意事项:
受到INSERT、UPDATE、BUILD的影响,rt_total_size、rt_data_size、rt_index_size、hot_total_size、hot_data_size、hot_index_size、cold_total_size、cold_data_size、cold_index_size会实时变动。
如果在写入数据后hot_total_size和cold_total_size都为0,则表示数据还在实时同步中。rt_total_size表示实时数据量。您可以通过BUILD语句将实时数据转换为历史数据,待BUILD完成后可以查到hot_total_size和cold_total_size。BUILD的详细信息,请参见BUILD。
由于定义的hot_partition_count是单个分片(Shard)内的热分区数量,而table_usage表查询到的hot_partition_count是按照Shard UNION之后的结果,在各Shard内分区数据不一致的情况下,可能会出现table_usage表中查询到的hot_partition_count大于定义的hot_partition_count。
例如:tableA有两个Shard(Shard1和Shard2),并且定义了hot_partition_count=2,此时Shard内的数据分布情况如下图。
Shard1:热分区为P4、P5,冷分区为P1、P2、P3。
Shard2:热分区为P3、P4,冷分区为P1、P2。
最终计算的实际热分区为(P4、P5)UNION(P3、P4)=(P3、P4、P5),因此实际hot_partition_count=3。
查询表的冷热存储策略变更进度
在使用ALTER TABLE
语句修改表的冷热存储策略后,您可以通过查询表storage_policy_modify_progress
来查看冷热变更进度。
语法
查询所有表的冷热存储策略变更进度:
SELECT * FROM information_schema.storage_policy_modify_progress;
查询单个表的冷热存储策略变更进度:
SELECT * FROM information_schema.storage_policy_modify_progress WHERE table_schema='<schema_name>' AND table_name='<table_name>';
返回值说明
参数 | 说明 |
参数 | 说明 |
table_schema | 数据库名。 |
table_name | 表名。 |
task_id | 执行冷热变更任务的ID。 |
source_storage_policy | 原存储策略。取值如下:
|
source_hot_partition_count | 原热分区数量。 |
dest_storage_policy | 目标存储策略。取值如下:
|
dest_hot_partition_count | 目标热分区数量。 |
hot_to_cold_partition_count | 热分区到冷分区变更的分区数量。 |
cold_to_hot_partition_count | 冷分区到热分区变更的分区数量。 |
hot_to_cold_data_size | 热分区到冷分区变更的数据量(单位:Byte)。 |
cold_to_hot_data_size | 冷分区到热分区变更的数据量(单位:Byte)。 |
hot_data_size_before_change | 变更前热数据量(单位:Byte)。 |
cold_data_size_before_change | 变更前冷数据量(单位:Byte)。 |
hot_data_size_after_change | 变更后热数据量(单位:Byte)。 |
cold_data_size_after_change | 变更后冷数据量(单位:Byte)。 |
start_time | 开始变更时间。 |
update_time | 结束变更时间。 |
progress | 变更进度(单位:百分比)。 |
status | 变更状态。取值如下:
|
- 本页导读 (1)
- 为什么要使用数据冷热分离
- 前提条件
- 费用说明
- 冷热存储策略
- 分区数量变更对冷热分区布局的影响
- 指定冷热存储策略
- 查询表的冷热存储策略
- 语法
- 返回值说明
- 查询表的冷热存储策略变更进度
- 语法
- 返回值说明