TiDB 资源管控的对撞测试以及最佳实践架构

导读

在现代数据库管理系统中，资源管控是优化系统性能、提高用户密度和降低成本的关键因素之一。TiDB 作为一个具有存算分离架构的分布式数据库，面临着在动态业务环境下如何高效管理资源的挑战。自TiDB 7.1 版本引入资源管控功能以来，社区通过大量测试验证了其在资源使用隔离上的有效性。然而，随着业务的不断发展和集群规模的变化(如扩容和缩容)，如何评估 TiDB 的动态容量，以及构建何种架构才能最大化资源管控的能力，成为亟待解决的问题。

本文将从业务角度切入，通过对不同类型业务(OLTP 和 OLAP)在资源管控下的表现进行详尽分析，探讨在动态发展模式下，如何优化TiDB 的资源管理策略。我们将深入研究同一计算节点和不同计算节点上的压力测试结果，揭示资源管控在不同业务类型之间的相互影响并提出最佳实践架构建议，以实现更稳定高效的系统性能。通过这篇文章，读者将了解到在实际运维中，如何通过精细的资源管控来提升TiDB 的整体表现和用户体验。

引言

TiDB 是一个存算分离的架构，资源管控对这种分离的架构来说实现确实有非常大的难度，TiDB 从 7.1 版本开始引入资源管控的概念，在社区也有不少伙伴测试，测试结果大部分在 RU 的隔离上得到了验证，资源管控在业务上带来的价值是利用提高用户密度的方式来降低成本，同时还可以通过资源管控的方式抑制不同类型的业务来避免集群抖动，但是随着我们业务在不断发展，用户在增加，集群的资源也在变化（缩容，扩容），在这种动态发展的模式下，如何评估我们的 TiDB 动态容量，以及什么架构才能发挥资源管控的最大能力是本文讨论的点，本文会从业务的角度作为切入点来反向观察集群的状态。

资源管控验证目标

OLTP vs OLTP 是否存在相互影响情况，包括业务层（TPS、QPS、duration）
OLTP vs OLAP 是否存在相互影响情况，包括业务层（TPS、QPS、duration）
OLAP vs OLAP 是否存在相互影响情况，包括业务层（TPS、QPS、duration）

环境介绍

最小化部署 3PD，3TiDB，3TiKV

TiDB 节点：为了公平 PD 和 TiDB 为混合部署，所有组件类如 Prometheus grafana alertmanager PD（L|UI）都放在一个 pd 机器上，让剩余的两个 TiDB 的计算节点负载相同

TiKV 节点：单机多实例部署，每个实例在部署 tikv 时都做了资源隔离，这样做的意义在于当 tikv 节点跑满时，最多用到 16c

yaml 复制代码

resource_control:  memory_limit: 150G  cpu_quota: 1600%

实验设计

TiDB 是存算分离的分布式数据库，多种不同类别的 SQL 难免会集中到一个 tidb 的计算节点上，而数据库中我们分为 OLTP 类业务和 OLAP 类业务，在这里我想说明下这两种业务的区别

OLTP 类的业务特点是短小的 SQL 语句，考验的是数据库处理高并发量的能力，常用的模拟工具有 sysbench，tpcc 等工具；

OLAP 类的业务特点是计算型的 SQL 语句，考验的是数据库优化器的能力，常用的模拟工具有 tpch 等工具；

综上所述，我们可以到如下集中测试的基本场景

压力来自相同的计算节点

压力来自不同的计算节点

再下来我们设计一下压测的样例，压测需要有如下的限制和数据

基于我们的验证目标（验证资源管控是否生效），那么无论是 tidb, tikv 的各种资源 (cpu,mem,network) 就不能打满，因为打满必定受到影响；
得到基线数据，基线数据是指无负载情况下的 qps 和 p95 响应延时，为了后续做对比；
TiDB 的资源管控组和用户为强绑定关系，我们为每个用户都单独设置一个资源组，也就是 1 对 1 的对应关系，这样可以让单租户把资源吃满。

TiDB 租户和资源组对应关系

压测样例

压测过程和数据篇幅较长，可点击 tidb.net/blog/bc405c... 查看"压测过程"章节实验结论

实验结论

1. OLTP vs OLTP:

RU 管控方面，相同资源管控组的不同用户，在同时执行 SQL 时，不会超出资源管控所设置的最大 RU 值（超卖参数除外）；
不同资源管控组的不同用户，在不同的 TiDB 计算节点上的 QPS 基本持平(有时还会超出基线数据)，P95 相同；
不同资源管控组的不同用户，在相同的 TiDB 计算节点上会有相互影响的情况，大约会有 8% ~ 10% 的影响；
关于资源组的优先级，经测试不同资源管控组的优先级几乎没有差别（ T5 场景）；
如果两个不同的资源组运行在不同的计算节点则没有影响（最佳实践）。

2. OLTP vs OLAP：

当 OLTP 平稳运行时遭遇 OLAP 业务会产生抖动，具体抖动延时需要看 OLAP 业务的 SQL 语句造成的影响；
当 OLTP 和 OLAP 在相同计算节点上执行时，P95 会有 8% 的下降，总体可以接受；
当 OLTP 和 OLAP 在相同计算节点上执行时，并且分配给 OLAP 业务的 RU 较少（一般为 OLAP 业务的 1/5 ），P95 会有 20% 的下降；
当 OLTP 和 OLAP 在相同计算节点上执行时，OLAP 业务表现会有 20% 左右的衰减（不过感觉 AP 类业务多个几秒钟无所谓）；
如果 AP 和 TP 类 SQL 分别运行在不同的 TiDB 计算节点上时，则影响最小（既做 AP 类资源限制又在计算层做资源隔离为最佳实践）。

3. OLAP vs OLAP：

当 OLAP 和 OLAP 在相同计算节点上执行时，查询效率会有下降（实测中发现过原来 300s 跑出的语句，时间翻倍）；
从返回结果看 OLAP 的资源优先级在实测过程中 medium 和 low 的差别不大；
加入 TiFlash 后，OLAP 的 SQL 语句在相同与不同的计算同时执行时，耗时相差不大；
运维方面的问题：不确定SQL 语句在 TiFlash 中占用了多少 RU；
OLAP 的业务在不同的计算节点上的效率最高。

最佳实践架构

这个 TiDB 架构应该是我理解的最佳实践了，从实验数据我们可以看到，即使我们开启了资源管控，两种不同业务类型同时请求同一个计算节点时，对其他的用户也是有一些抖动的，而从运维层面来说，要么降低租户的 RU，要么在计算节点进行隔离，从架构的角度出发，计算资源用 VIP 隔离开来，来达到专机专用的目的，存储节点通过 RU 来进行限制 IO，两层保护对稳定性有正向收益。