定论先行

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 数和空间运用在不断增长

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

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

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

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

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 有较大差距,在这里能够了解为是正在处于调度的进程。

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

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

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

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

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

定论:

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

静态集群冷热存储别离(无外部拜访)

ssd->hdd

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

 alter table tidb_ssd_hdd_test.logoutrole_log partition p20220417 placement policy storeonhdd;

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

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 节点;

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

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

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

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

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

定论:

  • 将冷数据从 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 不变。

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

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

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

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

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

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

定论:

  • 在有外部几乎是满 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 运用率比较低。

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

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

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

定论:

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

同一集群事务阻隔

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

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

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

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

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 放置战略