共计 10646 个字符,预计需要花费 27 分钟才能阅读完成。
论断后行
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 归档到 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
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 原文链接