继续浏览精彩内容
慕课网APP
程序员的梦工厂
打开
继续
感谢您的支持,我会继续努力的
赞赏金额会直接到老师账户
将二维码发送给自己后长按识别
微信支付
支付宝支付

你需要什么样的资源隔离?丨TiDB 资源隔离最佳实践

PingCAP
关注TA
已关注
手记 516
粉丝 61
获赞 85

导读

资源隔离是数据库性能优化的重要环节, TiDB 在当前版本已经实现了从数据级隔离到流控隔离的全面升级 ,无论是多系统共享集群、复杂负载隔离,还是小型系统整合和 SQL 精细化控制,TiDB 都提供了灵活且高效的解决方案。

本文以实际案例为切入点,详细解读了 Placement Rules in SQL、Resource Control 等关键功能,以及 7.2+ 版本新增的 Runaway Queries 管理机制, 帮助各位开发者和管理员选择最适合自己的 TiDB 资源隔离方案。


你需要什么样的隔离?

时至今日,TiDB 提供的隔离能力愈发完善,上到不同系统、下到 SQL 语句,均能实现良好的隔离效果。本文旨在帮助大家了解:你需要什么层面的资源隔离,以及各种层面隔离如何使用。

你需要什么层面的资源隔离

基于数据的隔离方案

中大型系统之间隔离

在提及资源隔离时,大家往往想到的是:多个系统共用一套集群,如何限制每个系统所用的资源。在之前版本中,TiDB 提供了基于 K8s 的 Cloud TiDB 方案,但企业 DBA 很少同时具备 K8s 和数据库两种技能;另外企业中 K8S 大部分也非原生,不一定满足 Cloud TiDB 的部署需求。

从 6.5 版本开始,TiDB 提供了 Placement Rules in SQL 功能,一种基于 SQL 规则的数据放置策略,可以轻松实现数据级别的物理隔离,使得多个系统共用一套 TiDB 集群时,满足物理层面隔离的需求。

典型场景:多系统共用集群并完全独占资源

多系统共用集群并完全独占资源

示例: Placement Rules in SQL 规则(适合中大型系统)

create placement policy policy_order constraints="[+zone=order]"; 
create placement policy policy_inv constraints="[+zone=inventory]"; 
alter database retail_order placement policy policy_order;
alter database retail_inventory placement policy policy_inv;

典型场景:每个系统仅独占一个实例、单点故障时共享

每个系统仅独占一个实例、单点故障时共享

典型客户案例: 某领先零售企业 TiDB 生产集群架构

示例: Placement Rules in SQL 规则(适合中型系统)

create placement policy policy_server1 leader_constraints="[+host=host1]"; 
create placement policy policy_server2 leader_constraints="[+host=host2]"; 
create placement policy policy_server3 leader_constraints="[+host=host3]"; 
alter database DB1 placement policy policy_server1;
alter database DB2 placement policy policy_server2;
alter database DB3 placement policy policy_server3;

系统内不同负载隔离

以上是多个系统之间的隔离,在一个业务系统内,同样也会有基于负载的隔离需求(如 OLTP 和 ETL/报表两种负载);也就是过去常提及的读写分离,在一套数据库内,实现两种负载的隔离。

在使用 TiDB 时,由于一套集群已经由多台服务器组成,如再建设一套配置相同的备集群来实现,此时成本相对是比较高的。从 6.5 版本开始,也可以轻松使用 Placement Rule/Placement Rules in SQL + Follower 副本读取策略来实现,同时与传统主备/主从读写分离相比:TiDB 的只读区域(含 TiKV/TiFlash)可提供与联机完全一致的查询能力。

典型场景:联机事务处理 +ETL|BI 隔离

联机事务处理 +ETL|BI 隔离

示例:

  • Placement Rules in SQL 规则(针对业务数据,Leader 分布在前两台 TiKV);
create placement policy policy_eyas leader_constraints="[-zone=zone3]"; 
alter database eyas placement policy policy_eyas;
  • Placement Rules in SQL 规则(针对运营数据,Leader 分布在第三台 TiKV);
create placement policy policy_bi leader_constraints="[+zone=zone3]" follower_constraints ='{"+zone=zone1": 1,"+zone=zone2": 1}';
alter database bi_eyas placement policy policy_bi;
alter database da_ping placement policy policy_bi;
alter database eyasbi placement policy policy_bi;
  • 业务库+运营库均增加列存副本;
  • TiDB 设置就近读。
set global tidb_replica_read = 'closest-replicas';

典型场景:联机事务处理+复杂查询隔离

联机事务处理+复杂查询隔离

典型案例: 2 机房双活+1 机房就近只读

注: zone 是 tikv 中一个 label 的定义,可以代表一个真实的机房,也可以单机房集群中设计一个 zone

示例:

  • Placement Rule 规则(设置全局 Leader 和 Follower 分布策略), 机房 q03 不分布任何 Leader,同时 q03 机房进行本地读取;
[
    {
        "group_id": "pd",
        "id": "q01",
        "start_key": "",
        "end_key": "",
        "role": "voter",
        "count": 1,
        "label_constraints": [
            {"key": "zone", "op": "in", "values": ["q01"]}
        ],
        "location_labels": ["host"]
    },
    {
        "group_id": "pd",
        "id": "q02",
        "start_key": "",
        "end_key": "",
        "role": "voter",
        "count": 1,
        "label_constraints": [
            {"key": "zone", "op": "in", "values": ["q02"]}
        ],
        "location_labels": ["host"]
    },
    {
        "group_id": "pd",
        "id": "q03",
        "start_key": "",
        "end_key": "",
        "role": "follower",
        "count": 1,
        "label_constraints": [
            {"key": "zone", "op": "in", "values": ["q03"]}
        ],
        "location_labels": ["host"]
    }
]
  • TiDB 设置就近读。
set global tidb_replica_read='closest-replicas';

基于流控的的隔离方案

基于数据隔离的方案虽然能够有效地实现 CPU、内存、磁盘等资源的物理隔离,但也存在一定的灵活性问题:

  • 数据需要与存储节点进行绑定(也就是资源的最小单位是节点),该方案仅适用于中大型系统之间的隔离,基本不适应于小型系统
  • 在扩缩容时,该方案可能需要迁移底层数据,无法立即生效
  • 如果集群中仅有一套库表供多个系统共享,此时基于数据的隔离方案便无法工作了

为了解决以上不足,TiDB 自 7.1 版本起引入了基于流控的隔离方案 - Resource Control,目的是简化分布式架构中资源管理的复杂度:

  • 将 CPU、IO、网络等资源统一抽象为资源单位(RU),大幅简化对资源的定义
  • 提供数据库用户、SQL 语句、后台任务等三个层面的资源隔离
  • 在扩容或缩容时,资源调整可以秒级生效,无需迁移数据,提供了极致弹性能力

总的来说,Resource Control 是一种更灵活高效的资源管理方式,不仅能够实现多系统、多负载的隔离,还可以进行 SQL 语句和后台任务层面更精细化的控制。

数据库用户隔离

典型场景 - 小型系统整合

在我过去的经历中,我发现小型数据库系统普遍存在资源利用率较低的情况。实际上,我们在申请数据库资源时,往往基于直觉或者标准化配置来选择资源,背后可能并没有一个明确的依据。另外,多个系统通常负载峰值时间各不相同,在使用传统方案时也只能根据最大峰值+冗余的方式来申请资源,不可避免会出现较多资源闲置。

TiDB 的 Resource Control 方案,使得我们能够在较小的配置下实现更高效的资源利用率。将多个小型数据库系统整合到 TiDB 后,每个系统的资源分配可以根据其实际负载峰值、QPS 等需求进行精细化管理;如果在这些系统中存在一个消耗资源较高的系统,还可考虑分配单独的 TiDB 计算实例供其使用。

小型系统整合

典型场景 - SaaS 场景

SaaS 场景

在以上第三种多租户架构中 ,多个租户共用一个库、同时共用一套表,表内通过分区来存储不同 SaaS 租户的数据,或直接使用单表(通过表内的 tenant_id 字段来区分 ),此时 TiDB Resource Control 可以轻松通过数据库用户来为不同租户进行资源控制。

而面对 SaaS 动辄数千个租户的需求,TiDB Resource Control 是极其有帮助的,无需划分 CPU/内存/节点数量,可创建数据库用户级别的资源组,轻松管理不同租户的资源需求和弹性需求:

三种多租户架构

示例:

  • 假设租户 1 是体量非常大,可为其单独创建数据库用户 user1,并为该用户创建独立资源组,优先级高,且允许超用;
CREATE RESOURCE GROUP rg_tenant1 RU_PER_SEC = 1000000 PRIORITY = HIGH BURSTABLE;
alter user 'user1' RESOURCE GROUP rg_tenant1;
  • 其他租户由于体量较小,共用一个资源池;
CREATE RESOURCE GROUP rg_tenant_default RU_PER_SEC = 500000 PRIORITY = MEDIUM;
alter user 'user_default' RESOURCE GROUP rg_tenant_default;
  • 扩容。
ALTER RESOURCE GROUP rg_tenant_default RU_PER_SEC = 900000 PRIORITY = MEDIUM;

典型场景 - 系统内批量负载隔离

在一个系统中往往会存在联机和批量两种负载,如联机的峰值在白天,到凌晨基本上是业务低峰期,此时可以安全的运行系统内的大型批量作业,进行大规模、高密度的读写,以尽快完成批量作业,进而不影响白天的联机业务。

但有些情况下,批量可能会跑到第二天业务高峰期,此时停止这个批量显然是不太合适的,但放任它继续消耗大量资源执行,显然也是不合适的。

在过去其实缺乏一些库内的管控手段的,只能在调度层、应用层进行有限控制。而 TiDB Resource Control 也可以轻松管理这种情况。

示例: 为批量作业单独创建用户,并绑定资源组:

CREATE USER 'USER_BATCH' IDENTIFIED BY '******';
CREATE RESOURCE GROUP rg_batch RU_PER_SEC = UNLIMITED PRIORITY = HIGH;
alter user 'USER_BATCH' RESOURCE GROUP rg_batch;


-- 假设批量任务超时运行到第二天白天,只需执行如下 SQL 即可立即将其限速
ALTER RESOURCE GROUP rg_batch RU_PER_SEC = 100000 PRIORITY = LOW;

SQL 语句级别隔离

自 7.2 版本以来,TiDB Resource Control 引入了对 Runaway Queries(即执行时间或消耗资源超出预期的查询)的管理功能:

  • QUERY_WATCH(手动处理):对发现的 SQL 进行限流或熔断
  • QUERY_LIMIT(自动处理):当不符合预期的 SQL 出现时,数据库可自己识别、并自适应处理

典型场景 - SQL限流与熔断(QUERY_WATCH)

有一些 SQL 语句可能存在这种情况:编写不规范或需要查询大量数据(如抽数),它们在运行时可能会消耗大量的资源,我们希望它们跑慢一点没关系,但不要消耗太多资源影响正常业务请求。在 TiDB 中,可以轻松通过 Resource Control 来对它们进行限流:

-- 该 SQL 执行时,单独使用 rg1 资源组执行(rg1 是一个 100 RU 的资源)
SELECT /*+ RESOURCE_GROUP(rg1) */ * FROM t where is_delete=0 and create_time>='2023-01-01';

-- 将 default 资源组中的这条 SQL 进行降低优先级,让其限速执行
QUERY WATCH ADD RESOURCE GROUP DEFAULT ACTION COOLDOWN SQL TEXT EXACT TO 'select * FROM t where is_delete=0 and create_time>='2023-01-01';

另外也可能存在一种情况,系统内突然出现一条之前从未运行过的大 SQL,它来历不明,我希望先直接将其熔断,不让其执行:

-- 根据 SQL DIGEST 维度进行拦截,并终止
QUERY WATCH ADD RESOURCE GROUP default ACTION KILL SQL DIGEST 'd08bc323a934c39dc41948b0a073725be3398479b6fa4f6dd1db2a9b115f7f57';

-- 另外还可以使用 SQL TEXT 维度(可单独拦截某一特定条件值的 SQL)
-- 以及 PLAN DIGEST 维度(可拦截 SQL 中某一很差的计划出现)

典型场景 - 超出预期的查询自适应管理(QUERY_LIMIT)

基于 QUERY_WATCH 的限流和熔断方案,属于事中或事后的人工处理手段。从问题的出现、发现到最终解决,这一过程往往需要一定的时间;即便是经验丰富、对系统非常熟悉的管理员,在解决完问题时,往往已经过去了数分钟,甚至更长时间。这意味着,业务可能受的影响时间也会与之相关。

而 QUERY_LIMIT 则提供了更加灵活的自适应处理手段,让数据库可以自动发现异常并处理异常,我们只需要定义异常即可:

示例:

  • 创建 rg_auto_cooldown 资源组,限额是 100000 RU,我们可以定义该资源组中执行时间超过 60 秒的查询为 Runaway Query,并让系统自动对 Runaway Query 进行降低优先级限流处理;
CREATE RESOURCE GROUP rg_auto_cooldown RU_PER_SEC = 100000 QUERY_LIMIT=(EXEC_ELAPSED='60s', ACTION=COOLDOWN);
  • 创 建 rg_over_10000 资源组,限额是 100000 RU,我们可以定义该资源组中每秒超过 10000 RU 的查询为 Runaway Query,并让系统自动对他们进行降低优先级限流处理;
CREATE RESOURCE GROUP rg_colldown RU_PER_SEC = 100000 QUERY_LIMIT=(RU=10000, ACTION=COOLDOWN);
  • 还可以在当前资源组,将大型查询隔离到其他资源组执行:定义 default 资源组中处理数据行数超过 1000000 的查询为 Runaway Query,并让系统自动将他放到 rg_bigquery 资源组中执行,避免与当前资源组中的请求发生争用。
CREATE RESOURCE GROUP rg_bigquery RU_PER_SEC = 10000 PRIORITY = LOW;
-- 假设我当前资源组为 default
ALTER RESOURCE GROUP default QUERY_LIMIT=(PROCESSED_KEYS=1000000, ACTION=SWITCH_GROUP(rg_bigquery));

后台任务级别隔离

在日常运维过程中创建索引是一个常见的工作,虽然在 TiDB 中所有 DDL 均是在线的,但我们也不能忽视创建索引时资源消耗带来的风险。自 7.4 版本开始,TiDB Resource Control 引入了对后台任务的管理。

示例:

以创建索引这一 DDL 任务为例,可以设置 ddl 为后台任务,并且限制其最多可使用 TiKV 节点总资源的 30%。此时系统便会动态地限制该任务的资源使用,以尽量避免此类任务在执行时对其他前台任务的性能产生影响:

ALTER RESOURCE GROUP `default` BACKGROUND=(TASK_TYPES='ddl', UTILIZATION_LIMIT=30);

目前 TiDB 支持如下几种后台任务的类型:lightning、br、ddl、stats 等。

总结

通过本文的学习,相信大家对 TiDB 的资源隔离能力有了更全面的理解;大家可以根据不同的场景需求,选择合适的资源隔离方案。

不同类型的隔离方案

如果您有新的资源隔离需求或场景,欢迎与我们联系

打开App,阅读手记
0人推荐
发表评论
随时随地看视频慕课网APP