首页云原生数据仓库AnalyticDB云原生数据仓库AnalyticDB MySQL版实践教程数据存储冷热分离
输入文档关键字查找

数据存储冷热分离

更新时间：2025-03-20 01:37
社区

云原生数据仓库 AnalyticDB MySQL 版数据冷热分离功能会将冷热数据分别存储在不同的介质上，在保证热数据查询性能的同时，降低冷数据的存储成本。

为什么要使用数据冷热分离

在海量大数据场景下，一张业务表中可能存储着大量的业务数据（例如日志数据、订单数据或监控数据）。随着时间的推移，部分数据的访问频率会逐渐降低，最终被搁置。但是这部分数据依旧会占用存储空间，导致存储成本增加。

AnalyticDB for MySQL数据冷热分离主要适用于按时间日期分区的表。集群会根据指定的热分区数量，按照分区的大小（分区键值的大小）降序排序，最大的N个分区为热分区，其余分区为冷分区。冷分区的数据会移动到成本更低的对象存储服务OSS中，降低存储成本；与此同时，热分区的数据仍然存储在SSD盘中，保证数据查询的高性能。

前提条件

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

费用说明

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

说明

支持使用存储资源包抵扣存储空间。

冷热存储策略

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

  • 全冷存储指数据全部存储在OSS中，采用同城冗余存储（多AZ），是一种较为经济的存储策略。

  • 全热存储指数据全部存储在SSD盘，满足高性能访问的需求，查询性能最好，但存储成本最高。

  • 冷热混合存储指热分区数据存储在SSD盘，冷分区数据存储在OSS。既保证热分区数据的查询性能，又节省冷分区数据的存储成本。其原理如下：

    冷热混合存储需指定热分区数。假设热分区数为N，在按照分区的大小（分区键值的大小）降序排序后，最大的N个分区为热分区，存储在SSD盘，其余分区为冷分区，存储在OSS中，形成冷热分区布局。冷热分区布局不是固定不变的，当分区数量变更时，会重新调整冷热分区布局。详细说明，请参见分区数量变更对冷热分区布局的影响。

image

分区数量变更对冷热分区布局的影响

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

    点击查看示意图

    如图所示，设置的热分区数为5，当新增分区20241226之后，20241226为当前最大的分区，在BUILD之后该分区需要放在热分区中，但是当前热分区数已满5，冷热存储策略会从热分区中选一个最小的分区20241221迁移到冷分区，并把20241226放在热分区中。

    image

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

    • 当热分区数增加，即M>N时，会从冷分区迁移M-N个分区数据到热分区。

      点击查看示意图

      如图所示，当前热分区数为5， 修改热分区数为6后，冷热存储策略会从冷分区迁移一个最大的分区20241220到热分区中。

      image

    • 当热分区数减少，即M<N时，会从热分区迁移N-M个分区数据到冷分区。

      点击查看示意图

      当前热分区数为5， 修改热分区数为4后，冷热存储策略会从热分区迁移一个最小的分区到冷分区中。

      image

指定冷热存储策略

  • 创建表时指定冷热存储策略：您可以在建表时通过storage_policy参数来指定表的冷热存储策略。

  • 为已有的表指定冷热存储策略：您可以通过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：全热存储。

  • 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）。

返回值注意事项：

  • 受到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。

  • 由于定义的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内的数据分布情况如下图。

    image

    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

原存储策略。取值如下：

  • 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：变更完成。

上一篇：表结构设计下一篇：数据变更最佳实践
  • 本页导读 （1）
  • 为什么要使用数据冷热分离
  • 前提条件
  • 费用说明
  • 冷热存储策略
  • 分区数量变更对冷热分区布局的影响
  • 指定冷热存储策略
  • 查询表的冷热存储策略
  • 语法
  • 返回值说明
  • 查询表的冷热存储策略变更进度
  • 语法
  • 返回值说明
文档反馈
phone 联系我们

立即和Alibaba Cloud在线服务人员进行交谈，获取您想了解的产品信息以及最新折扣。

alicare alicarealicarealicare