TiDB 6.0 实战分享丨冷热存储分离解决方案

结论先行

TiDB 6.0 正式提供了数据放置框架（Placement Rules in SQL ）功能，用户通过 SQL 配置数据在 TiKV 集群中的放置位置，可以对数据进行直接的管理，满足不同的业务场景需要。如：

1.冷热分离存储，降低存储成本

• TiDB 6.0 正式支持数据冷热存储分离，可以降低 SSD 使用成本。使用 TiDB 6.0 的数据放置功能，可以在同一个集群实现海量数据的冷热存储，将新的热数据存入 SSD，历史冷数据存入 HDD，降低历史归档数据存储成本。
  • 将热数据从 ssd 迁移到 hdd，每小时可归档约 3000 万行，总体来看效率还是比较高的
  • 将冷数据从 hdd 迁移到 ssd，每小时可迁移约 6300 万行，大约是从 ssd 迁移到 hdd 速度的 2 倍
  • 分离存储过程，ssd 和 hdd 用于归档的 IO 消耗都在 10%以内，集群访问 QPS 表现平稳，对业务访问的影响较小
  • 在补写冷数据场景，每小时写入约 1500 万行到 hdd，数据可正确地直接写入 hdd，不会经过 ssd

2.业务底层物理隔离，实现同一集群不同存储

• 通过放置规则管理将不同数据库下的数据调度到不同的硬件节点上，实现业务间数据的物理资源隔离，避免因资源争抢，硬件故障等问题造成的相互干扰
• 通过账号权限管理避免跨业务数据访问，提升数据质量和数据安全。

3.合并MySQL业务，降低运维压力，提升管理效率

• 使用少数 TiDB 集群替换大量的 MySQL 实例，根据不同业务底层设置不同的物理存储隔离需求，让数据库数量大大减少，原本的升级、备份、参数设置等日常运维工作将大幅缩减，在资源隔离和性价比上达到平衡，大幅减少 DBA 日常的运维管理成本。

我们的 HTAP 集群目前有一个数据归档需求，整个集群共约 330TB，考虑到成本和访问频率、性能等各方面需求，要求至少存储 3 个月共约 80TB 到 ssd，250TB 存到 hdd，现在基于我们的大数据冷热分离归档业务场景，本文重点探讨冷热数据归档存储的功能和特性，以方便下一步我们正式应用到生产环境。

概述

TiDB 集群通过 PD 节点（Placement Driver 组件）在系统内基于热点、存储容量等策略自动完成 region 的调度，从而实现集群数据均衡、分散存储在各个节点的目标，这些调度操作是集群的自身管理行为，对用户而已几乎是透明的，在之前的版本用户无法精确控制数据的存储方式和位置。

TiDB 6.0 正式提供了数据放置框架（Placement Rules in SQL ）功能，用户通过 SQL 配置数据在 TiKV 集群中的放置位置，可以对数据进行直接的管理，以满足不同的业务场景需要。用户可以将库、表和分区指定部署至不同的地域、机房、机柜、主机。还支持针对任意数据提供副本数、角色类型等维度的灵活调度管理能力，这使得在多业务共享集群、跨中心部署、冷热数据归档存储等场景下，TiDB 得以提供更灵活更强大的数据管理能力。

该功能可以实现以下业务场景：

• 动态指定重要数据的副本数，提高业务可用性和数据可靠性
• 将最新数据存入 SSD，历史数据存入 HDD，降低归档数据存储成本
• 把热点数据的 leader 放到高性能的 TiKV 实例上，提供高效访问
• 不同业务共用一个集群，而底层按业务实现存储物理隔离，互不干扰，极大提升业务稳定性
• 合并大量不同业务的 MySQL 实例到统一集群，底层实现存储隔离，减少管理大量数据库的成本

原理简介

早期版本的 Placement rule 使用时需要通过 pd-ctl 工具设置和查看，操作繁琐且晦涩难懂。经过几个版本的迭代和优化，推出的 PlacementRules in SQL 对用户更加友好，到了 v6.0.0 总体来说还是很方便理解和使用的，避免了使用 pd-ctl 工具配置的复杂性，大大降低使用门槛。

放置策略的实现依赖于 TiKV 集群 label 标签配置，需提前做好规划（设置 TiKV 的 labels）。可通过show placement labels查看当前集群所有可用的标签。

 mysql> show placement labels ;
 +------+-----------------------------------------------------------------+
 | Key  | Values                                                          |
 +------+-----------------------------------------------------------------+
 | disk | ["ssd"]                                                         |
 | host | ["tikv1", "tikv2", "tikv3"] |
 | rack | ["r1"]                                                          |
 | zone | ["guangzhou"]                                                   |
 +------+-----------------------------------------------------------------+
 4 rows in set (0.00 sec)
 

使用时有基础用法和高级用法两种方式。

(1) 基础放置策略

基础放置策略主要是控制 Raft leader 和 followers 的调度。

 #创建放置策略
 CREATE PLACEMENT POLICY myplacementpolicy PRIMARY_REGION="guangzhou" REGIONS="guangzhou,shenzhen";
 
 #将规则绑定至表或分区表，这样指定了放置规则
 CREATE TABLE t1 (a INT) PLACEMENT POLICY=myplacementpolicy;
 CREATE TABLE t2 (a INT);
 ALTER TABLE t2 PLACEMENT POLICY=myplacementpolicy;
 
 #查看放置规则的调度进度，所有绑定规则的对象都是异步调度的。
 SHOW PLACEMENT;
 
 #查看放置策略
 SHOW CREATE PLACEMENT POLICY myplacementpolicy\G
 select * from information_schema.placement_policies\G
 
 #修改放置策略，修改后会传播到所有绑定此放置策略的对象
 ALTER PLACEMENT POLICY myplacementpolicy FOLLOWERS=5;
 
 #删除没有绑定任何对象的放置策略
 DROP PLACEMENT POLICY myplacementpolicy;
 

(2) 高级放置策略

基础放置策略主要是针对 Raft leader 、Raft followers 的调度策略，如果需要更加灵活的方式，如不区分 region 角色将数据指定存储在 hdd，需要使用高级放置策略。使用高级放置策略主要有两个步骤，首先创建策略，然后在库、表或分区上应用策略。

 # 创建策略，指定数据只存储在ssd
 CREATE PLACEMENT POLICY storeonfastssd CONSTRAINTS="[+disk=ssd]";
 
 # 创建策略，指定数据只存储在hdd
 CREATE PLACEMENT POLICY storeonhdd CONSTRAINTS="[+disk=hdd]";
 
 # 在分区表应用高级放置策略，指定分区存储在hdd或者ssd上，未指定的分区由系统自动调度
 CREATE TABLE t1 (id INT, name VARCHAR(50), purchased DATE)
 PARTITION BY RANGE( YEAR(purchased) ) (
   PARTITION p0 VALUES LESS THAN (