关于数据库:TiDB-冷热存储分离解决方案

论断后行

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 );

高级搁置策略具体内容，请看官网介绍https://docs.pingcap.com/zh/t...。

环境

角色	机器数	内存	数据盘	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归档到hddalter 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

0. 将集群降级到6.0.0版本1. 创立默认SSD策略2. 关上搁置策略默认开关，使得集群已有库表都默认存储在ssd上 （该性能依赖官网公布新版本反对）- 目前只能用脚本alter全副库设置这个默认策略，如果有新增的库也须要提前进行设置3. 申请新机器并扩容新的 hdd tikv  4. 创立 hdd 搁置策略5. 在指标表的指标分区上指定 ssd或hdd 策略6. 定期将过期分区申明hhd搁置策略

对新建的集群利用Placement Rules

0. 部署6.0.0集群版本1. 创立默认SSD策略2. 创立的全副库都先设置这个默认策略3. 申请新机器并扩容新的 hdd tikv  4. 创立hdd搁置策略5. 在指标表或指标分区上指定ssd或hdd 策略6. 定期将过期分区申明hhd搁置策略

原作者：@Jellybean 原文链接