根据业务的使用情况,AnalyticDB MySQL弹性模式集群版(新版)(3.1.3.3及以上版本)支持表或分区级别的冷热分离数据存储策略。
冷热数据的定义
冷数据指的是访问频次较低的数据,采用低价的HDD存储,满足存储空间的需求。
热数据指的是访问频次较高的数据,采用SSD存储,满足高性能访问的需求。
您可以执行CREATE TABLE语句指定表的冷热存储策略为:全热存储(数据全部存储在SSD)、全冷存储(数据全部存储在HDD)、冷热混合存储(指定一定数量的分区存储在SSD,其余数据存储在HDD)。更多信息可参见CREATE TABLE。

冷热数据的迁移
数据入库开始是在RealTime引擎,经过build会应用冷热存储策略,将数据分为冷、热两部分。其中冷数据放在HDD存储,热数据放在SSD存储。
冷热分区布局会按照分区值N的大小降序排列,最大的N个分区为热分区,存储在SSD,其余分区为冷分区,存储在HDD。N的值可以在指定冷热存储策略时定义,更多信息可参见CREATE TABLE。
- 当数据有新增,修改,删除时,会重新调整冷热分区布局。
- 当调整冷热策略时,会重新调整冷热分区布局。您可以执行ALTER TABLE语句修改表的冷热存储策略,更多信息可参见ALTER TABLE。
- 冷到热的迁移
- 当前热分区数为N,修改热分区的数量M,当N<M时,会从冷分区迁移M-N个分区数据到热分区。
如图所示,当前热分区数为5, 修改热分区数为6后,5<6,所以需要从冷分区迁移一个最大的分区,即20201104到热分区中。
- 热到冷的迁移
- 当有新的分区数据写入,对所有分区排序,超过N的旧数据会迁移到冷分区;当前热分区数为N,修改热分区的数量M,当N>M时,会从热分区迁移N-M个分区数据到冷分区。
如图所示,当新增分区20201110之后,20201110为当前最大的分区,应该放在热分区中,但是当前热分区数已满5,所以需要从热分区中选一个最小的分区20201105迁移到冷分区,并把20201110放在热分区中。
冷热数据存储诊断表
- 查询冷热存储布局
- 用户可以通过查询表table_usage,来查看当前的冷热数据存储情况。具体使用方式如下:
- 查询所有表的存储状态:
select * from information_schema.table_usage
- 查询单个表的存储状态:
select * from information_schema.table_usage where table_schema='$schema_name' and table_name='$table_name'
table_usage表字段信息:字段名 字段含义描述 table_schema 数据库名 table_name 表名 storage_policy 当前存储策略 - HOT:全热表
- COLD:全冷表
- MIXED:混合表
hot_partition_count 当前存储的热分区数量 cold_partition_count 当前存储的冷分区数 rt_total_size 实时数据总大小(单位为bytes),是rt_data_size和rt_index_size的总和 rt_data_size 实时数据大小(单位为bytes) rt_index_size 实时数据的主键大小(单位为bytes) hot_total_size 热分区总数据量(单位为bytes),是hot_data_size和hot_index_size的总和 hot_data_size 热分区数据大小(单位为bytes) hot_index_size 热分区数据的主键和索引大小(单位为bytes) cold_total_size 冷分区总数据量(单位为bytes),是cold_data_size和cold_index_size的总和 cold_data_size 冷分区数据大小(单位为bytes) cold_index_size 冷分区数据的主键和索引大小(单位为bytes) table_usage表说明:- 如果加载数据之后hot_total_size和cold_total_size都为0,则表示数据还在realtime中,rt_total_size为实际数据的存储,可以通过执行build 指令,将realtime数据转换为分区数据,待build完成后可以看到hot_total_size和cold_total_size的显示。
build指令:
build table $table_name
- 由于用户定义的hot_partition_count是单个shard内二级分区的热分区存储情况。而这里的hot_partition_count是按照shard union之后的结果,在各shard内分区数据不一致的情况下,可能会出现实际显示的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。
- table_usage是实时更新的,随着insert/update/delete/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会实时变动。
- 查询所有表的存储状态:
- 查询冷热变更进度
- 用户可以通过执行
ALTER TABLE
语句修改表的冷热存储策略(详细信息请参见ALTER TABLE):- 查询当前集群中所有参与变更的表的进度:
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'
storage_policy_modify_progress表字段信息:字段名 字段含义描述 table_schema 数据库名 table_name 表名 task_id 执行冷热变更任务的ID source_storage_policy 原存储策略 - HOT:全热表
- COLD:全冷表
- MIXED:混合表
source_hot_partition_count 原热分区数量 dest_storage_policy 目标存储策略 - HOT:全热表
- COLD:全冷表
- MIXED:混合表
dest_hot_partition_count 目标热分区数量 hot_to_cold_partition_count 热到冷变更的分区数量 cold_to_hot_partition_count 冷到热变更的分区数量 hot_to_cold_data_size 热到冷变更的数据量(单位:bytes) cold_to_hot_data_size 冷到热变更的数据量(单位:bytes) hot_data_size_before_change 变更前热数据量(单位:bytes) cold_data_size_before_change 变更前冷数据量(单位:bytes) hot_data_size_after_change 变更后热数据量(单位:bytes) cold_data_size_after_change 变更后冷数据量(单位:bytes) start_time 开始变更时间 update_time 结束变更时间 progress 变更进度(单位:百分比) status 变更状态 - INIT:还未开始进行变更
- RUNNING:正在进行变更
- FINISH:变更完成
- 查询当前集群中所有参与变更的表的进度:
在文档使用中是否遇到以下问题
更多建议
匿名提交