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