{
    "componentChunkName": "component---src-templates-blog-blog-detail-tsx",
    "path": "/blog/multi-tenant-solution-tidb-7.1.0",
    "result": {"pageContext":{"blog":{"id":"Blogs_504","title":"TiDB v7.1.0 跨业务系统多租户解决方案","tags":["资源管控","多租户"],"category":{"name":"案例实践"},"summary":"本文介绍了 TiDB 数据库的资源管控技术，并通过业务测试验证了效果。资源管控技术旨在解决多业务共用一个集群时的资源隔离和负载问题，通过资源组概念，可以限制不同业务的计算和 I/O 资源，实现资源隔离和优先级调度，提高系统利用率和稳定性。","body":"> 本文作者李文杰，网易游戏计费 TiDB 负责人\n\n## 导读\n\n本文介绍了 TiDB 数据库的资源管控技术，并通过业务测试验证了效果。资源管控技术旨在解决多业务共用一个集群时的资源隔离和负载问题，通过资源组概念，可以限制不同业务的计算和 I/O 资源，实现资源隔离和优先级调度，提高系统利用率和稳定性。\n\n## 业务背景  \n\n随着业务对 TiDB 的使用不断扩大和深入，在多业务共用一个集群的情况下，相信不少用户也遇到过不同负载之间相互影响的问题。在之前的版本里，TiDB 也在尝试不同的方法来缓解或解决这类问题。比较典型的例子就是通过引入 TiFlash 列存组件，在存储引擎层面区分 TiKV 上的在线处理事务和在 TiFlash 上的分析型任务，在存储层物理隔离不同的负载。这种架构优化有很多的好处，但如果业务都是需要访问 TiKV 才能得到结果的场景，就没办法来处理。\n\n我们线上十几个生产集群，考虑成本、运维等问题都是多业务共用一个集群，在我们尽可能将 TP 业务和 AP 业务分离部署的前提下，通常还是会遇到下面的问题：\n\n- 当一个业务处于高峰期时，会过多占用别的业务使用的资源，进而影响别的业务正常运行。\n  - 我们希望能保护不同业务的资源持有情况，保证业务能分配到基本的运行资源而不被挤兑。\n- 当集群中的重要业务处于低谷值时，有较多的剩余资源，如果我们能把错峰的业务引进来就可以充分使用资源，可以降本增效。但这要求错峰运行的业务需要能得到控制，其他时候不会占用过多资源。\n- 当集群遇到临时的问题 SQL 引发的性能问题时，只能停掉 SQL 。\n  - 我们更希望不是干掉它的执行，而是临时限制它资源消耗，允许它缓慢运行，但又不会影响集群其他业务。\n\n在这样的业务痛点背景下 TiDB v7.1.0 提出了资源管控技术，我们第一时间跟进该技术，并尝试探讨解决融合系统中多租户资源使用的隔离方案。\n\n## TiDB 资源管控技术\n\n资源管控技术（Resource Control）可以在负载剧烈变化时保证服务质量，同时提供了数据库的多租户隔离能力，能够有效地降低数据库运行成本。\n\n### 原理说明\n\nTiDB 资源管控特性提供了两层资源管理能力，包括在 TiDB 层的流控能力和 TiKV 层的优先级调度的能力。将用户绑定到某个资源组后，TiDB 层会根据用户所绑定资源组设定的配额对用户的读写请求做流控，TiKV 层会根据配额映射的优先级来对请求做调度。通过流控和调度这两层控制，可以实现应用的资源隔离，满足服务质量 (QoS) 要求。\n\n- TiDB 流控：TiDB 流控使用[令牌桶算法](https://en.wikipedia.org/wiki/Token_bucket)做流控。如果桶内令牌数不够，而且资源组没有指定 `BURSTABLE` 特性，属于该资源组的请求会等待令牌桶回填令牌并重试，重试可能会超时失败。\n- TiKV 调度：可以为资源组设置绝对优先级 (PRIORITY)，不同的资源按照 `PRIORITY` 的设置进行调度，`PRIORITY` 高的任务会被优先调度。如果没有设置 PRIORITY，TiKV 会将资源组的 `RU_PER_SEC` 取值映射成各自资源组读写请求的优先级，并基于各自的优先级在存储层使用优先级队列调度处理请求。\n\n![TiKV 调度.png](https://img1.www.pingcap.com/prod/Ti_KV_290c8ff769.png)\n\nTiDB 资源管控技术利用资源组 (Resource Group) 将集群划分为多个逻辑单元，每个资源组都能限制其所需的计算和 I/O 资源。当集群有空闲资源时，通过特定设置可以允许一部分资源组超越其限制，充分利用集群资源。它基本上解决了在多种业务合并后，造成资源争抢的问题，保证了业务的稳定性。如下是该技术的一个概念图：\n\n![概念图.png](https://img1.www.pingcap.com/prod/_3afc075ebf.png)\n\nResource Control 是基于 TiDB 的流控和 TiKV 的调度功能来完成的。同时 BURSTABLE 功能允许其超过资源组的约束配额，使其可以保证服务正常运行。\n\n### 管理方式\n\n资源管控引入了资源组(Resource Group)的概念，通过设置“用户”和“资源组” 的对应关系，把会话与用户组进行绑定，利用“用量 (RU)”对资源限额进行定义。[结构如下](https://tidb.net/blog/67d82266)：\n\n![资源组.png](https://img1.www.pingcap.com/prod/_bbb0a1e66b.png)\n\n关于资源组、资源限额、调度优先级等特性具体可以参考[官网](https://docs.pingcap.com/zh/tidb/stable/tidb-resource-control)。\n\n这里特地说明资源组设定是很灵活的，很方便管理员根据业务的使用场景，我觉得这也对 TiDB 的易用性有很好的提升， 分别设置不同的级别：\n\n- 用户级别。将用户绑定到特定的资源组。绑定后，对应的用户新创建的会话会自动绑定对应的资源组。\n\n- 会话级别。通过 `SET RESOURCE GROUP` 设置当前会话的资源组。\n\n- 语句级别。通过优化器 `hint RESOURCE_GROUP() `设置当前语句的资源组。\n\n### 技术应用点\n\n总结之，该技术主要解决了下面业务常见问题：\n\n- 当系统中存在多业务负载时，资源隔离，保证交易类业务的响应时间不受数据分析或批量业务的影响。\n- 在系统负载较低时，繁忙的应用允许超过设定的读写配额，最大化利用资源，提升硬件利用率，降低运行成本。\n- 限制突发 SQL 的资源消耗，避免引起集群性能问题。\n- 提供用量统计的精确反馈，完成不同业务合理的成本分摊\n  - 通过监控面板获取实际用量的使用情况，协助用户合理改进配置。同时，配合企业管理目标，TiDB 能够协助企业精确统计各部门数据库资源的使用情况，完成合理的成本分摊。\n- 提供灵活的资源绑定手段。\n  - 支持在用户级，会话级，和语句级指定资源的绑定方式，满足不同场景的资源控制需要。  \n\n经过梳理它的基本原理和设计目标等内容，看起来可以很好解决我们实际生产环境的业务痛点，所以我们开启进一步的实际测试和验证。\n\n## 业务验证\n\nTiDB 可以基于硬件部署或实际负载估算集群的总体 RU 容量，我们在测试时是直接参考基于硬件部署的估算量。\n\n### 业务资源模拟\n\n为了模拟我们生产环境最常见的不同业务，这里我们创建三个租户，分别表示三种不同的业务负载，每类业务有不同的管控目标。下表是我们的不同业务运行在同一个 TiDB 集群中，每个业务不同的运行需求：\n\n![三租户模拟.png](https://img1.www.pingcap.com/prod/_ab5aa34b17.png)\n\n在资源管控技术的基础上，我们可以为这三类用户分别创建资源组：\n\n- 为租户 app_oltp 分配一个较高的用量，租户 app_olap 和 租户 app_other 则相对低\n  - 在系统资源紧张的情况下，最优先保证租户 app_oltp 的服务质量。\n\n- 租户 app_oltp 和 app_olap 的资源组设置为 burstable\n  - 租户 app_oltp 发生超预期的负载，仍旧可能会保证质量；\n  - 而当整个集群负载有空余时， 租户 app_olap 可以利用空闲资源加速其工作。\n![租户资源分配.png](https://img1.www.pingcap.com/prod/_5962502d30.png)\n\n- 创建资源组\n```\n CREATE RESOURCE GROUP IF NOT EXISTS rg_oltp RU_PER_SEC = 1000 BURSTABLE PRIORITY = HIGH;\n CREATE RESOURCE GROUP IF NOT EXISTS rg_olap RU_PER_SEC = 400 BURSTABLE;\n CREATE RESOURCE GROUP IF NOT EXISTS rg_other RU_PER_SEC = 100;  \n```\n\n- 我们线上的业务是已经存在了的，换言之上线该功能时业务账号也一定是已经存在的，所以模拟时直接对业务绑定资源组\n```\nALTER USER app_oltp RESOURCE GROUP rg_oltp;\n ALTER USER app_olap RESOURCE GROUP rg_olap;\n ALTER USER app_other RESOURCE GROUP rg_other;  \n```\n\n### 业务运行模拟\n\n我们在测试环境启动短连接业务实时访问数据，不断进行读取和写入操作，分别用来模拟几个租户不同的负载，观测业务侧吞吐量 (QPS) 和 数据库 TiDB 的资源消耗情况 (RU 用量趋势）。整个场景大概模拟下面几个场景：\n\n1.对有设置使用上限且正在运行的业务，在线调整集群资源分配操作：\n\na. 临时扩大租户 app_other 的可用资源，模拟临时给在线业务增加资源  \nb. 临时缩小租户 app_other 配额，模拟临时给在线业务缩减资源  \nc. 允许租户 app_other 突破资源限额，模拟临时取消在线业务资源使用限制  \nd. 不允许租户 app_other 突破资源限额使其回到最开始的限额状态，模拟临时限制在线业务资源使用  \n\n2.模拟不同业务在同一个集群融合共存，观察全部租户经历最重要业务的一个波峰、波谷完整周期的运行情况\n\na. 首先三类负载同时运行，表示业务正常共存情况  \nb. 业务流量高峰来临，租户 app_oltp 达到峰值负载  \nc. 租户 app_oltp 峰值过去，回到平时状态  \nd. 租户 app_oltp 的负载到低谷值，其他不变  \ne. 租户 app_oltp 低谷过去，回到平时状态\n\n**1 在线增加/减少业务可用资源**\n\n对有设置使用上限且正在运行的业务，临时调整租户 app_other 的可用资源，模拟临时给在线业务增加或减少资源。\n\n- 初始：租户 app_other 的业务初始资源配额\n\n ```\nALTER RESOURCE GROUP rg_other RU_PER_SEC = 100;\n```\n\n- 扩大：临时扩大租户 app_other 业务的可用资源\n```\nALTER RESOURCE GROUP rg_other RU_PER_SEC = 400;\n```\n\n- 缩小：临时缩小租户 app_other 业务的可用资源\n```\nALTER RESOURCE GROUP rg_other RU_PER_SEC = 50;\n```\n\n![资源分配示意.png](https://img1.www.pingcap.com/prod/_a53ced0295.png)\n\n如上图所示，可以看到租户 app_other 的业务初始资源配额为 100，期间业务在稳定运行。\n\n假设有某个原因需要我们临时调大它的可用资源，此时调大可用资源 RU_PER_SEC = 400，业务能使用到的 RU 会立即响应分配到需要的资源，曲线会不断上升。反之我们缩小可用资源 RU_PER_SEC = 50 时，曲线会下降到我们预期的设定值。\n\n- 总结：\n  - 说明 TiDB 的资源管控技术可以在线调整业务资源使用状态，实时对业务进行资源配置，大大提高业务响应速度。\n  - 如果这类业务是突发的异常 SQL，我们可以临时限制它的资源消耗，避免引起集群性能问题。\n\n**2 在线取消业务配额限制**\n\n允许租户 app_other 突破资源限额，模拟临时取消在线业务资源使用限制场景。\n\n- 初始：租户 app_other 的业务初始资源配额\n```\nALTER RESOURCE GROUP rg_other RU_PER_SEC = 50;\n```\n\n- 取消限制：允许租户 app_other 业务突破可用资源的限额\n```\nALTER RESOURCE GROUP rg_other RU_PER_SEC = 50 BURSTABLE;\n```\n\n![资源分配示意 2.png](https://img1.www.pingcap.com/prod/2_71c6d887f6.png)\n\n如上图所示，可以看到租户 app_other 的业务初始资源配额为 50，期间业务在稳定运行。此时我们临时取消它的可用资源限制，在集群收到配置后其 RU 曲线不断上升，直到需要的最大值。\n\n- 总结：\n  - 说明 TiDB 的资源管控技术可以在线调整业务资源使用状态，实时取消对业务资源使用限制\n\n**3 在线限制业务最大可用资源**\n\n不允许租户 app_other 突破资源限额，模拟临时限制在线业务资源使用\n\n- 初始：允许租户 app_other 业务突破可用资源的限额\n```\nALTER RESOURCE GROUP rg_other RU_PER_SEC = 50 BURSTABLE;\n```\n\n- 不允许突破限额：不允许租户 app_other 突破限额\n```\nALTER RESOURCE GROUP rg_other RU_PER_SEC = 50;\n```\n\n![资源分配示意 3.png](https://img1.www.pingcap.com/prod/3_63da287a65.png)\n\n如上图所示，可以看到租户 app_other 的业务初始资源配额没有限制，可以使用到其所需的最大资源，业务在稳定运行。此时我们临时增加限制，不允许突破限额，在集群收到配置后其 RU 曲线不断下降，直到回到最初的限制状态。\n\n- 总结：\n  - 说明 TiDB 的资源管控技术可以在线调整业务资源使用状态，实时添加硬上限，不允许业务突破限额\n\n- 小结：\n我们整理一下上面的模拟操作，如下面图示过程，经过测试和验证，证明 TiDB 的资源管控技术可以在线调整业务资源使用状态，允许 TiDB 管理员根据业务运行动态，实时扩大、缩小、取消限额、添加硬上限不允许业务突破限额等操作，非常灵活和方便，大大降低运维的难度，也极大提高集群的资源使用效率。\n\n![资源分配示意 4.png](https://img1.www.pingcap.com/prod/4_0dab96c9bb.png)\n\n**4 跨业务共存测试**\n\n我们通过调整租户 app_oltp 业务的压测 QPS，产生出租户 app_oltp 业务的波峰和波谷。这里我们模拟不同业务在同一个集群融合共存，所有业务经历最重要业务的一个波峰、波谷完整周期，观察运行情况。流程如下：\n\n- 首先三类负载同时运行，表示业务正常共存情况\n- 业务流量高峰来临，租户 app_oltp 达到峰值负载\n- 租户 app_oltp 峰值过去，回到平时状态\n- 租户 app_oltp 的负载到低谷值，其他不变\n- 租户 app_oltp 低谷过去，回到平时状态\n\n![资源分配示意 5.png](https://img1.www.pingcap.com/prod/5_7eb2a092bd.png)\n\n如上图可以看到，刚开始时集群的几个业务正常共存，三类负载同时运行着。\n\n- 租户 app_oltp 达到峰值负载其业务流量高峰来临，系统会分配给它更多的资源，于此同时由于集群可用资源不足租户 app_olap 分配得到的 RU 有所减少，等到租户 app_oltp 的峰值过去，租户 app_olap 分配得到的 RU 有所增加回到最初的状态。\n- 经过一段时间后，租户 app_oltp 达到其运行的业务谷值其所需要的 RU 下降，此时集群空闲 RU 增多，由于租户 app_olap 设置的是 BURSTABLE， 允许突破限额使用资源，所以租户 app_olap 的可用 RU 上升，等到租户 app_oltp 的谷值过去，租户 app_olap 分配得到的 RU 有所减少回到最初的状态。\n- 由于租户 app_other 自始至终有配额限制且需要较少的 RU ，所以其稳定维持在一个较低的水平，不影响别的业务运行。\n\n![TiDB 集群RU使用.png](https://img1.www.pingcap.com/prod/Ti_DB_RU_435d5c5483.png)\n\n前面的过程我们是从集群资源使用的角度看的问题，现在换个视角从业务 QPS 角度来看，如上图所示不同的业务的运行 QPS，基本随着可用资源的增多而升高，随着可用资源的减少而下降，服务业务预期。由此得出， 利用 TiDB 提供的资源管控和调度能力，多个不同诉求的租户能够共存在一套系统中，在保证各自服务目标的基础上，提升资源使用效率。\n\n**5 总结**\n\n我们验证了针对单个在线业务的资源调整，以及模拟了重要业务在经历完整波峰、低谷的运行周期内各个业务的运行情况，每个要点的测试数据和结果都符合我们的预期，证明了该资源管控技术的可行性。同时也表明了：\n\n- TiDB 的资源管控技术能动态跟踪业务负载情况，实时分配所需的资源，证明其操作具有良好的实时性。\n- 当系统中存在多业务负载时，能够实现资源隔离，保证重要的业务不受其他访问的影响。\n- 在系统负载较低时，繁忙的应用允许超过设定的配额，能最大化利用资源，提升硬件利用率，降低运行成本。\n\n## 跨业务系统多租户解决方案\n\n基于我们线上 TiDB 的使用方式，就可以制定出一个初步的跨业务系统多租户解决方案，其他业务系统的部署架构需要具体情况具体分析。\n\n这里使用 TiDB 多租户技术，能完成多个业务系统使用统一的集群，保证不同业务负载相互隔离，互不干扰，互不影响，然后对于有统计分析类需求也可以再利用 TiFlash 的 实时 HTAP 能力，实现跨业务数据关联查询，这部分能力通过 TiFLash 与 TiKV 也进行了物理隔离，不会影响线上运行的 TP 业务。这个方案架构图大致如下：\n\n![方案架构图.png](https://img1.www.pingcap.com/prod/_1f7666bc97.png)\n\n**方案说明**\n\n- 根据不同的业务设置不同资源组和 RU，当集群整体资源繁忙时实现不同业务基于 RU 限流和负载隔离；\n- 为重要业务设置资源组 BURSTABLE 属性，实现跨业务错峰资源借用；\n- 为重要业务设置优先级为 HIGH，确保集群优先保证重要业务资源可用；\n- 引入 TiFlash 解决实时数据分析需求；\n- 如果业务有必要，还可以针对 tidb-sever 划分不同的业务节点，真正达到整个集群的资源隔离\n\n**方案总结**\n\n- 优势\n  - 通过控制应用、会话、SQL 放入到对应的资源组中，高优先级的业务可以优先被满足，剩余的算力可以去满足次优的业务，达到资源的充分利用\n  - 系统可扩展性强，在系统负载较低的情况下，繁忙应用即使超过设定的 RU，也仍然可以获得所需的系统资源，从而提高了系统的可扩展性\n  - 不同业务可以混合部署在同一个集群上，减少硬件成本\n  - 不同业务错峰使用资源，提升整体资源利用率，降低运行成本\n  - 节约硬件成本\n  - 高可扩展\n  - 资源灵活管控\n  - 解决数据孤岛问题\n\n- 劣势\n  - 资源划分策略难以确定，先根据硬件情况估计分配，在运行一段时间后负载校准，再介入调整，这需要运维人员有很高的技术和经验，容易出错\n  - 集群系统复杂度变高，要手动对集群资源池进行划分和管理，增加系统的复杂度，维护难度变高\n  - 系统复杂度高\n  - 资源分配策略不好制定\n\n## 未来展望\n\n- 笔者在测试验证中发现，资源如何划分是一个比较棘手的问题，通过硬件配置校准 RU 的估算容量并不准确，真实容量往往偏差较大，所以需要我们先给较大的资源配额，观察一段时间后通过负载校准得到真实 RU 消耗再设置正确值，如果这块后续能够更加智能、更加自动化，减少人工的介入可能会更完美，期待官方后续优化。\n- 目前 RU 包括的资源是 CPU 、磁盘 IO 和网络 IO，暂时还不支持内存资源的管控，期待后续官方把内存的使用管控也加进来。\n- 调整资源组配置后，只对用户新建的会话生效，我们线上不少业务是长连接，这会导致无法生效，期待官方后面也能优化这方面的内容。","date":"2023-08-09","author":"李文杰","fillInMethod":"writeDirectly","customUrl":"multi-tenant-solution-tidb-7.1.0","file":null,"relatedBlogs":[{"relatedBlog":{"body":"## 导读\n\n资源管控技术（Resource Control）是 TiDB 7.0 版本中优化提升的重要能力之一，不仅可以在负载剧烈变化时，保证服务质量，同时提供了数据库的多租户隔离能力，能够有效地降低数据库运行成本，帮助企业节省信息化管理开支，提升企业的竞争力。  \n\n本文从将技术优势、配置方式、场景实践等角度详细解析 TiDB 7.0 版本中的资源管控技术。  \n\n作为可透明扩展的分布式数据库，TiDB 一直致力于满足企业对大型数据库集群的管理需要，集群内资源管控和资源隔离是企业客户长久以来的诉求之一。资源管控的主要目的在于解决数据库管理中常见的一些问题：  \n\n- 当多个业务共享同一数据库集群时，某个业务的非预期负载变化会影响其他业务的正常运行\n- 当集群中存在混合负载时，对资源需求较高的数据分析或批量作业会影响在线交易类业务的响应时间\n- 在需要 7x24 高可用性的业务系统中，数据备份、统计信息收集等后台任务可能会影响服务质量\n- 应用灰度上线时，小流量引发的性能问题仍可能“击穿”整个生产数据库\n\n为了解决上述场景中的问题，TiDB 开发了资源管控技术，于 TiDB 6.6 首次引入，并在 TiDB 7.0 进行了优化和增强。该技术利用资源组 (Resource Group) 将一个庞大的数据库集群划分为多个逻辑单元，每个资源组都能限制其所需的计算和 I/O 资源。通过特定设置，当集群有空闲资源时，允许一部分资源组超越其限制，以实现资源的充分利用。\n\n## 核心优势\n\n- TiDB 采用了业界领先的双层资源管控机制来实现更精确的管控。“流量控制”模块控制资源限额，确保仅在限额内的操作才能得以执行；“调度控制”模块则对队列中的任务设置不同的优先级，以确保在负载剧烈变化或超负荷运行时，高优先级的任务能够得到快速反馈。与同类产品通常只提供其中一层管控能力不同，TiDB 同时具备流控和调度控制能力，能够精确定义出更符合用户场景的配置。\n- 基于存储计算分离的架构，TiDB 的资源管控对最重要的 I/O 资源进行了限制。I/O 吞吐通常是数据库系统最常见的资源瓶颈，也是资源管控的难点，多数数据库产品并不支持对 I/O 进行控制。只有控制住主要瓶颈，才能保证在资源阻塞时有疏通调控的手段。\n- 把所有资源抽象成统一的单位来进行分配和限制。太过细粒度的设置通常难以衡量，也容易失去灵活性。TiDB 希望通过尽量少的指标来识别用户的意图，自适应地完成最佳的调度方案，提升易用性。\n- 除了隔离性，提升资源利用率也是 TiDB 资源管控的重要目标。在整体资源尚有空闲的情况下，允许部分业务超过资源组定义的限制。 \n- 提供用量统计的精确反馈， 通过监控面板获取实际用量的使用情况，协助用户合理改进配置。同时，配合企业管理目标，TiDB 能够协助企业精确统计各部门数据库资源的使用情况，进而完成合理的成本分摊。\n- 提供灵活的资源绑定手段。支持在用户级，会话级，和语句级指定资源的绑定方式，满足不同场景的资源控制需要。\n\n## 管理方式\n\n资源管控引入了“资源组(Resource Group)”的概念，通过设置“用户”和“资源组” 的对应关系，把会话与用户组进行绑定，利用“用量 (RU)”对资源限额进行定义。结构如下：\n\n![资源组结构.png](https://img1.www.pingcap.com/prod/_d377c2529e.png)\n\n### 资源组 (Resource Group)  \n\n资源组是资源管理的逻辑单元。任意一个会话属于唯一的资源组，而同一资源组的所有会话共享同一组资源限额。TiDB 支持数据库用户与资源组的映射关系，通过设置数据库用户的默认资源组，用户会话可以分属于不同的资源组。未指定默认资源组的用户，与系统内置的 default 资源组相关联。\n\n### 资源限额\n\nTiDB 首先支持为资源组配置用量 (RU)。RU (Request Unit) 是 TiDB 对 CPU、IO 等系统资源的统一抽象的单位，目前会考虑 CPU、IOPS 和 IO 带宽三个指标，按照一定的比例统一到 [RU 单位上](https://docs.pingcap.com/zh/tidb/v6.6/tidb-resource-control#什么是-request-unit-ru)。TiDB 支持设置资源组为 BURSTABLE 模式，BURSTABLE 模式允许资源组超额使用到集群的空闲资源。\n用户可以查看面板数据的反馈，以获取真实的用量请求和分配情况。通过对数据进行分析，来优化资源组的限额配置。配合真实负载的压力测试，用户还可以通过数据反馈得出整个系统的用量上限。\n\n### 调度优先级\n\n默认情况下，所有资源组的优先级 (PRIORITY)均为“中等(medium)”。当资源组在同一优先级下，调度优先级按照资源配额的比例分配，这已经能够满足绝大多数场景的需要。用户仍旧可以显式地指定资源组优先级为“高(high)”或者“低(low)”，从而完成更复杂的设定。比如，为一个算力需求不大，但优先级很高的应用配置资源组。\n\n### 资源组设定\n\n在 TiDB v7.0，用户能够通过以下方式指定资源组：\n- 用户级别。通过 `CREATE USER` 或 `ALTER USER` 语句将用户绑定到特定的资源组。绑定后，对应的用户新创建的会话会自动绑定对应的资源组。\n- 会话级别。通过 `SET RESOURCE GROUP` 设置当前会话的资源组。\n- 语句级别。通过优化器 hint `RESOURCE_GROUP()` 设置当前语句的资源组。\n\n### 配置步骤\n\n- 启用资源管控\n\n手工开启资源管控分两步进行（资源管控在 TiDB 7.0 中默认开启）：  \n\n1)设置 TiDB 全局变量启用“流量控制”：  \n```\nSET GLOBAL tidb_enable_resource_control = 'ON';\n```  \n\n2)在 TiKV 配置中将 `resource-control.enabled` 设为 `true` 启用“调度控制”  \n\n- 估算集群容量\n\n在资源规划之前，TiDB 提供了集群总用量(RU)的估算。需要注意的是，这个值是基于当前硬件配置结合平均负载经验得出的参考值，在运行用户实际应用时可能会有偏差。用户可以以此作为资源组起始规划的参考，后续再根据实际运行数据进行微调。  \n\n```\nCALIBRATE RESOURCE;\n```\n\n- 有了总容量的估算，此时我们可以根据实际业务目标规划和创建资源组。例如创建一个名为 rg1 的资源组，分配每秒 500 RU 的流量，并允许资源组在有空闲资源的情况下超限额分配。  \n\n```\nCREATE RESOURCE GROUP IF NOT EXISTS rg1 RU_PER_SEC = 500 BURSTABLE;\n```\n\n- 将用户 `usr1` 的资源组设置为 `rg1`\n\n```\nALTER USER usr1 RESOURCE GROUP rg1;\n```\n\n完成上述配置后，当系统繁忙时，用户 `usr1` 的所有会话使用的资源上限为 500 RU/秒；非繁忙时间段， `usr1` 则能够使用空闲集群资源。\n\n## 场景演示\n\n我们来看一个配置的示例。假定我们有三个租户分别运行三种不同的业务形态，每类业务有不同的管控目标：\n\n![三租户配置示例.png](https://img1.www.pingcap.com/prod/_963a4a6f64.png)\n\n对于以上这个需求，如果选择严格的多租户物理隔离，就不得不为每一个租户分配足够的资源，同时会造成 oltp 谷值负载时的资源浪费比较严重；而放入一套集群又无法消除租户 batch 对租户 oltp 的影响。利用 TiDB 既“隔离”又“融合”的资源管控技术，我们可以为这几类用户分别创建资源组：\n\n- 为租户 oltp 分配一个较高的用量，租户 batch 和 租户 hr 则相对低，这样在系统资源紧张的情况下，保证租户 oltp 的服务质量。\n- 租户 oltp 和 batch 的资源组设置为 burstable， 这样租户 oltp 发生超预期的负载，仍旧可能会保证质量；而当整个集群负载有空余时， 租户 batch 可以利用空闲资源加速其工作。\n\n![三租户配置示例-2.png](https://img1.www.pingcap.com/prod/2_79a66c4018.png)\n\n- 创建资源组\n\n```\nCREATE RESOURCE GROUP oltp  RU_PER_SEC=4000 BURSTABLE;\nCREATE RESOURCE GROUP batch RU_PER_SEC=400 BURSTABLE;\nCREATE RESOURCE GROUP hr    RU_PER_SEC=400;\n```\n\n- 创建租户对应租户，并设置其所属的资源组\n\n```\nCREATE USER 'oltp' RESOURCE GROUP oltp;\nGRANT ALL PRIVILEGES ON oltp.* TO 'oltp'@'%';\n\nCREATE USER 'batch' RESOURCE GROUP batch;\nGRANT ALL PRIVILEGES ON batch.* TO 'batch'@'%';\n\nCREATE USER 'hr' RESOURCE GROUP hr;\nGRANT ALL PRIVILEGES ON hr.* TO 'hr'@'%';\n```\n\n在完成以上简单的设置之后，我们来模拟几个租户不同的负载，观测吞吐量 (QPS) 和服务质量 (P99 响应时间）。整个场景模拟分为三个阶段：  \n\n1. 首先三类负载同时运行， 租户 oltp 设置为峰值负载。\n2. 切换租户 oltp 的负载到谷值，其他不变。\n3. 再次切换租户 oltp 的负载回到峰值。\n\n![三租户配置示例-3.png](https://img1.www.pingcap.com/prod/3_ec8c33d535.png)\n\n从实际数据来看，TiDB 资源管控技术在负载变化时的反馈非常及时。租户 oltp 的响应时间始终维持在较低的水平，租户 hr 的吞吐被限制在较低的范围内：\n\n1. 当租户 oltp 维持在峰值负载时， 它保持高吞吐和较低的响应时间；租户 batch 和 租户 hr 维持在低吞吐，由于租户 batch 可以使用空闲资源，因此吞吐要略高于租户 hr。\n2. 当租户 oltp 进入谷值负载，吞吐下降，其响应时间仍旧很低。这时由于租户 batch 的资源需求很大，因此它的吞吐迅速提升，响应时间下降， 租户 hr 仍旧被限制在其限额内。\n3. 当租户 oltp 重新回到峰值负载，租户 batch 则立即让出资源，使得租户 oltp 的吞吐再次回到之前的水平，响应时间维持不变。\n\n由此得出， 利用 TiDB 提供的资源管控和调度能力，多个不同诉求的租户能够共存在一套系统中，在保证各自服务目标的基础上，提升资源使用效率。\n\n## 资源管控技术协助企业兼顾质量与成本\n\n从上面的例子我们看到， 资源管控技术能够有效地解决在负载剧烈变化时，服务质量无法保证的问题。我们也可以利用这项技术防止未经验证的应用出现资源过载，比如新业务上线前的灰度测试，为资源组为灰度流量定义上限，避免局部性能问题引发大范围影响。  \n\n资源管控技术同时提供了数据库的多租户隔离能力，支持企业将中小型的系统进行合并，降低数据库运行成本。成本的节约主要来自几个方面：  \n\n- **节省预留资源**：一般来说，我们在规划单系统容量的时候，平均负载一般占到规划容量的 50% 甚至更低，留下足够的空间应对突发的性能抖动，以及未来可能的业务增长。而多个不相关的业务系统很少在同一时间出现负载波动，结合 TiDB 可透明扩展的特性，将这些系统合并到同一集群中，就不必预留相同比例的空间了。\n![节省预留资源.png](https://img1.www.pingcap.com/prod/_01adb7ab23.png)\n\n\n- **缓解峰值谷值波动**：如果将负载峰值与谷值不同的系统整合在一起，整合后的系统可以减少负载波动的幅度。在“削峰填谷”的作用下，资源利用率得到提升，低负载时段的硬件浪费也得到了减少。\n\n![缓解峰值谷值波动.png](https://img1.www.pingcap.com/prod/_9712ec1ec2.png)\n\n\n- **快速扩展与收缩**：企业经常需要为定期的业务活动增加临时的计算资源，以确保系统的稳定性。在多个业务系统合并的情况下，可以借助合理的业务规划，共享预留资源，轮流进行促销活动，而不必反复部署，节约重复的人力投入。\n\n- **提升运维效率**：将多个业务系统整合成一个系统，可以显著降低运维人员的投入。因为管理实体变少了，系统数量也减少到以前的几十分之一，运维难度和需要的人工成本都随之大大降低。\n\n这要求产品需要有很强的负载隔离能力，同时又能够将资源融合，正是 TiDB 资源管控技术想要达成的目标。\n\n## 未来展望\n\nTiDB 发布的资源管控能力是一个很好的开始，我们将沿着这个方向从多角度持续深耕这项技术，通过细粒度资源管控技术为客户创造更多的价值：  \n\n- **更多样的管控方式**： 根据场景的不同，为客户提供百分比，权重，用量等多种资源限额定义方式，并把 TiDB Cloud 中 Serverless 模式的计量方式和经验注入产品，协助客户运行自己的私有云服务，轻松完成成本分摊。扩展资源组的映射方式，支持除用户以外其他会话属性向资源组的映射。\n\n- **更多维的管控范围**： 除了最重要的 CPU 与 I/O 资源，持续延伸管控的范围和粒度，如分析型负载，内存使用，并行度等等。另外， 还将支持把运维操作和系统内部任务编入资源组， 协助客户做更精细的场景定义。\n\n- **更智能的管控手段**：通过分析历史运行数据，提供资源管理的建议，协助客户发现资源配置的潜在问题和风险，结合 TiDB Cloud 的部署运行经验，为客户提供更经济更合理的资源配置建议，协助企业的成本控制。\n\nTiDB 的弹性扩展特性和资源管控能力可以有效提高 IT 系统的效率，并协助企业降低 IT 运营的成本，同时确保系统的稳定性和安全性。随着资源管控技术的不断增强， TiDB 一定能够协助企业在数字化的道路上更加扎实地前进。","author":"宋日杰","category":1,"customUrl":"tidb-resource-control","fillInMethod":"writeDirectly","id":486,"summary":"资源管控技术是 TiDB 7.0 版本中优化提升的重要能力之一，不仅可以在负载剧烈变化时，保证服务质量，同时提供了数据库的多租户隔离能力，能够有效地降低数据库运行成本，帮助企业节省信息化管理开支，提升企业的竞争力。","tags":["Resource Control"],"title":"新特性解析丨TiDB 资源管控的设计思路与场景解析"}},{"relatedBlog":{"body":"![活动 banner.jpeg](https://img1.www.pingcap.com/prod/banner_8a580af0b8.jpeg)\n\nTiDB 7.1 是 2023 年度发布的首个 LTS（Long Term Support） 版本，汇集了来自 20+ 个真实场景带来的功能增强，累计优化和修复 140+ 功能，旨在提升关键业务的稳定性和性能，帮助开发人员和数据库管理员提高生产力并进一步降低总体拥有成本（TCO）。用户可在生产环境中使用 TiDB 7.1。\n\n## 半年版本回顾\n\nTiDB 7.1 LTS 距离上一个 LTS 版本 6.5 已经过去了整半年，在这期间，我们对产品的关键能力做了大量的增强和优化，其中最重要的特性有：\n\n- TiDB 7.0 提供了基于资源组的资源管控（Resource Control）：这使得 TiDB 在针对多租户场景有了很好的应对。事实上，经常有用户希望借助 TiDB 的可伸缩特性将多套业务系统归一到一个集群中，从而使得集群管理、资源利用都能得到有效的改进。资源管控特性提供了对多租户的支持，并解决了不同租户间资源争抢的问题。在新版本中，用户可以很方便地借助这个功能完善数据库整合的使用场景。\n- Multi-RocksDB 特性：借助将单一 TiKV 实例中的 RocksDB 拆成多份，TiKV 的写吞吐提升近三倍；此外，在新架构中数据分片（Region）大小将变得更大，由此减小维护分片所带来的开销，减少单位存储所需的固定 CPU 消耗，更节省成本。这使得大写入吞吐，或者需要大量存放温数据的 Data Serving 场景下，TiDB 的表现得到了本质的提升。\n\n对于这些重要的重量级特性，在新版本中也将持续得到打磨和加强。这半年中，TiDB 在一些关键场景的性能也得到长足提升：\n\n- 数据导入 Lightning 性能提升近 30%；\n- 真实业务测试下，Analyze Table 性能提升 42%+；\n- 标准测试 TPC-H 和真实业务测试下，TiDB 分析能力分别提升 15% 和 25%；\n- TiCDC 针对大型单表复制性能提升可达 90%+。\n\n## TiDB 7.1 介绍\n\nTiDB 7.1 是我们计划在 2023 年发布的两个长期可支持（LTS）版本中的第一个，它为您提供了一个面向未来的数据库，可以为各种关键业务应用程序提供动力。TiDB 7.1 为您带来：\n\n- 更稳定地支持关键业务负载，为 DBA 提供多工作负载稳定性控制，并显著改善尾部延迟；\n- 以更少的资源提供更佳的性能，通过架构增强实现更高的吞吐以及更快的在线 DDL。\n\n此外，TiDB 7.1 企业版增强了数据库审计功能，通过更细粒度的事件过滤控制、更友好的过滤条件设置方式、新增的 JSON 文件输出格式以及审计日志的生命周期管理，大幅提升系统的审计能力。\n\n### 更稳定地支持关键业务负载\n\n本节中的功能增强都属于集群稳定性的主题。更具体地说，即使在工作负载较大的情况下，TiDB 也可以保障稳定运行，并稳定处理具有特殊情况的工作负载的延迟。\n\n#### 通过资源组改进资源管控的用户体验，提供更好的隔离性\n\n我们在[文章（TiDB 7.0）](/blog/tidb-7.0-release)中介绍了通过资源组进行资源管控的功能，为 TiDB database consolidation （数据库整合）方案奠定了基础，具有里程碑的意义。多个业务可共享同一个 TiDB 集群，DBA 可为不同的工作负载设置资源配额和优先级，例如为关键业务分配更高的优先级，确保其能够优先获得资源，避免受到其他工作负载的干扰。\n\n在 TiDB 7.1 中，资源管控特性正式 GA 了，并加入了两个特性增强：\n\n- 降低了在重写入密集型工作负载中出现的尾延迟：资源组通过资源配额和优先级控制工作负载。优先级由存储级别控制。当工作负载写入繁重时，基于优先级重新调度机制有时会造成更高的尾延迟（Tail Latency）。在 7.1 版本中，尾延迟被修正到预期水准。\n- 增加原生负载校准工具，帮助用户设置更准确的资源资源分配：资源分配的基础是用户对负载的资源使用量有所了解。新增的校准工具将很好的帮助您评估相关信息，以合理配置资源组。最快的方法是从 SQL 接口运行校准命令来估计基准测试（如 TPC-C 和 sysbench）的资源使用情况。\n\n#### 多个热点场景下性能和稳定性提升\n\n对 TiDB 的底层行存储 TiKV 有三个关键增强，以降低延迟提升稳定性（通过 p99 延迟衡量）。新版本引入了三项优化，分别针对三个级别热点进行处理：Key 级别、分片（Region）级别和节点级别：\n\n- Key 级热点：锁冲突优化\n- Region 级热点：TiKV 子任务的批处理化\n- 节点级热点：引入了基于负载的副本读取\n\n**锁冲突优化（GA）**\n\nTiDB 引入了处理 Key 级热点的优化。在遇到许多单点悲观锁冲突的负载中，唤醒等待请求的算法在新版本中将表现得更稳定，最大限度地减少了重试的资源浪费，从而节省了整个集群的资源并降低了尾延迟。测试表明，当启用锁冲突优化时，如果吞吐量相对较小，即使在冲突最严重的工作负载中，新版本的尾延迟也将降低 40-60%。\n\n![QPS.png](https://img1.www.pingcap.com/prod/QPS_08931bca5b.png)\n\n![99 Latency.png](https://img1.www.pingcap.com/prod/99_Latency_b8134dcf7c.png)\n\n**批处理 TiKV 子任务（GA）**\n\n选择性较差的查询可能会导致需要读取许多数据。在 TiDB 的分布式存算分离架构中，这样的查询可能会带来数万或数十万个 RPC 请求用于获取数据，如果使用索引读取则将更进一步加重这一负担。\n\nTiDB 服务器作为 TiKV 客户端，现在可以识别针对同一分片的批处理任务，并将这些批量发送到对应的存储节点。这大大减少了网络的 RPC 开销，使得这些查询更稳定。这个增强可以将相应场景中的延迟减少多达 50%。\n\n**基于负载的副本读取（GA）**\n\n这个特性用于优化节点级读热点。当大批量查询以不均匀的方式发起读取，可能会出现节点热点。注入 Index Lookup JOIN 这类常见的事情都可能会导致这种情况。一旦发生，读取请求会排队，当队列塞满时，一些请求可能会等待相当长时间。我们希望通过更均匀地分配工作来减少延迟。\n\n新版本中，TiDB 引入了基于负载的副本读取来实现这一点。它为队列提供了一个可配置的持续时间阈值，当超过该阈值时，它会告诉 TiDB 开始优先考虑副本读取。在读热点的情况下，与不打散读热点相比，该功能可提高读取吞吐量 70%～200%。\n\n有关此优化的更多信息，请[参阅文档](https://docs.pingcap.com/tidb/dev/troubleshoot-hot-spot-issues#scatter-read-hotspots)。\n\n### 更少的资源，更佳的性能\n\n本节中的功能和改进，提升了 TiDB 读、写以及管理操作的性能，以提供更好的用户体验。新版本中，TiDB 增加了多值索引以提供对 JSON 的查询效率。此外，在写入吞吐、分析查询速度和后台任务效率方面也进行了大量的改进和优化。\n\n#### 多值索引（GA）以增加速度和灵活性\n\n多值索引也称为“JSON 索引”，这种新型辅助索引在 TiDB 6.6 中引入并在 7.1 中 GA。多值索引支持索引记录到数据记录的 N:1 映射，使得查询可以快速检查存储在 JSON 数组中的特定值。\n\n例如，假设您将这样的数据存储在列中：\n\n```\n{\n\n    \"user\":\"Bob\",\n\n    \"user_id\":31,\n\n    \"zipcode\":[94477,94536]\n\n}\n```\n\n无论该数据存储为 blob，还是邮政编码直接存储为 zip 数组，用户都可以创建多值索引来定位特定邮政编码存在于哪一行。\n\n索引是使用表达式创建的，该表达式将 JSON 数据逻辑解析为生成列（Generated Column）和该列上的二级索引。如果您将 JSON 存储为 blob，并且需要支持遍历多层嵌套的查询，您只需创建一个索引以检索。\n\n有关用法和注意事项的更多详细信息，请参阅[多值索引文档](https://docs.pingcap.com/tidb/dev/sql-statement-create-index/#multi-valued-index)。\n\n#### 更快的 TTL（GA）\n\nTTL (Time to live) 在我们的 [TiDB 6.5 发布的文章](/blog/tidb-6.5-release)中作为一个实验特性进行了介绍，而在 7.1 中这个特性 GA 了。此外在新版本中，TiDB 节点可以共享 TTL 相关任务并并发执行，从而拥有了更好的性能和资源利用率。\n\n#### 延迟物化加速分析查询（GA）\n\nTiFlash 是 TiDB 的列式存储引擎，在 7.1 版本中延迟物化特性 GA。当表扫描拥有高过滤性的时候，TiDB 优化器可选择让 TiFlash 启用延迟物化。开启该特性后，TiFlash 支持下推部分过滤条件到 TableScan 算子，即先扫描过滤条件相关的列数据，过滤得到符合条件的行后，再扫描这些行的其他列数据，继续后续计算，从而减少 IO 扫描和数据处理的计算量。\n\n此功能的影响取决于实际负载和数据分布。在某些情况下，它可以显著减少延迟（在我们的测试中延迟最高可降低 70%）。TiDB 的查询优化器可以决定是否使用它，默认情况下打开是安全的。\n\n#### Multi-RocksDB 存储引擎带来巨大性能提升\n\n在 TiDB 6.6 中，我们引入了对 TiKV 存储架构的重大更改。虽然这个架构仍然是实验性的（默认关闭，并且只能在新集群中启用），但在这个 LTS 版本中，该特性获得重大加强，并在预生产环境中收到了很好的测试反馈。\n\n在 TiDB 6.6 之前，单一 TiKV 节点所有 Region 共享一个 RockDB 存储引擎。新架构则将不同 Region 分别存放在不同 RocksDB。新架构的好处是显著的：\n\n- 减少 RocksDB 对应的 LSM 负担，增加了吞吐量，测试结果显示写入吞吐量增加了 200%。\n- 使用不同 RocksDB 也会减少 Compaction 带来的写放大，降低资源消耗。\n- 更好的写入吞吐使集群的扩展速度提高 500%。\n- 在测试一些真实的客户工作负载时，我们观察到尾部延迟减少了近 50%。\n- 更小的单位存储消耗，使得集群可扩展性进一步增强。\n\n在 TiDB 7.1 中，我们进一步提高了该特性的性能和稳定性，并添加了网络带宽优化。当前仍然缺失的是 TiCDC、BR 等生态工具的支持，当这些完成后我们将宣布这个特性 GA。\n\n有关更多详细信息，请[参阅产品文档](https://docs.pingcap.com/tidb/dev/partitioned-raft-kv)。\n\n#### Online DDL 的大幅提升（实验特性）\n\n在《[天下武功唯快不破：TiDB 在线 DDL 性能提升 10 倍](/blog/10-times-online-ddl-performance-improvement)》中，我们介绍了 TiDB 索引构建操作性能的提高方式，并在 7.0 版本 GA。在 TiDB 7.1 中，类似于前述 TTL 改进，我们引入了跨 TiDB 节点分配 DDL 作业的框架，以进一步提高性能。\n\n## 立即体验 TiDB 7.1\n\n浏览 [TiDB 7.1 Release Notes](https://docs.pingcap.com/zh/tidb/stable/release-7.1.0)，下载 TiDB [社区版](/product-community/)，了解更多新增和优化特性。\n\n\n<div class=\"is-flex is-flex-direction-row is-justify-content-center\">\n  <div class=\"is-flex is-flex-direction-column\">\n    <a target=\"_blank\" class=\"button is-link mx-5\"\n       href=\"/product-community/\"\n       style=\"background-color: #4fc172;\">\n      下载 TiDB 社区版\n    </a>\n  </div>\n  <div class=\"is-flex is-flex-direction-column\">\n    <a target=\"_blank\" class=\"button is-link mx-5\"\n       href=\"https://pingcap.com.cn\"\n       style=\"background-color: #3a40e1;\">\n      了解 TiDB 企业版\n    </a>\n  </div>\n  <div class=\"is-flex is-flex-direction-column\">\n    <a target=\"_blank\" class=\"button is-link mx-5\"\n       href=\"https://tidbcloud.com/free-trial?utm_source=website-zh&utm_medium=referral&utm_campaign=blog-tidb-7.0-release\"\n       referrerpolicy=\"no-referrer-when-downgrade\" style=\"background-color: #3a40e1;\">\n      免费试用 TiDB Cloud\n    </a>\n    <div style=\"font-size:12px; text-align:center\">适用于中国出海企业和开发者</div>\n</div>\n","author":"PingCAP","category":2,"customUrl":"tidb-7.1-release","fillInMethod":"writeDirectly","id":492,"summary":"TiDB 7.1 是 2023 年度发布的首个 LTS 版本，汇集了来自 20+ 个真实场景带来的功能增强，累计优化和修复 140+ 功能，旨在提升关键业务的稳定性和性能，帮助开发人员和数据库管理员提高生产力并进一步降低总体拥有成本。","tags":["TiDB","Release"],"title":"TiDB 7.1 LTS 发版：为关键业务提供业务稳定性和多租户场景支持"}}]}}},
    "staticQueryHashes": ["1327623483","1820662718","3081853212","3430003955","3649515864","4265596160","63159454"]}