冷热分离数据存储 - 云原生数仓 AnalyticDB MySQL

冷热数据的定义

冷数据指的是访问频次较低的数据，采用低价的HDD存储，满足存储空间的需求。

热数据指的是访问频次较高的数据，采用SSD存储，满足高性能访问的需求。

您可以执行CREATE TABLE语句指定表的冷热存储策略为：全热存储（数据全部存储在SSD）、全冷存储（数据全部存储在HDD）、冷热混合存储（指定一定数量的分区存储在SSD，其余数据存储在HDD）。更多信息可参见CREATE TABLE。

数据入库开始是在RealTime引擎，经过build会应用冷热存储策略，将数据分为冷、热两部分。其中冷数据放在HDD存储，热数据放在SSD存储。

冷热分区布局会按照分区值N的大小降序排列，最大的N个分区为热分区，存储在SSD，其余分区为冷分区，存储在HDD。N的值可以在指定冷热存储策略时定义，更多信息可参见CREATE TABLE。

冷到热的迁移: 当前热分区数为N，修改热分区的数量M，当N<M时，会从冷分区迁移M-N个分区数据到热分区。
如图所示，当前热分区数为5，修改热分区数为6后，5<6，所以需要从冷分区迁移一个最大的分区，即20201104到热分区中。
热到冷的迁移: 当有新的分区数据写入，对所有分区排序，超过N的旧数据会迁移到冷分区；当前热分区数为N，修改热分区的数量M，当N>M时，会从热分区迁移N-M个分区数据到冷分区。
如图所示，当新增分区20201110之后，20201110为当前最大的分区，应该放在热分区中，但是当前热分区数已满5，所以需要从热分区中选一个最小的分区20201105迁移到冷分区，并把20201110放在热分区中。

AnalyticDB MySQL弹性模式集群版（3.1.3.5及以上版本）支持数据的冷热分离存储，用户可以通过查表的方式查询某一张表的冷热数据存储布局情况。如果执行了冷热策略变更语句，也可以通过查表的方式查询当前冷热变更的进度。

查询冷热存储布局

用户可以通过查询表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：变更完成