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 (2000) PLACEMENT POLICY=storeonhdd,
   PARTITION p1 VALUES LESS THAN (2005),
   PARTITION p2 VALUES LESS THAN (2010),
   PARTITION p3 VALUES LESS THAN (2015),
   PARTITION p4 VALUES LESS THAN MAXVALUE PLACEMENT POLICY=storeonfastssd
 );

高档放置战略具体内容，请看官网介绍docs.pingcap.com/zh/tidb/sta…。

环境

人物	机器数	内存	数据盘	CPU	OS
TiDB&TiPD	3	256G	1TB hdd	40 cpu (20 core*2 thread)	Debian 4.19.208-1 (2021-09-29) x86_64 GNU/Linux
TiKV	3	256G	800GB ssd，1TB hdd	40 cpu (20 core*2 thread)	Debian 4.19.208-1 (2021-09-29) x86_64 GNU/Linux

冷热归档存储

方针：对给定的表按日期分区，将最新分区的数据存入 SSD，前史数据存入 HDD

功用验证

1.布置集群并树立放置战略

布置 TiDB v6.0.0 集群，具体参阅布置集群操作

创立数据落盘战略，以备运用

 # 运用该战略的库、表、分区，数据会存储在ssd上
 CREATE PLACEMENT POLICY storeonssd CONSTRAINTS="[+disk=ssd]" ;
 # 运用该战略的库、表、分区，数据会存储在hdd上
 CREATE PLACEMENT POLICY storeonhdd CONSTRAINTS="[+disk=hdd]";
 #检查集群已有战略
 mysql> show placement \G
 *************************** 1. row ***************************
           Target: POLICY storeonhdd
        Placement: CONSTRAINTS="[+disk=hdd]"
 Scheduling_State: NULL
 *************************** 2. row ***************************
           Target: POLICY storeonssd
        Placement: CONSTRAINTS="[+disk=ssd]"
 Scheduling_State: NULL
 2 rows in set (0.02 sec)

2.创立库表并应有放置战略

树立方针表为TiDB分区表并且按 Range 分区。

 # 创立数据库tidb_ssd_hdd_test，并设置该库默许落盘战略，设置后新建的表都会默许继承该战略
 create database tidb_ssd_hdd_test  PLACEMENT POLICY=storeonssd;
 # 检查战略现已运用到指定库上
 mysql> show placement \G
 *************************** 1. row ***************************
           Target: POLICY storeonhdd
        Placement: CONSTRAINTS="[+disk=hdd]"
 Scheduling_State: NULL
 *************************** 2. row ***************************
           Target: POLICY storeonssd
        Placement: CONSTRAINTS="[+disk=ssd]"
 Scheduling_State: NULL
 *************************** 3. row ***************************
           Target: DATABASE tidb_ssd_hdd_test
        Placement: CONSTRAINTS="[+disk=ssd]"
 Scheduling_State: SCHEDULED
 3 rows in set (0.02 sec)
 # 树立分区表，能够看到表树立后默许继承和库一样的落盘战略，要害标识为“/*T![placement] PLACEMENT POLICY=`storeonssd` */”
 CREATE TABLE `logoutrole_log ` (
   `doc_id` varchar(255) NOT NULL,
   `gameid` varchar(255) DEFAULT NULL ,
   -- some fields
   `logdt` timestamp DEFAULT '1970-01-01 08:00:00' ,
   `updatetime` varchar(255) DEFAULT NULL ,
   UNIQUE KEY `doc_id` (`doc_id`,`logdt`),
   -- some index
   KEY `logdt_gameid` (`logdt`,`gameid`)
 ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_bin /*T![placement] PLACEMENT POLICY=`storeonssd` */
 PARTITION BY RANGE ( UNIX_TIMESTAMP(`logdt`) ) (
   PARTITION `p20220416` VALUES LESS THAN (UNIX_TIMESTAMP('2022-04-17 00:00:00')),
   PARTITION `p20220417` VALUES LESS THAN (UNIX_TIMESTAMP('2022-04-18 00:00:00')),
   PARTITION `p20220418` VALUES LESS THAN (UNIX_TIMESTAMP('2022-04-19 00:00:00')),
   PARTITION `p20220419` VALUES LESS THAN (UNIX_TIMESTAMP('2022-04-20 00:00:00')),
   PARTITION `p20220420` VALUES LESS THAN (UNIX_TIMESTAMP('2022-04-21 00:00:00')),
   PARTITION `p20220421` VALUES LESS THAN (UNIX_TIMESTAMP('2022-04-22 00:00:00')),
   PARTITION `p20220422` VALUES LESS THAN (UNIX_TIMESTAMP('2022-04-23 00:00:00'))
 );

3.写入热数据到 ssd 盘并扩容 hdd 存储节点

集群只有 3 个 ssd 的 tikv 节点，发动 flink 流往方针表导入数据，能够看到这 3 个 ssd 节点的 region 数和空间运用在不断增长

在原有基础上再扩容 3 个 hdd tikv 实例

4.冷热别离

为了便利模仿数据的搬迁，flink 导入的数据是悉数落在 2022-04-16 这一天：

 mysql> select date(logdt) as day,count(0) from logoutrole_log group by day order by day ;
 +------------+----------+
 | day        | count(0) |
 +------------+----------+
 | 2022-04-16 |  1109819 |
 +------------+----------+
 1 row in set (1.09 sec)

中止 Flink 写入后，设置数据别离放置战略，将存储在 ssd 上的 2022-04-16 这一天的数据，转存到 hdd 上，模仿冷数据归档操作：

 mysql> alter table tidb_ssd_hdd_test.logoutrole_log partition p20220416 placement policy storeonhdd;
 Query OK, 0 rows affected (0.52 sec)

在运用 hdd 转存战略后，如下图能够看到调度规矩里 2022-04-16 这一天的分区 Placement 由 ssd 变为了 hdd，即集群现已知晓最新的调度战略是将这一天的分区数据调度到 hdd 去，Scheduling_State 处于 PENDING 状况，表明 Follower 的 raft log 与 Leader 有较大差距，在这里能够了解为是正在处于调度的进程。

跟着时刻的推移，数据在不断从 ssd 搬迁到 hdd 上。从集群 grafana 监控面板能够看到 ssd 节点上的 region 数据在不断下降，直到降到接近于 0；相反，hdd 上的 region 数不断上升，直到数据悉数迁出 ssd 节点。110 万行数据从 ssd 搬迁到 hdd，大约耗时 3min 。

在数据悉数迁如 hdd 节点后，检查调度进展，此刻 Scheduling_State 处于 SCHEDULED 完结调度状况：

定论：

证明冷热数据阻隔存储战略现已生效，ssd 上的数据完结搬迁到 hdd 上，且 ssd 的空间得以开释，契合数据归档的方针。

静态集群冷热存储别离（无外部拜访）

ssd->hdd

继续经过 flink 写入数据到 2022-04-17 分区，然后停流使集群没有外部拜访流量，将此分区上 ssd 数据搬迁到 hdd。

 alter table tidb_ssd_hdd_test.logoutrole_log partition p20220417 placement policy storeonhdd;

ssd 上的 region 悉数搬迁到 hdd 上，ssd 空间被开释，hdd 空间运用逐步添加，搬迁进程中 ssd 和 hdd 的 IO 耗费都在 5%左右，内存和网络带宽运用不变、坚持平稳。约 6 千万行 130GB 数据从 ssd 数据搬迁到 hdd 大概需求 2 个小时

定论：

在将大规划数据从 ssd 数据搬迁到 hdd 进程，集群资源耗费比较低，能够有效防止过多占用集群资源。
在集群没有外部拜访压力时，在默许装备下，集群以每小时约 3000 万行的速度从 ssd 搬迁到 hdd 节点。

hdd->ssd

在没有外部流量拜访时，将数据从 hdd 搬迁回 ssd，从监控图能够看到，hdd 节点的 tikv 的 leader 数、region 数在此期间都在下降，分别从 850、2500 逐步下降直到为 0，磁盘空间也从 62GB 下降为 0，表明数据在继续搬迁出 hdd 节点；

相反地，由于数据不断迁入到 ssd 中，ssd 节点的 tikv 的 leader 数、region 数在此期间都在上升，分别从 1500、4200 逐步上升到 2200、6700，直到数据迁入完结，然后坚持数量不变，ssd 的磁盘空间耗费也从 100GB 上升到 161GB。

搬迁的进程中，ssd 和 hdd 节点的 IO 运用率都比较低，如下图：

定论：

将冷数据从 hdd 搬迁至 ssd，搬迁 1.7 亿行共约 200GB 数据，大约耗时 2 小时 40 分钟，均匀每小时搬迁 6300 万行，速度约为将热数据从 ssd 迁到 hdd 的 2 倍（每小时约 3000 万行）
将数据从 hdd 搬迁至 ssd 的进程，不管是对 ssd 仍是 hdd，其均匀 IO 运用率都不高，不会占用过多集群的资源，能够以为数据搬迁进程对集群正在运行的事务影响不大

热集群冷热存储别离（外部继续拜访）

继续继续写入数据到 2022-04-18 和 2022-04-19 的 ssd 分区，然后不停流坚持继续的写入压力，搬迁 2022-04-18 数据从 ssd 到 hdd，调查集群体现。

#运用放置战略将2022-04-18数据从ssd归档到hdd
alter table tidb_ssd_hdd_test.logoutrole_log partition p20220418 placement policy storeonhdd;

在归档进程，flink 同时继续以 2100 的 QPS 写入热数据，期间 ssd IO 接近 100%，hdd 的 IO 耗费在 10%以下，各节点 CPU 在 500%以下，网络带宽在 200MB/s 以下，内存运用坚持平稳。

从 region 数改变的视点来看：

在归档数据时，ssd 的 tikv region 数从 6300 下降到 3500 左右，当搬迁完结后是净写入数据，此刻 ssd 节点的 region 数量又继续上升；
hdd 节点的 region 数从开始的 2600 上升到 6500 左右，跟着数据搬迁完结，hdd 的 region 数不再添加，一直坚持 6500 不变。

从磁盘运用空间改变的视点来看：

归档数据时，ssd 节点的磁盘运用空间从 152GB 下降到 88GB，当搬迁完结后，此刻是净写入数据，ssd 空间开始上升；
数据在不断写入到 hdd 节点，所以其运用空间从 61GB 上升到 154GB，跟着数据搬迁完结，一直坚持不变

定论：

在有外部几乎是满 IO 的写入压力时，归档约 2 亿行、400GB 数据从 ssd 到 hdd 节点，大概需求 6 个小时，即约 3300 万行/小时，能够说冷数据的归档功率仍是比较高的
集群后台在进行数据归档时，flink 的 sink QPS 改变不大，能够以为归档的进程对集群正常写入影响不大

归档数据补写

事务上有补全前史数据的场景，比方数据重算等，这里模仿补全前史冷数据，写入到 hdd。

2022-04-16 这一天的数据现已悉数转存到 hdd 冷盘中。发动 flink 流，继续对 2022-04-16 分区写入数据，这些只会写 hdd，不会写入 ssd。flink 流以 2000 左右的 sink QPS 补全冷数据，hdd tikv 节点 IO 打满，SSD 的 IO 运用率比较低。

从下图能够看到，在补全冷数据的时分， hdd 节点的 region 数在不断上升，hdd tikv 的空间耗费也在不断添加，而 ssd 的空间运用和 region 数均坚持不变，阐明数据并不会写入 ssd 中，契合预期。

定论：

阐明 TiDB 冷热数据别离存储功用，在补全前史冷数据的场景，即归档数据补写，数据能够正确地直接写入到 hdd，期间数据不会经过 ssd
补全冷数据，hdd tikv 节点 IO 打满，ssd 的 IO 运用率比较低，也阐明数据不会经过 ssd

同一集群事务阻隔

除了冷热数据归档外，咱们线上不同的事务线通常采用一套或多套 MySQL 来办理，但由于事务多导致 MySQL 有数百个，日常的监控、确诊、版别晋级、安全防护等作业对运维团队形成了巨大的压力，且跟着事务规划越来越大，办理的本钱不断上升。

运用 Placement rule 功用能够很简单灵敏的集群同享规矩。能够将不同 MySQL 上的事务搬迁到同一个 TiDB 集群，完结多个不同事务的共用一个集群而底层供给物理存储阻隔，有效削减很多 MySQL 的办理本钱。这个也是咱们接下来会继续推动优化的当地。

举例阐明，事务 A和B 同享资源，下降存储和办理本钱，而事务 C 和 D 独占资源，供给最高的阻隔性。由于多个事务同享一套 TiDB 集群，晋级、打补丁、备份计划、扩缩容等日常运维办理频率能够大幅减缩，下降办理负担提高功率。

CREATE PLACEMENT POLICY 'shared_nodes' CONSTRAINTS = "[+region=shared_nodes]";
CREATE PLACEMENT POLICY 'business_c' CONSTRAINTS = "[+region=business_c]";
CREATE PLACEMENT POLICY 'business_d' CONSTRAINTS = "[+region=business_d]";
ALTER DATABASE a POLICY=shared_nodes;
ALTER DATABASE b POLICY=shared_nodes;
ALTER DATABASE c POLICY=business_c;
ALTER DATABASE d POLICY=business_d;

依据 SQL 接口的数据放置规矩，你只是运用少量 TiDB 集群办理很多的 MySQL 实例，不同事务的数据放置到不同的 DB，并经过放置规矩办理将不同 DB 下的数据调度到不同的硬件节点上，**完结事务间数据的物理资源阻隔，防止因资源争抢，硬件毛病等问题形成的彼此搅扰。**经过账号权限办理防止跨事务数据拜访，提高数据质量和数据安全。在这种布置方法下，集群数量大大减小，本来的晋级，监控告警设置等日常运维作业将大幅减缩，在资源阻隔和性价比上达到平衡，大幅削减日常的 DBA 运维办理本钱。

总结

1.冷热别离存储，下降存储本钱

TiDB 6.0 正式支撑数据冷热存储别离，能够下降 SSD 运用本钱。运用 TiDB 6.0 的数据放置功用，能够在同一个集群完结海量数据的冷热存储，将新的热数据存入 SSD，前史冷数据存入 HDD，下降前史归档数据存储本钱。
- 将热数据从 ssd 搬迁到 hdd，每小时可归档约 3000 万行，整体来看功率仍是比较高的
- 别离存储进程，ssd 和 hdd 用于归档的 IO 耗费都在 10%以内，集群拜访 QPS 体现平稳，对事务拜访的影响较小
- 在补写冷数据到 hdd 场景，数据可正确地直接写入 hdd，不会经过 ssd。flink 补写冷数据时满 IO 每秒写入约 4000 行，每小时写入约 1500 万行。

2.事务底层物理阻隔，完结同一集群不同存储

经过放置规矩办理将不同数据库下的数据调度到不同的硬件节点上，完结事务间数据的物理资源阻隔，防止因资源争抢，硬件毛病等问题形成的彼此搅扰
经过账号权限办理防止跨事务数据拜访，提高数据质量和数据安全。

3.合并MySQL事务，下降运维压力，提高办理功率

运用少量 TiDB 集群替换很多的 MySQL 实例，依据不同事务底层设置不同的物理存储阻隔需求，让数据库数量大大削减，本来的晋级、备份、参数设置等日常运维作业将大幅减缩，在资源阻隔和性价比上达到平衡，大幅削减 DBA 日常的运维办理本钱。

4.放置战略运用操作进程

对已有集群运用 Placement Rules
1. 将集群晋级到 6.0.0 版别
2. 创立默许 SSD 战略
3. 翻开放置战略默许开关，使得集群已有库表都默许存储在 ssd 上（该功用依赖官方发布新版别支撑）
4. 现在只能用脚本 alter 悉数库设置这个默许战略，如果有新增的库也需求提早进行设置
5. 申请新机器并扩容新的 hdd tikv
6. 创立 hdd 放置战略
7. 在方针表的方针分区上指定 ssd 或 hdd 战略
8. 定时将过期分区声明 hhd 放置战略
对新建的集群运用 Placement Rules
1. 布置 6.0.0 集群版别
2. 创立默许 SSD 战略
3. 创立的悉数库都先设置这个默许战略
4. 申请新机器并扩容新的 hdd tikv
5. 创立 hdd 放置战略
6. 在方针表或方针分区上指定 ssd 或 hdd 战略
7. 定时将过期分区声明 hhd 放置战略

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

定论先行

1.冷热别离存储，下降存储本钱

2.事务底层物理阻隔，完结同一集群不同存储

3.合并MySQL事务，下降运维压力，提高办理功率

概述

原理简介

环境

冷热归档存储

功用验证

静态集群冷热存储别离（无外部拜访）

ssd->hdd

hdd->ssd

热集群冷热存储别离（外部继续拜访）

归档数据补写

同一集群事务阻隔

总结

1.冷热别离存储，下降存储本钱

2.事务底层物理阻隔，完结同一集群不同存储

3.合并MySQL事务，下降运维压力，提高办理功率

4.放置战略运用操作进程

相关文章

雨打西窗，再见那年夏天的暴雨⛈️！用js实现（源码+npm）

iOS 闪退、崩溃、crash

Jetpack Compose(二)-Modifier修饰符

基于原型的继承模式

作者信息