{
    "componentChunkName": "component---src-templates-blog-blog-detail-tsx",
    "path": "/blog/tidb-7.1-release",
    "result": {"pageContext":{"blog":{"id":"Blogs_492","title":"TiDB 7.1 LTS 发版：为关键业务提供业务稳定性和多租户场景支持","tags":["TiDB","Release"],"category":{"name":"公司动态"},"summary":"TiDB 7.1 是 2023 年度发布的首个 LTS 版本，汇集了来自 20+ 个真实场景带来的功能增强，累计优化和修复 140+ 功能，旨在提升关键业务的稳定性和性能，帮助开发人员和数据库管理员提高生产力并进一步降低总体拥有成本。","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","date":"2023-06-06","author":"PingCAP","fillInMethod":"writeDirectly","customUrl":"tidb-7.1-release","file":null,"relatedBlogs":[{"relatedBlog":{"body":"![TiDB 7.0发版.jpeg](https://img1.www.pingcap.com/prod/Ti_DB_7_0_dd0bec1e31.jpeg)\n\n我们很高兴地宣布，TiDB 7.0 正式发布。TiDB 7.0 聚焦于帮助用户通过可靠性能和简化数据库操作来快速响应业务需求，从而满足客户的高期望值，并提升开发人员和 IT 运维人员的生产力。新版本中，TiDB 在可扩展性与性能、稳定性与高可用、SQL 以及可观测性几个领域获得持续提升，累计引入新特性 20 余项，优化功能 50 余项。TiDB 7.0 是 TiDB 7 系列首个 DMR 版本，适用于开发、测试和 PoC 等场景。\n\n在 7 系列版本以及之后 2-3 年的时间里，我们希望 TiDB 在不断迭代中拥有：\n\n- 更强的基础能力（核心性能，扩展性，性价比，云原生等）；\n- 更加多元化的场景支持（多租户，更多数据模型支持，更好的生态适配）；\n- 更顺滑的运维体验（更强的 DDL 能力，以 SQL 为统一界面的运维体验等，智能运维）；\n- 更可靠更安全（更高的可用性，更好的安全体系整合，更多合规认证）。这些主题都将逐步在 7 系列以及后续版本中落实，给予用户更优的使用体验，让 TiDB 变成一个好用且泛用，可靠且经济的选择。具体到 7.0 版本，TiDB 初步提供了更好的资源管控能力，让 TiDB 针对 SaaS 和多平台统一共存等场景有了根本性的解决方案；其次，TiFlash 发布了面向云的存算分离新架构，这使其可以真正做到存算资源解耦，计算资源可以按需启停，且基于 S3 的存储设计也将大幅降低存储成本；而诸如分析引擎支持落盘，自动执行计划缓存等，则是针对企业级场景做出的必要强化；最后，TiDB 7.0 提供了对 MySQL 8.0 的兼容，这将使得相关用户能更方便地迁移到 TiDB。\n\n接下来让我们具体看看新版本的情况。\n\n## 资源管控增强多租户形态下工作负载稳定性\n\n资源管控特性（Resource Control）在 TiDB 6.6 中引入（实验特性），在 TiDB 7.0 中得到增强和优化，极大地提升 TiDB 集群的资源利用效率和性能表现，为稳定的多租户奠定了基础。资源管控特性对 TiDB 具有里程碑的意义，用户可以将一个分布式数据库集群划分成多个逻辑单元，将不同的数据库用户映射到对应的资源组中，并根据需要设置每个资源组的配额。该功能允许为一个或多个会话组设置资源上限，如果来自某个工作负载或应用程序的消耗异常重，则其资源消耗将被限制在配额内，以防止对其他更关键的工作负载造成干扰。  \n\n资源管控适用于以下场景：  \n\n- 用户可以将多个应用程序合并到单个 TiDB 集群中，降低 TCO 并保证重要工作负载所需的资源。\n- 用户可以在业务运营时间内安全运行批处理任务。\n- 模拟环境（Staging Environments）可共享具有受资源管控限制的单个 TiDB 集群。\n\n会话可通过三种方式绑定到资源组：通过 `CREATE USER` 或 `ALTER USER` 语句将用户绑定到特定的资源组，使得用户会话始终受到设定边界约束；通过 `SET RESOURCE GROUP` 设置当前会话的资源组；也可通过优化器 Hint `RESOURCE_GROUP()` 设置当前语句的资源组。\n\n## TiFlash 支持数据落盘来稳定分析工作负载\n\nTiFlash 是 TiDB 的列存储和计算引擎，是数据库分析工作负载能力的支柱。在 TiDB 7.0 之前，TiFlash 在内存中处理所有数据。从这个版本开始，TiFlash 支持数据落盘功能（Spill to disk），通过调整算子内存使用阈值，控制对应算子的最大内存使用量。对于大查询而言，当算子使用内存超过一定阈值时会自动将数据落盘，牺牲一定的性能换取整体分析查询的稳定性。数据落盘操作根据用户配置参数进行，并适用于单个推送下去的操作。由于该优化发生在单个运算符级别上，因此必须在多个位置执行数据落盘操作。在 TiDB 7.0 中，它首先被应用于以下情况：  \n\n- 相等条件下的哈希连接；\n- GROUP BYs 上的哈希聚合；\n- 窗口函数中 TopN 和排序运算符。\n\n在执行这些操作期间，如果运算符使用的内存量超过了配置限制，会自动将数据落盘并继续进行后续处理。为了说明目标工作负载受影响程度，我们模拟了决策支持系统，使用 TPC-H 基准测试工具进行测试，结果如下表所示：  \n\n![TPC-H 基准测试工具测试结果.png](https://img1.www.pingcap.com/prod/TPC_H_54be3f1f7f.png)\n\n## 自动计划缓存减少查询延迟  \n\n在此之前，TiDB 已经支持使用 PREPARE 准备语句来进行计划缓存。TiDB 7.0 中，非 Prepare 语句的执行计划也能够被缓存，使执行计划缓存能够应用于更广泛的场景。该功能支持在会话级别上对查询进行缓存，全局级别的支持将在未来发布中推出。会话级别的缓存将减少由于查找正确计划而导致的延迟，但可能也会增加全局缓存中可能存在重复数据时所需内存。目前可以通过此功能进行单表过滤和范围查询类型的查询进行缓存，但不能够处理单表复杂查询和 JOIN 查询等其他类型。  \n\n## TiFlash 支持存算分离架构，降低数据分析成本\n\n在 TiDB 7.0 版本，TiFlash 支持存算分离和 S3 对象存储（实验特性）。之前版本的 TiFlash 是存算一体架构，TiFlash 节点既是存储节点，也是计算节点，其计算和存储能力扩展受到一定限制。同时，TiFlash 节点只能使用本地存储。在 7.0 版本中，TiFlash 支持存算分离架构，分为 Write Node 和 Compute Node 两种节点，可以分别部署，单独按需扩展，并支持将数据存储在 Amazon S3 或兼容 S3 API 的对象存储中。  \n\n![TiFlash 存算分离架构.png](https://img1.www.pingcap.com/prod/Ti_Flash_4db2295760.png)\n<center>图：TiFlash 存算分离架构</center>\n\nTiFlash 存算分离架构适用于高性价比的数据分析场景。在数据量很大，但是只有少量数据被频繁查询，大部分冷数据很少被查询的场景下，将经常被查询的数据缓存在 Compute Node 的本地 SSD 上，可以提供较快查询性能，将大量冷数据存储在成本较低的 S3 或者其他对象存储上，从而节省存储成本。在计算资源需求有明显的波峰和波谷场景下，例如晚上执行的重型对账查询，对计算资源要求较高，可以临时扩展 Compute Node，其他时间可以用较少的 Compute Node 完成查询任务。TiFlash 的存算分离架构大幅降低了使用 TiFlash 支持分析工作负载的成本，并且提供了一定程度的工作负载隔离。目前，TiUP 和 TiDB Operator 已经支持部署和缩放 TiFlash 独立组件的能力。  \n\n## TTL 定期删除过期数据为系统减负\n\nTiDB 6.5 引入了 Time to live（TTL）实验特性，提供了行级别的生命周期控制策略，该项特性在 TiDB 7.0 中正式 GA。TTL 是一种通过 SQL 配置设置表中行到期时间的方式，帮助用户周期性且及时地清理不需要的数据，并尽量减少对用户负载的影响。TTL 以表为单位，并发地分发不同的任务到不同的 TiDB Server 节点上，进行并行删除处理。在某些情况下，较大的表格意味着查询时间更长；较大的表格意味着更多的存储成本；在 TiDB 中，一个表越大，Region 就越多，限制表格大小可以减轻系统负担；各种合规性要求可能需要设置数据过期。基于成本、性能或安全等因素考虑，数据库管理员可以配置自动检查并删除过期的表格行数据，例如定期删除验证码、短网址记录、不需要的历史订单、计算的中间结果等。  \n\n## 使用 Key 分区提高可扩展性  \n\n在 7.0 之前，TiDB 支持 Hash、Range 和 List 分区。新版本引入了 key 分区，与 Hash 分区类似，Key 分区可以保证将数据均匀地分散到一定数量的分区里面。Hash 分区只能根据一个指定的整数表达式或字段进行分区，而 Key 分区可以根据字段列表进行分区，且 Key 分区的分区字段不局限于整数类型。Key 分区提供了一种更灵活的方式来对数据集进行划分以改善集群的可扩展性。\n\n## 使用 REORGANIZE PARTITION 适应不断变化的需求  \n\nTiDB 长期以来一直支持分区，修改分区表的唯一方法是添加或删除分区和截断 LIST/RANGE 分区。TiDB 7.0 TiDB 支持 ALTER TABLE... REORGANIZE PARTITION 语法，用户可以对表的部分或所有分区进行重新组织，包括合并、拆分、或者其他修改，并且不丢失数据，增加了可用性和灵活性以满足不断变化的需求。  \n\n## 使用 LOAD DATA 从远程存储导入数据  \n\nTiDB 7.0 中，`LOAD DATA` 语句集成 TiDB Lightning，用户可以使用 `LOAD DATA` 语句完成原先需要使用 TiDB Lightning 才能完成的数据导入任务（实验特性），不仅可以省去 TiDB Lightning 的部署和管理成本，还可以借助 TiDB Lightning 的功能极大扩展 `LOAD DATA` 语句的能力，包括：支持从 Amazon S3 和 Google Cloud Storage 导入数据到 TiDB，且支持使用通配符一次性匹配多个源文件导入到 TiDB；支持查询任务状态，添加操作便利性等。  \n\n浏览 TiDB 7.0.0 [Release Notes](https://docs.pingcap.com/zh/tidb/v7.0/release-7.0.0)，了解更多新增和优化特性。立即下载试用，开启崭新的 TiDB 探索之旅。企业级用户期待的 TiDB 7.1 LTS 版本将很快与大家见面，敬请期待！\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</div>\n","author":"PingCAP","category":2,"customUrl":"tidb-7.0-release","fillInMethod":"writeDirectly","id":473,"summary":"TiDB 7.0 聚焦于帮助用户通过可靠性能和简化数据库操作来快速响应业务需求，从而满足客户的高期望值，并提升开发人员和 IT 运维人员的生产力。","tags":["TiDB","Release"],"title":"TiDB 7.0 发版"}},{"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 资源管控的设计思路与场景解析"}}]}}},
    "staticQueryHashes": ["1327623483","1820662718","3081853212","3430003955","3649515864","4265596160","63159454"]}