TiDB多业务合并新玩法

帅萌的杂谈铺 2024-09-24

235

一、背景

TiDB在v8版本进一步加强了resource control和分布式框架的能力。基于之前的placement rule in sql，我们可以推出TiDB新的解决方案。

比如机票业务：分为国内机票/国际机票/机票营销，如果每个子业务都需要一套TiDB集群。就会造成集群数据量多，服务器存在浪费的情况。

如果使用resource control+placement rule in sql的方案，可以进一步减少集群数量，减少人工运维成本，减少服务器数量。

对核心业务性能无影响，理由：指定了TiKV 存储数据的物理节点，从而实现核心和非核心业务进行了物理隔离。

非核心业务使用resource control能力进行隔离，也避免了突发慢查询SQL影响集群。

无论是本地机房，或者同城三中心的部署默认，一样适用此方案。

二、方案架构图

1、placement rule实现重要业务存储层彻底隔离+数据冷热分离

2、resource control实现次要的一些业务的相对隔离；

3、用分布式框架来实现并行任务（DDL、数据备份恢复、统计信息收集、TTL管理等），对业务进一步提供稳定性保障的同时，还可以提供给业务进行RDS查询使用。

数据存放使用说明：

1、热数据区域1，存放重点业务A数据；

2、热数据区域2，存放相对次要业务B、C、D、E业务数据；

3、冷数据区域1，存放所有业务A、B、C、D、E业务冷数据；

三、技术实现参考

1、label设计参考

针对不同的TiKV 设置labels，分别设置核心、非核心、其他的标签

SQL
核心（业务A）：bussiness-a
非核心（业务B、C、D、E）：bussiness-b
其他（业务A、B、C、D、E）：bussiness-all

2、创建并绑定放置策略

2.1、使用 CREATE PLACEMENT POLICY 语句创建放置策略：

SQL
# 策略myplacementpolicya，存放业务A热数据
CREATE PLACEMENT POLICY myplacementpolicya PRIMARY_REGION="bussiness-a" REGIONS="bussiness-a";

# 策略myplacementpolicyb，存放业务B、C、D、E热数据
CREATE PLACEMENT POLICY myplacementpolicyb PRIMARY_REGION="bussiness-b" REGIONS="bussiness-b";

# 策略myplacementpolicyall，存放业务A、B、C、D、E热数据
CREATE PLACEMENT POLICY myplacementpolicyall PRIMARY_REGION="bussiness-all" REGIONS="hdd";

在该语句中：

PRIMARY_REGION="bussiness-a" 选项代表 Raft leader 被放置在 region 标签为 us-east-1 的节点上。

REGIONS="bussiness-a,bussiness-b" 选项代表 Raft followers 被放置在 region 标签为 us-east-1 和 region 标签为 us-west-1 的节点上。

更多可配置的放置选项和对应的含义，请参考放置选项。

2.2、db层设置

SQL
CREATE database db-a PLACEMENT POLICY=myplacementpolicya;

CREATE database db-b PLACEMENT POLICY=myplacementpolicyb;
CREATE database db-c PLACEMENT POLICY=myplacementpolicyb;
CREATE database db-d PLACEMENT POLICY=myplacementpolicyb;
CREATE database db-e PLACEMENT POLICY=myplacementpolicyb;

# 对于业务A、B、C、D、E来说，可以根据某个date字段创建分区，将超过三年的数据，按照分区放入myplacementpolicyall（hdd盘的tikv下），作为冷数据存储，进一步降低存储成本。
ALTER TABLE t1 PARTITION p1 PLACEMENT POLICY=myplacementpolicyall;

使用 CREATE TABLE 或者 ALTER TABLE 将放置策略绑定至表或分区表，这样就在表或分区上指定了放置策略：

SQL
CREATE TABLE t1 (a INT) PLACEMENT POLICY=myplacementpolicya;
CREATE TABLE t2 (a INT);
ALTER TABLE t2 PLACEMENT POLICY=myplacementpolicya;

PLACEMENT POLICY 为全局作用域，不与任何数据库表结构相关联。因此，通过 CREATE TABLE 指定放置策略时，无需任何额外的权限。

2.3、查看放置策略

要查看某条已创建的放置策略，可以使用 SHOW CREATE PLACEMENT POLICY 语句：

SQL
SHOW CREATE PLACEMENT POLICY myplacementpolicya\G
*************************** 1. row ***************************
Policy: myplacementpolicy
Create Policy: CREATE PLACEMENT POLICY myplacementpolicya PRIMARY_REGION="us-east-1" REGIONS="us-east-1,us-west-1"
1 row in set (0.00 sec)

在test 里面创建的表默认属于 myplacementpolicy 规则

2.4、策略创建说明

在上面所介绍的业务背景下，应创建3个策略。

策略1:其中的tikv-server只存放业务A下的所有数据；

策略2:其中的tikv-server存放业务B、C、D、E下的所有数据；

策略3:用来将业务A、B、C、D、E所有的业务数据进行冷热分离（如超过3年数据存放在hdd盘上的tikv-server中）

实现逻辑图

3、设置 resource control 资源隔离

核心DB由于存放在独立的tikv节点，并且tidb-server也是独立的，无需给核心DB做资源隔离。

其他的DB 是需要资源隔离，可以使用resource control进行隔离。

资源隔离采用RU,可以理解更细力度的资源统计。

Request Unit (RU) 是 TiDB 对 CPU、IO 等系统资源的统一抽象的计量单位，用于表示对数据库的单个请求消耗的资源量。请求消耗的 RU 数量取决于多种因素，例如操作类型或正在检索或修改的数据量。

SQL
对于策略myplacementpolicyb下，业务B、C、D、E热数据共享6个tikv-server，使用resource-control进行一定隔离.
对于策略myplacementpolicyall下的所有业务A、B、C、D、E冷数据共享，也使用resource-control进行一定隔离.

CREATE RESOURCE GROUP IF NOT EXISTS bussinessa RU_PER_SEC = 200000 BURSTABLE;
CREATE RESOURCE GROUP IF NOT EXISTS bussinessb RU_PER_SEC = 50000 BURSTABLE;
CREATE RESOURCE GROUP IF NOT EXISTS bussinessall RU_PER_SEC = 20000 BURSTABLE;

CREATE USER 'bussiness-a'@'%' IDENTIFIED BY '123' RESOURCE GROUP bussinessa;
CREATE USER 'bussiness-b'@'%' IDENTIFIED BY '123' RESOURCE GROUP bussinessb;
CREATE USER 'bussiness-all'@'%' IDENTIFIED BY '123' RESOURCE GROUP bussinessall;

四、总结

该方案特点如下：

1、在计算层，使用不同的tidb-server进行彻底的计算资源的隔离。并且也可以根据不同的业务重要级别配置不同的计算资源。如有任务系统A配置3台16C64G资源的机器部署tidb-server使用，业务B、C、D、E使用4台8C32G资源的机器部署tidb-server，后台任务（DDL、数据备份恢复、统计信息收集、TTL管理等）使用3台8C8G资源的机器部署tidb-server，进一步确保业务稳定性；综合来看，根据业务重要等级，可以在计算层彻底的做到计算资源的隔离，也可以做到计算资源的共享；

2、在存储层，最重要的业务系统A单独享用6台16C64G nvme ssd盘的存储资源。业务B、C、D、E共同享用6台16C64G nvme ssd盘的存储资源。业务A、B、C、D、E所有业务的冷数据（如超过三年）共同享用4台8C16G的hdd盘的存储资源。综合来看，可以根据业务重要等级，可以在存储层彻底的做到计算资源的隔离，也可以做到存储层资源的共享；

3、在另一方面，可以在架构下，依据需求扩容tiflash节点，轻易的进行跨业务之间的数据关联分析，对外提供数据服务能力，而告别传统的dblink技术的使用；

4、随着越来越多的业务合并到一套集群，整体的硬件资源会越来越节省，完全可以作为op版本下的dbaas来使用；

5、随着业务的增加，可以按需扩展，完全无需做过多的资源评估工作，TiDB极致的弹性能力提供了很好的体验；

6、该使用方式，不只是带来服务器数量的降本，同时也可极大降低运维负担。

采用这套方案，满足核心业务的资源使用情况。还能减少服务器硬件的使用和大幅降低了集群数量和维护成本。即使出现服务器宕机的情况，依然不会对其他业务造成影响。

就拿国内机票业务线举例，核心的独立集群，非核心的共享集群。非核心的集群没有采用资源隔离的手段，非常容易发生慢查询SQL影响整个集群，故障面容易被扩大。

如果采用 placement rule in sql+resource control 可以实现资源的完全隔离，那么可以进行集群整合。从而实现降低了成本，并且对业务无影响。

tidb 集群技术

文章转载自帅萌的杂谈铺，如果涉嫌侵权，请发送邮件至：contact@modb.pro进行举报，并提供相关证据，一经查实，墨天轮将立刻删除相关内容。

TiDB多业务合并新玩法

评论