文档

数据存储冷热分离

更新时间:

AnalyticDB for MySQL弹性模式集群版(新版)(3.1.3.3及以上版本)支持表或分区级别的数据存储冷热分离策略。

前提条件

AnalyticDB for MySQL集群需要同时满足以下条件:

  • 集群系列需为弹性模式集群版(新版)

  • 集群内核版本需为3.1.3.3或以上。

    说明
    • 如何查看集群版本,请参见查看版本

    • 如需升级版本请提交工单并提供可升级的时间。升级版本耗时约20分钟。升级期间,您的集群仍可以正常运行,但升级过程中会出现闪断,建议您在业务低峰期升级,或确保您的应用有自动重连机制。

费用说明

集群在使用过程中,存储热数据和冷数据占用的存储空间会按量收费。详情请参见数仓版计费项数仓版产品定价

说明

包年包月集群可以购买存储资源包来抵扣热数据存储空间和冷数据存储空间。超出存储资源包的部分按量付费。详情请参见存储资源包

存储策略

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

  • 全冷存储指数据全部存储在OSS中,是一种较为经济的存储策略。

  • 全热存储指数据全部存储在SSD盘,满足高性能访问的需求。

  • 冷热混合存储指一定数量的分区存储在SSD盘,其余数据存储在OSS中。

image.png

指定冷热存储策略

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

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

冷热混合存储原理

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

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

例如热分区数为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;
  • 查询单个表的冷热数据存储情况:

    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_sizert_index_size的总和。

rt_data_size

实时数据量(单位:Byte)。

rt_index_size

实时数据的主键和索引大小(单位:Byte)。

hot_total_size

热分区总数据量(单位:Byte),是hot_data_sizehot_index_size的总和。

hot_data_size

热分区的数据量(单位:Byte)。

hot_index_size

热分区数据的主键和索引大小(单位:Byte)。

cold_total_size

冷分区总数据量(单位:Byte),是cold_data_sizecold_index_size的总和。

cold_data_size

冷分区的数据量(单位:Byte)。

cold_index_size

冷分区数据的主键和索引大小(单位:Byte)。

table_usage表说明:

  • table_usage是实时更新的,随着insert/update/delete/build的执行,rt_total_sizert_data_sizert_index_sizehot_total_sizehot_data_sizehot_index_sizecold_total_sizecold_data_sizecold_index_size会实时变动。

  • 如果加载数据之后hot_total_sizecold_total_size都为0,则表示数据还在实时中,rt_total_size为实时数据的存储,可以通过执行build语句,将实时数据转换为分区数据,待build完成后可以查到hot_total_sizecold_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内的数据分布情况如下图。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:变更完成。