{ "componentChunkName": "component---src-templates-blog-blog-detail-tsx", "path": "/blog/tidb-7.2-release", "result": {"pageContext":{"blog":{"id":"Blogs_494","title":"TiDB 7.2 - 更平滑的操作体验","tags":["TiDB","Release"],"category":{"name":"产品技术解读"},"summary":"TiDB 7.2 致力于简化数据管理，引入了暂停和恢复 DDL 操作、资源组控制查询影响以及将 TiDB Lightning 导入服务整合到 TiDB 中的功能。","body":"关系型数据库管理系统（RDBMS）的世界正在发生变化，分布式架构和大数据规模下的一致性比以往任何时候都更加必要。分布式SQL引擎的创造者和维护者面临着提供易用性的新范式。虽然 PingCAP 一直将此作为首要任务，但 TiDB 7.2 则直接致力于使 TiDB 数据的管理更加容易。\n\n*版本 7.2 是一个开发里程碑版本（DMR），旨在引入实验性功能，因此不适用于生产环境。对于生产部署，请参考我们最新的稳定版本（LTS）7.1，以及[相应的博客](/blog/tidb-7.1-release)。*\n\n与所有 TiDB 发布博客一样，本文专注于版本发布的主要功能亮点。有关版本的更全面信息，请参阅文档中的官方[发布说明](https://docs.pingcap.com/zh/tidb/v7.2/release-7.2.0)。\n\n## 暂停和恢复 DDL 以优先处理关键流量\n\n在前序版本中，TiDB 极大提高了 DDL 尤其是添加索引的速度。即便如此，构建索引仍然是数据库相对最为昂贵的操作之一。在线 Schema 变更使得 TiDB 的用户可以不用因此暂停业务，但数据重组的在线性质可能会对前台工作负载产生影响，尤其是对延迟和抖动敏感度高的在线业务：数据规模越大，耗时越长，您的在线流量暴露的风险就越高。虽然用户可以通过限制并发度来减少对前台流量的干扰。然而，即使如此，仍然可能会出现资源干扰的情况。\n\n为了解决这类问题，TiDB 7.2 引入了在 DDL 操作暂停能力：用户可以暂停正在进行的 DDL 操作，并在合适的时机恢复操作。\n\n总体而言，这使 DDL 操作能够在大规模数据重组对性能的影响提供了手动干预的手段，并且无需重新启动操作而因此丢失 DDL 操作进度。\n\n## 通过资源组控制不良查询的影响\n\n在最新的[稳定版本 7.1 ](/blog/tidb-7.1-release)中，通过资源组实现资源控制的功能正式 GA。该功能的目的是在同一集群上保持多个独立工作负载的性能稳定。该功能的底层机制也正好适用于一些可操作性的增强。\n\nTiDB 7.2 基于执行时间引入了基于[资源组](https://docs.pingcap.com/zh/tidb/stable/tidb-resource-control)的全局查询超时概念，并将该控制功能提升到资源组的层面，使其更加细粒度。现在，归类为业务逻辑组的查询可以拥有自己的超时设置，避免了在集群中为所有工作负载和查询组确定“一刀切”的超时时间的需求。\n\n## 从远程对象存储中导入到 TiDB\n\n如果您是当前的 TiDB 用户，您可能已经熟悉导入服务 [TiDB Lightning](https://docs.pingcap.com/zh/tidb/stable/tidb-lightning-overview)。它是一个独立的服务，具备完整的导入功能，可以通过事务层逻辑方式和通过文件系统直接进行物理导入数据。\n\n为了使从其他来源加载数据更简单，并且避免用户需要部署这个独立的服务，TiDB 7.2 将 Lightning 的物理导入服务整合到 TiDB 本身中。通过直接整合到 TiDB 中，不仅部署变得更简单，而且还为管理数据加载提供了一个 SQL 接口。在这里包含 Lightning 的功能还意味着可以直接从 AWS S3 和 Google Cloud Storage (GCS) 加载数据。\n\n有关更多信息，请[参考文档](https://docs.pingcap.com/zh/tidb/v7.2/release-7.2.0)。","date":"2023-07-19","author":"PingCAP","fillInMethod":"writeDirectly","customUrl":"tidb-7.2-release","file":null,"relatedBlogs":[{"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
\n
\n \n 下载 TiDB 社区版\n \n
\n
\n \n 了解 TiDB 企业版\n \n
\n
\n \n 免费试用 TiDB Cloud\n \n
适用于中国出海企业和开发者
\n
\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"]}