TiDB 6.0 实战分享丨冷热存储分离解决方案
TiDB 6.0 以 SQL 形式对用户暴露数据调度框架(Placement Rule In SQL),使得 TiDB 在多中心,冷热数据分离和大量写入所需的缓冲隔离等场景下也能够提供灵活的应对。本文将基于大数据冷热分离归档业务场景,重点探讨冷热数据归档存储的功能和特性,以便其在大规模 HTAP 集群归档中的实践应用。
作者简介:李文杰,网易游戏计费 TiDB 负责人,TUG 核心成员,TUG 2019 年和 2020 年 MVA。
结论先行
1. 冷热分离存储,降低存储成本
将热数据从 ssd 迁移到 hdd,每小时可归档约 3000 万行,总体来看效率还是比较高的;
将冷数据从 hdd 迁移到 ssd,每小时可迁移约 6300 万行,大约是从 ssd 迁移到 hdd 速度的 2 倍;
分离存储过程,ssd 和 hdd 用于归档的 IO 消耗都在 10%以内,集群访问 QPS 表现平稳,对业务访问的影响较小;
在补写冷数据场景,每小时写入约 1500 万行到 hdd,数据可正确地直接写入 hdd,不会经过 ssd。
2. 业务底层物理隔离,实现同一集群不同存储
通过放置规则管理将不同数据库下的数据调度到不同的硬件节点上,实现业务间数据的物理资源隔离,避免因资源争抢,硬件故障等问题造成的相互干扰;
通过账号权限管理避免跨业务数据访问,提升数据质量和数据安全。
3. 合并 MySQL 业务,降低运维压力,提升管理效率
概述
动态指定重要数据的副本数,提高业务可用性和数据可靠性;
将最新数据存入 ssd,历史数据存入 hdd,降低归档数据存储成本;
把热点数据的 leader 放到高性能的 TiKV 实例上,提供高效访问;
不同业务共用一个集群,而底层按业务实现存储物理隔离,互不干扰,极大提升业务稳定性;
合并大量不同业务的 MySQL 实例到统一集群,底层实现存储隔离,减少管理大量数据库的成本。
原理简介
mysql> show placement labels ;
+------+-----------------------------------------------------------------+
| Key | Values |
+------+-----------------------------------------------------------------+
| disk | ["ssd"] |
| host | ["tikv1", "tikv2", "tikv3"] |
| rack | ["r1"] |
| zone | ["guangzhou"] |
+------+-----------------------------------------------------------------+
4 rows in set (0.00 sec)
(1) 基础放置策略
#创建放置策略
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) 高级放置策略
# 创建策略,指定数据只存储在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
);
环境
冷热归档存储
功能验证
部署 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)
# 创建数据库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 的 TiKV 节点,启动 Flink 流往目标表导入数据,可以看到这 3 个 ssd 节点的 region 数和空间使用在不断增长
在原有基础上再扩容 3 个 hdd TiKV 实例
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)
mysql> alter table tidb_ssd_hdd_test.logoutrole_log partition p20220416 placement policy storeonhdd;
Query OK, 0 rows affected (0.52 sec)
静态集群冷热存储分离(无外部访问)
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,迁移 1.7 亿行共约 200GB 数据,大约耗时 2 小时 40 分钟,平均每小时迁移 6300 万行,速度约为将热数据从 ssd 迁到 hdd 的 2 倍(每小时约 3000 万行)。
将数据从 hdd 迁移至 ssd 的过程,不管是对 ssd 还是 hdd,其平均 IO 使用率都不高,不会占用过多集群的资源,可以认为数据迁移过程对集群正在运行的业务影响不大。
热集群冷热存储分离(外部持续访问)
#应用放置策略将2022-04-18数据从ssd归档到hdd
alter table tidb_ssd_hdd_test.logoutrole_log partition p20220418 placement policy storeonhdd;
在归档数据时,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 变化不大,可以认为归档的过程对集群正常写入影响不大。
归档数据补写
说明 TiDB 冷热数据分离存储功能,在补全历史冷数据的场景,即归档数据补写,数据可以正确地直接写入到 hdd,期间数据不会经过 ssd;
补全冷数据,hdd TiKV 节点 IO 打满,ssd 的 IO 使用率比较低,也说明数据不会经过 ssd。
同一集群业务隔离
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;
总结
对已有集群应用 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 放置策略
活动预告
新发布的 TiDB 6.0 大幅增强了 TiDB 作为企业级产品的可管理性,具备更成熟的 HTAP 与容灾能力,加入多项云原生数据库所需的基础特性。抢先试用 TiDB 6.0、TiFlash、TiEM 和 PingCAP Clinic 等多款新品与服务,参与 Book Rush 贡献,将有机会享受 “TiDB 荣誉体验官” 在内的多项权益!
扫描下方二维码了解详情
关注公众号:拾黑(shiheibook)了解更多
[广告]赞助链接:
四季很好,只要有你,文娱排行榜:https://www.yaopaiming.com/
让资讯触达的更精准有趣:https://www.0xu.cn/
随时掌握互联网精彩
- 1 让澳门绽放更加迷人的色彩 7956361
- 2 网红收入超千万报税竟未达5000元 7965759
- 3 多地官宣将“取消公摊” 7859605
- 4 “打开”活力满满的澳门 7760478
- 5 哈尔滨文旅回复刘亦菲 7675243
- 6 男子给已婚同事发"么么哒"被开除 7508455
- 7 蚂蚁集团即将借壳上市?蚂蚁回应 7454704
- 8 艺术家谢芳逝世 曾主演《青春之歌》 7331396
- 9 特斯拉一夜之间市值蒸发9600亿 7290309
- 10 全国日均收购秋粮超200万吨 7169084