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

前提条件

AnalyticDB MySQL版集群需要同时满足以下条件：

集群系列需为弹性模式集群版（新版）。
集群内核版本需为3.1.3.3或以上。
说明
- 如何查看集群版本，请参见查看版本。
- 如需升级版本请提交工单并提供可升级的时间。升级版本耗时约20分钟。升级期间，您的实例仍可以正常运行，但由于升级过程中会伴随几次闪断，建议您在业务低峰期升级，或确保您的应用有自动重连机制。

AnalyticDB MySQL版的数据存储冷热分离策略分为全冷存储、全热存储、冷热混合存储。

在执行CREATE TABLE时，您可以通过storage_policy参数来指定表的数据存储冷热分离策略。

对于已有的表，可以通过ALTER TABLE table_name storage_policy;修改表的冷热存储策略。详情请参见更改表的冷热数据存储策略。

冷热混合存储需要首先指定热分区数。您可以通过hot_partition_count参数来指定热分区数。如何通过hot_partition_count设置热分区数，请参见CREATE TABLE。

假设热分区数为N，数据存储冷热分离策略会按照分区的大小（指定分区列数据的数据值大小）降序排序，最大的N个分区为热分区，存储在SSD盘，其余分区为冷分区，存储在HDD盘，形成冷热分区布局。

例如热分区数为4，分区包含20201110、20201109、20201108、20201107、20201106、20201105和20201104，数据存储冷热分离策略会将最大的4个分区20201110、20201109、20201108和20201107指定为热分区，剩余分区为冷分区。

冷热分区布局不是固定不变的。以下情况会影响冷热分区布局：

当有新的分区数据写入时，数据存储冷热分离策略会对所有分区重新排序，超过N的旧数据会迁移到冷分区。

如图所示，当新增分区20201110之后，20201110为当前最大的分区，应该放在热分区中，但是当前热分区数已满5，数据存储冷热分离策略会从热分区中选一个最小的分区20201105迁移到冷分区，并把20201110放在热分区中。热冷迁移

当前热分区数为N，修改热分区的数量为M。

当热分区数增加，即M>N时，会从冷分区迁移M-N个分区数据到热分区。
如图所示，当前热分区数为5，修改热分区数为6后，数据存储冷热分离策略会从冷分区迁移一个最大的分区20201104到热分区中。
当热分区数减少，即M<N时，会从热分区迁移N-M个分区数据到冷分区。
例如，当前热分区数为5，修改热分区数为4后，数据存储冷热分离策略会从热分区迁移一个最小的分区到冷分区中。

您可以通过查询表 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	实时数据总量（单位：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）

table_usage表说明：

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会实时变动。
如果加载数据之后hot_total_size和cold_total_size都为0，则表示数据还在实时中，rt_total_size为实时数据的存储，可以通过执行build语句，将实时数据转换为分区数据，待build完成后可以查到hot_total_size和cold_total_size。
build指令：
```
build table <table_name>
```
由于用户定义的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语句修改表的数据存储冷热分离策略，详细信息请参见 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>'

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	热到冷变更的数据量（单位：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	变更状态 INIT：未开始变更 RUNNING：正在进行变更 FINISH：变更完成