专栏 - TiDB多业务合并新玩法

一、背景

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，分别设置核心、非核心、其他的标签

核心（业务A）：bussiness-a

非核心（业务B、C、D、E）：bussiness-b

其他（业务A、B、C、D、E）：bussiness-all

2、创建并绑定放置策略

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


策略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";

策略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 标签为 bussiness-a 的节点上。

REGIONS="bussiness-a" 选项代表 Raft followers 被放置在 region 标签为 bussiness-a 的节点上。

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

2.2、db层设置


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 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，数据即在对应策略的库下对应的tikv实例上。如：


SQLCREATE TABLE db-a.tt1 (a INT) ; # 该表数据会自动将数据落到策略myplacementpolicya下，label为bussiness-a的tikv实例上面。

SQLCREATE TABLE db-a.tt1 (a INT) ;

# 该表数据会自动将数据落到策略myplacementpolicya下，label为bussiness-a的tikv实例上面。

如果想将该表数据放到其他策略的tikv-server实例下面，也可使用 CREATE TABLE 或者 ALTER TABLE 将放置策略绑定至表或分区表，这样就在表或分区上指定了放置策略：


SQLCREATE TABLE t1 (a INT) PLACEMENT POLICY=myplacementpolicyb; CREATE TABLE t2 (a INT);ALTER TABLE t2 PLACEMENT POLICY=myplacementpolicyb;

SQLCREATE TABLE t1 (a INT) PLACEMENT POLICY=myplacementpolicyb;

CREATE TABLE t2 (a INT);ALTER TABLE t2 PLACEMENT POLICY=myplacementpolicyb;

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

2.3、查看放置策略

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


SHOW CREATE PLACEMENT POLICY myplacementpolicya\G************************* 1. row *********************** Policy: myplacementpolicyaCreate Policy: CREATE PLACEMENT POLICY myplacementpolicya PRIMARY_REGION="bussiness-a" REGIONS="bussiness-a"*********************** 2. row *********************** Policy: myplacementpolicybCreate Policy: CREATE PLACEMENT POLICY myplacementpolicya PRIMARY_REGION="bussiness-b" REGIONS="bussiness-b "*********************** 3. row ************************* Policy: myplacementpolicyallCreate Policy: CREATE PLACEMENT POLICY myplacementpolicya PRIMARY_REGION="bussiness-all" REGIONS="bussiness-all" 1 row in set (0.00 sec)

SHOW CREATE PLACEMENT POLICY myplacementpolicya\G*************************** 1. row ***************************

Policy: myplacementpolicyaCreate Policy:

CREATE PLACEMENT POLICY myplacementpolicya PRIMARY_REGION="bussiness-a"

REGIONS="bussiness-a"*************************** 2. row ***************************

Policy: myplacementpolicybCreate Policy: CREATE PLACEMENT POLICY myplacementpolicya

PRIMARY_REGION="bussiness-b" REGIONS="bussiness-b

"*************************** 3. row ***************************

Policy: myplacementpolicyallCreate Policy:

CREATE PLACEMENT POLICY myplacementpolicya PRIMARY_REGION="bussiness-all" REGIONS="bussiness-all"

1 row in set (0.00 sec)

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

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 数量取决于多种因素，例如操作类型或正在检索或修改的数据量。


对于策略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;

对于策略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 可以实现资源的完全隔离，那么可以进行集群整合。从而实现降低了成本，并且对业务无影响。