{ "componentChunkName": "component---src-templates-blog-blog-detail-tsx", "path": "/blog/tidb-6.0-make-tso-more-efficient", "result": {"pageContext":{"blog":{"id":"Blogs_399","title":"TiDB 6.0：让 TSO 更高效丨TiDB Book Rush","tags":["TiDB"],"category":{"name":"案例实践"},"summary":"TSO 是 TiDB 中一个单调递增的时间戳，由 PD leader 分配。TiDB 在事务开始时会获取 TSO 作为 start_ts、提交时获取 TSO 作为 commit_ts，依靠 TSO 实现事务的 MVCC。本文介绍了 TiDB 6.0 版本中对 TSO 分配优化的原理和验证。","body":"> 本文源自“TiDB 6.0 Book Rush” 投稿。作者：h5n1，TiDB 爱好者，目前就职于联通软件研究院。\n\n## 前言\n\nTiDB 作为一个分布式数据库，计算节点 tidb server 和存储节点 tikv/tiflash server 有着近乎线性的扩展能力，当资源不足时直接在线扩容即可。但作为整个集群大脑的 PD 节点因为只有 leader 提供服务，不能像其他组件一样通过扩展节点而提高处理能力。\n过往版本 TSO 分配的主要问题： \n\n1. TSO 分配由 PD Leader 节点提供，大量请求下会导致 Leader 节点 CPU 利用率增高，影响事务延迟。\n2. PD Follower 节点基本处于空闲状态，系统资源利用率较低。\n3. TiDB 跨数据中心访问 PD Leader 时，数据中心间的延迟导致事务延迟增加。\n\n为提升 TSO 的处理性能针对部分场景 TiDB 引入了 TSO Follower Proxy、RC Read TSO 优化、Local TSO 等特性，通过扩展 PD 处理能力和减少 TSO 请求的方式，提升整体吞吐量，降低事务延迟。\n\n## TSO\n\nTSO 是一个单调递增的时间戳，由 PD leader 分配。TiDB 在事务开始时会获取 TSO 作为 start_ts、提交时获取 TSO 作为 commit_ts，依靠 TSO 实现事务的 MVCC。TSO 为 64 位的整型数值，由物理部分和逻辑部分组成，高 48 位为物理部分是 unixtime 的毫秒时间，低 18 位为逻辑部分是一个数值计数器，理论上每秒可产生 262144000（即 2 ^ 18 * 1000）个 TSO。\n\n![TSO.png](https://img1.www.pingcap.com/prod/TSO_62d940cb5c.png)\n\n为保证性能 PD 并不会每次为一个请求生成一个 TSO，而是会预先申请一个可分配的时间窗口，时间窗口是当前时间和当前时间+3 秒后的 TSO，并保存在 etcd 内，之后便可以从窗口中分配 TSO。每隔一定时间就会触发更新时间窗口。当 PD 重启或 leader 切换后会从 etcd 内获取保存的最大 TSO 开始分配，以保证 TSO 的连续递增。\n\n## Follower Proxy\n\n默认情况下 TSO 请求由 PD leader 处理，TiDB 内部通过 PD Client 向 PD leader 发送请求获取 TSO，PD client 并不会将收到的请求立刻发送给 PD leader ，而将同一时刻收到的所有请求打包发送给 PD leader，然后由 PD leader 返回一批 TSO。由于仅有 leader 提供服务，tidb server 数量较多时会有较多的 PD Client 和 PD Leader 建立连接，导致切换处理连接请求时 CPU 消耗较高。同时 follower 节点仅通过 raft 同步数据和提供选举等功能，基本处于空闲状态。 \n\n在 5.3.0 版本引入 TSO Follower Proxy 功能，当开启后 TiDB 的 PD Client 会随机选择一个 PD 节点（包括 leader 和 follower）发送 TSO 请求，PD Follower 会作为一个代理服务将收到的一批请求按照默认情况下 PD Client 处理 TSO 方式打包发送给 leader 处理，以进一步减少 PD Client 和 PD Leader 的交互次数以及 PD leader 的连接数，以此降低 leader 的 CPU 负载。 \n\n![TSO Follower Proxy.png](https://img1.www.pingcap.com/prod/TSO_Follower_Proxy_30f4e79c8e.png)\n\n通过设置全局变量 tidb_enable_tso_follower_proxy 为 true 即可开启 PD follower 的 TSO 代理功能，该功能适用于 tidb server 数量较多并发请求很高，PD leader 因高压力的 TSO 请求而达到 CPU 瓶颈，导致 TSO RPC 请求的延迟较高的场景。\n\n## RC Read TSO 优化\n\nRead-Commited 隔离级别需要在悲观事务模式下，在悲观事务中每个 SQL 执行时会从 PD 获取 TSO (for_update_ts) 用于一致性读、冲突检测等，每个 SQL 相当于一个 Snapshot-Isolation 的’小事务’，相比乐观事务模式悲观事务产生的 TSO 请求会更多，在整个事务期间如果能在不破坏事务一致性和隔离性的情况下减少 tso 请求次数，就能够降低 PD 的负载和事务延迟，从而提升整体性能。 \n\n6.0 版本中对 RC 事务中的 SELECT 语句 TSO 请求做了优化，使用一种乐观方式获取 TSO ，仅当遇到新版本后才会获取最新的 TSO 读取数据，通过减少读操作从 PD 获取 TSO 的请求次数，从而降低查询延迟，提升读写冲突较小场景的 QPS。该特性由 tidb_rc_read_check_ts 变量控制，默认为 off，开启该功能设置为 on 即可。 \n\n优化后 select 语句处理基本过程如下： \n\n1. Select 语句执行时不从 PD 获取 TSO 作为 for_update_ts，而是使用上一个有效的 TSO 作为 for_update_ts（即为 read_ts）。如果是事务中的第一个语句则是 start_ts，否则是上一个 SQL 的 for_update_ts。\n2. 构建执行计划并执行，发送到 tikv 的数据读取请求（pointget、coprocessor）会带上 RcReadCheckTS 标志。\n3. 数据读取请求使用前面获得的 read_ts 做一致性读取，并将数据返回 tidb server。\n4. TiKV 会检查返回的数据是否有更新版本，如果有更新的版本则返回 WriteConflict 错误，否则返回数据后正常结束执行。\n5. 如果此时 tidb 还未向 client 发送数据则会从 PD 获取最新的 TSO 作为 for_update_ts 重新执行整个查询，否则会向 client 返回错误。 \n\n从上面的过程可以看出遇到新版本会导致 tidb server 使用正常的流程重新获取 TSO 和执行 SQL，在读写冲突的情况下会降低性能使得事务执行时间延长。如果已经有部分数据返回 client 的话会导致报错 SQL 执行失败，虽然通过增加 tidb_init_chunk_size 变量大小延迟 tikv 返回数据时间，可以降低一些上述错误发生的情况，但仍然不是一个根本解决方式。 \n\n## Local TSO\n\n在多数据中心场景下 PD leader 位于某个数据中心内，数据中心间的延迟会造成 TSO 请求延迟增加，如果能够在数据中心内完成 TSO 请求和分配则可以大大降低 TSO 请求延迟。基于此 TiDB 引入了 Local TSO （实验功能），PD 中设计 2 个 TSO allocator 角色：local tso allocator 和 global tso allocator，相应的事务也被分成了本地事务 local transaction 和全局事务 global transaction 两种。 \n\n### Local TSO\n\n当通过 enable-local-tso 启用后数据中心内的 PD 会选出一个节点作为 local tso allocator 用于分配 TSO，该节点作为 local tso 分配的 leader 角色（PD 角色仍为 follower）。当事务操作的数据仅涉及到本数据中心的数据时，则判断为本地事务，向本地 tso allocator 申请 local tso。 \n\n每个数据中心分配自己的 local tso，相互之间是独立的，为避免不同数据中心分配了相同的 TSO，PD 会设置 local tso 中的逻辑时间低几位做后缀，不同的数据中心使用不同的值，同时这些信息会持久化记录到 PD 内。\n\n### Global TSO\n\n当事务操作的数据涉及到其他数据中心时则为全局事务，此时需要向 PD leader 申请 global tso， PD leader 作为 global tso allocator。当未启用 local-tso 功能时，仍按原来的逻辑所有数据中的 TSO 请求由 PD leader 负责处理。 \n\n为保证 local tso 和 global tso 的线性增长，global tso allocator 和 local tso allocator 会进行 max_tso 同步： \n\n1. Global tso allocator 收集所有 local tso allocator 的最大 local tso。\n2. 从所有 local tso 中选出一个最大的 local tso 作为 max_tso 下发到 local allocator。\n3. 如果 max_tso 比自己的大则更新 TSO 为 max_tso，否则直接返回成功。\n\nLocal tso 的使用需要考虑不同的数据中心处理不同的业务，同时要结合 PlacementRules in SQL 将表根据业务规则按数据中心进行分布，同时可设置 txn_scope 变量为 local/global 用于人为控制获取 global tso 还是 local tso。 \n\n基本配置步骤（目前不支持 Local TSO 回退为 Global TSO 模式）： \n\n1.PD、TiKV、TiDB server 均需要根据实际部署设置 label，为保证高可用每个 DC 的 PD 数量应>1。\n\n![label 设置 1.jpeg](https://img1.www.pingcap.com/prod/label_1_ab2bdf4afc.jpeg)\n\n![label设置2.jpeg](https://img1.www.pingcap.com/prod/label_2_0c6212e0ec.jpeg)\n\n2.开启库或表级 Placement Rules in SQL，根据地域和业务关系进行调度。 \n\n```\nCREATE PLACEMENT POLICY dc1_leader LEADER_CONSTRAINTS=\"DC1\" FOLLOWER_CONSTRAINTS=\"DC1,DC2,DC3\" FOLLOWERS=2;\nAlter table new_order PARTITION p0 PLACEMENT POLICY dc1_leaders\n```\n3.设置 PD 参数 enable-local-tso=on 使用 tiup reload 重启 PD 开启 Local TSO 功能。启用之后可通过 `pd-ctl -u pd_ip:pd_port member` 中 `tso_allocator_leaders` 项内容查看每个中心的 local tso allocator leader。\n\n![设置 pd 参数.jpeg](https://img1.www.pingcap.com/prod/pd_99fad1fe4f.jpeg)\n\n\n## 测试\n\n### 测试环境\n\n![测试环境.png](https://img1.www.pingcap.com/prod/_66b447f291.png)\n\n### TSO Follower Proxy\n\n在 1024 线程下使用 sysbench 对 6 张 1 亿记录表在开启 TSO Follower Proxy 前后的 TPS 和平均延迟如下：\n\n![sysbench.png](https://img1.www.pingcap.com/prod/sysbench_a559fc6673.png)\n\n测试期间 TSO Follower Proxy 关闭和开启时的 CPU 利用率： \n\n![CPU 利用率.jpeg](https://img1.www.pingcap.com/prod/CPU_31486267fc.jpeg)\n\n### RC Read TSO\n\n使用 tiup-bench 测试不同线程下开启 tidb_rc_read_check_ts 前后的 TPCC，可以看到开启该功能后对 TPCC 有一定提升，但随着线程数增加冲突增多 TPCC 出现下降情况。\n\n![tiup-bench.png](https://img1.www.pingcap.com/prod/tiup_bench_2a8d585e02.png)\n\n通过 TiDB –> PD Client –> PD Client CMD OPS 监控可以看到 256 线程下开启 tidb_rc_read_check_ts 后 PD client 中等待 TSO 的次数明显降低。\n\n![OPS 监控.png](https://img1.www.pingcap.com/prod/OPS_63d7318b7c.png)\n\n### Local TSO\n\nLocal TSO 作为实验功能尚需完善，TPCC 测试中当开启该功能后出现大量报主键重复错误。\n![local TSO.png](https://img1.www.pingcap.com/prod/local_TSO_bdd1cf8a8e.png)\n\n## 总结\n\n为提升 TSO 的扩展性和效率，TiDB 进行了大量的优化工作，但这些优化有确定的场景，需要结合业务和实际情况考虑，否则盲目开启有可能会造成 QPS 降低、延迟增高的情况： \n\n1. 对于 Follower TSO Proxy 适合于由于 PD Leader CPU 繁忙导致的 TSO 获取延迟的场景，通过开启 Follower Proxy 后降低 leader 的压力。\n2. RC Read TSO 优化适合于读多写少的场景，如果数据冲突严重反而会造成性能下降。\n3. Local TSO 作为 TiDB 分布式授时方案从理论上能够解决因数据中心间的延迟造成的 TSO 延迟，不过目前实验功能尚有一些问题，将在后续版本不断改进。","date":"2022-06-23","author":"h5n1","fillInMethod":"writeDirectly","customUrl":"tidb-6.0-make-tso-more-efficient","file":null,"relatedBlogs":[{"relatedBlog":{"body":"![TiDB 6.0.jpeg](https://img1.www.pingcap.com/prod/Ti_DB_6_0_67ed961868.jpeg)\n\n## 概览\n\n我们很高兴为大家带来 TiDB 最新版 6.0 的介绍。虽然是一个开源数据库，但 TiDB 的定位一直都是面向企业级和云的数据库，而 TiDB 6.0 也是围绕这个主题而研发的。在最新版本中，我们大幅度加强了作为企业级产品的可管理性，与此同时也加入了诸多云原生数据库所需的基础设施。\n\n对于企业级和云数据库，除了性能，可用性和功能等常规维度外，一个重要维度就是可管理性。除了提供必备的「硬」能力以完成用户的技术及业务目标，是否「好用」，是用户做选择时的重要考量，可管理性维度也会很深地影响用户实际使用数据库的隐性成本。而这点对于云数据库则更为明显，将数据库作为云服务提供，将使得可管理性的重要程度被放大：一个可运维性更好的数据库，在固定的运维和支持资源下，将为用户提供更好的服务。\n\n针对这个方向，TiDB 6.0 引入数据放置框架（Placement Rules In SQL），增加了企业级集群管理组件 TiDB Enterprise Manager ，开放了智能诊断服务 PingCAP Clinic 的预览，大幅加强了生态工具的可运维性，并针对热点问题为用户提供了更多的手段。这些努力加在一起，将使用户无论使用的是公有云服务，还是私有部署，都获得体验更平滑和近似的使用体验，让 TiDB 在成熟的企业级云数据库维度更向前迈进。\n\n除此之外，在这一年的时间内 TiDB 6.0 相较于前序版本也有了长足的进步，修复了 137 个 Issues，并融入了 77 个严苛的真实环境锤炼带来的增强。而社区一直期望的 [TiFlash 开源](https://github.com/pingcap/tiflash)也实现了，欢迎广大社区开发者一起参与。\n\n
\n
\n \n 下载 TiDB 社区版\n \n
\n
\n \n 了解 TiDB 企业版\n \n
\n
\n \n 免费试用 TiDB Cloud\n \n
适用于中国出海企业和开发者
\n
\n
\n\n## 全面加强可管理性\n\n可管理性是数据库的一个重要能力维度：在满足业务需求的前提下，是否灵活易用，将决定了用户技术选择背后的隐性成本。这种成本可大可小，可以是一句抱怨，也可能会结合人因带来灾难性后果。在最新版本研发过程中，我们结合了客户和市场反馈，总结了当前的可管理性的问题仍存在的缺失，这包含了「复杂且不直观的集群的日常管理」、「无法控制数据的存储位置」、「数据生态套件难于使用」、「面对热点缺少解决方案」等多个维度，而 TiDB 6.0 从内核、数据生态套件、增强组件多个方面针对这些问题进行了加强。\n\n### 自主的数据调度框架\n\n让我们先从内核部分开始。\n\nTiDB 6.0 以 SQL 形式对用户暴露数据调度框架（Placement Rule In SQL）。以往，TiDB 的数据调度对于用户一直都是黑盒，TiDB 自行决定某一个数据块应该存在哪个节点，无论数据中心的物理边界和不同规格机器差异。这使得 TiDB 在多中心，冷热数据分离和大量写入所需的缓冲隔离等场景下无法提供灵活的应对。\n\n我们先看两个有趣的场景：\n\n1. 你有一个业务横跨多个城市，北京、上海和广州都设有数据中心。你希望将 TiDB 以跨中心的方式部署在这三个数据中心，分别覆盖华北、华东和华南的用户群，让不同区域的用户可以就近访问数据。在以往的版本中，用户的确可以跨中心的方式部署 TiDB 集群，但却无法如上述期望地将归属不同用户群的数据存放在不同的数据中心，只能任由 TiDB 按照热点和数据量均匀分布的逻辑将数据分散在不同中心。在高频访问的情况下，用户访问很可能会频繁跨越地域进而承受很高的延迟。\n\n2. 你希望用一组导入专用节点专门用于隔离导入数据所带来的性能抖动，而后再将导入完的数据迁回工作节点；或者你希望用一组低配节点存放冷数据，接受低频历史数据访问。暂时，还没有特别的手段支持这样的用况。\n\nTiDB 6.0 开放的数据调度框架提供了针对分区 / 表 / 库级数据在不同标签节点之间的自由放置接口，用户可以针对某张表、某个数据分区的存储位置做出自定义的选择。在新版本中，用户可以将一组节点给与标签，并为这组标签定义放置约束。例如你将所有位于纽约机房的 TiDB 存储节点定义放置策略：\n\n```\nCREATE PLACEMENT POLICY 'newyork' CONSTRAINTS = \"[+region=nyc]\";\n```\n\n然后将这个策略应用于表：\n\n```\nCREATE TABLE nyc_account (ID INT) PLACEMENT POLICY = 'newyork';\n```\n\n通过这种方式，所有 NYC_ACCOUNT 的数据将存放在纽约机房，而用户的数据访问请求也自然会被路由到本地机房。\n\n类似的，用户可以为机械磁盘节点打标签用以冷存和低频访问以节省成本，并将旧数据分区放置在低成本节点。\n\n```\nCREATE PLACEMENT POLICY storeonhdd CONSTRAINTS=\"[+disk=hdd]\";\nALTER TABLE orders PARTITION p0 PLACEMENT POLICY = 'storeonhdd'；\n```\n\n另外，该功能也可被用于多租户隔离场景。例如在同一集群中，用户可以将不同租户的数据经由放置规则分配到不同节点，而不同租户的负载也将自动由对应节点处理。这使得 TiDB 具备了租户隔离的能力，且辅以合理的权限设置，租户之间仍保有数据互访的可能。\n\n虽然是一个大型功能引入，但实际上这个框架的主体部分，已经通过 TiFlash 的行列分离能力于 4.0 版本间接发布给用户使用了，且经过了超过一年的迭代和打磨。因此，虽然是一个重大变更，但该框架却已经拥有了成熟的案例。本次发布将 Placement Rules 能力借以 SQL 的形式向用户全面开放，除了解决上述问题之外，也希望借助社区无限的想象力，发掘更多有价值的用法。\n\n### 热点场景应对\n\n分布式数据架构下，有一个恼人的话题：如何应对热点。在热点数据访问或锁冲突场景下，分布式数据库无法发挥多计算节点的性能优势，造成性能瓶颈，影响业务稳定和应用体验。TiDB 6.0 针对这类问题增加了多种解决方案。\n\n#### 小表缓存\n\n有时用户的业务同时涉及大表（例如订单）和若干小表（例如汇率表），其中大表的负载很容易通过分布式分担，但每次交易亦要访问的小表的数据却容易造成性能瓶颈。TiDB 6.0 新引入的小表缓存功能，支持显式将小的热点表缓存于内存中以大幅提高访问性能，提升吞吐，降低访问延迟，适用于高频访问低频更新的小表场景，例如配置表，汇率表等。\n\n#### 内存悲观锁\n\n通过将悲观锁事务缓存化，大幅降低悲观场景下的资源开销，CPU 和 IO 开销降低 20%左右，同时性能提升 5%-10% 左右。\n\n除了上述新增功能外，TiDB 未来还将提供基于负载的热点 region 自动分裂能力，提升热点数据的访问吞吐，解决非预期突发热点访问造成的性能问题。\n\n### 数据生态套件可管理性提升\n\n作为 TiDB 产品重要的一环，数据生态套件之于可管理性尤为重要。具体到数据迁移场景，当用户在对大规模的MySQL Sharding 系统进行迁移时，需要有很多的迁移任务、迁移规则、源端和目标端表相关的配置和管理工作。 在数据同步环境的日常管理过程中，经常需要对数据同步任务进行监控、诊断、创建、删除等管理操作。 命令行的操作在进行复杂运维操作，或者大量任务操作时，通常会效率很低，而且容易出错。由此，在新版本中，DM 推出了基于 Web 的图形管理工具，帮助用户更加方便的对整个数据迁移环境进行管理。它包含了如下功能：\n\n- Dashboard： 包含了 DM 中同步任务的主要监控信息和运行状态信息，帮助用户快速了解任务的整体运行状况，以及与延迟、性能相关的重要信息。\n- 数据迁移任务管理功能，帮助用户监控、创建、删除、配置复制任务。\n- 数据迁移上游管理功能，帮助用户管理数据迁移环境中的上游配置，包含了，新增、删除上游配置、监控上游配置对应的同步任务状态、修改上游配置等相关的管理功能。\n- 迁移任务详细信息管理功能，根据用户指定的筛选条件查看同步任务的具体配置和状态信息，包括，上下游配置信息，上下游数据库名称、表名称等。\n- 集群成员信息管理功能，帮助用户查看当前 DM 集群的配置信息和各个 worker 的状态信息。\n\n![1.png](https://img1.www.pingcap.com/prod/1_3e5c53fbc3.png)\n\n### 全新的管理平台和智能诊断套件\n\n#### TiEM 管理平台\n\n从最初版本至今，TiDB 的日常运维都是以命令行操控为主。虽然 TiDB 从 4.0 开始推出 TiUP 工具对 TiDB 集群进行安装部署和运维操作，降低了管理复杂度，然而它终究是命令行工具，学习成本较高，对相当多的企业用户而言，并不合意。除此之外，我们也经常遇到用户同时管理多个业务的多套集群，且配置和规格各不相同，任何集群变更和监控都是一个很大的挑战。一个无心的疏忽登录了错误的管理节点，应用了错误的变更，就可能带来无法挽回的损失。我们曾经遇到过仅仅因为切错命令行分页，而将生产集群当做测试集群关闭的惨况。现下诸多企业级数据库都拥有图形化管理界面，而 TiDB 6.0 中，也引入了 TiEM（TiDB Enterprise Manager）。\n\n![2.png](https://img1.www.pingcap.com/prod/2_2a7eeabc8b.png)\n\n在当前版本中，TiEM 集成了资源管理，多集群管理，参数组管理，数据的导入导出，系统监控等诸多功能。用户可以通过 TiEM 在同一界面管理多套集群，扩缩容，数据备份恢复，统一参数变更，版本升级，主备集群切换等。TiEM 还内置了监控和日志管理，让集群巡检变得轻松高效，不再需要在多套工具和监控之间不断切换。通过 TiEM 的管理平台，除了方便的统一界面进行多集群管理外，也将很大程度避免人为疏失带来的灾难，而用户也可以从繁杂易错的工作中解脱。\n\n#### PingCAP Clinic 自动诊断服务（预览版）\n\n和其他数据库系统一样，TiDB 本身存在一定的内在的复杂性，问题诊断和解决并不是非常容易的事情。而对于云环境下，服务提供商更需要面对大量不同用况的用户，对于集群的问题定位，诊断，问题解决都提出了全新的挑战。为了更好更高效地应对问题诊断，定位和修复，TiDB 必须用不同以往的方式面对。究极而言，我们希望数据库是可以智能地自调整自修复，但这却是一个非常宏大的目标。\n\n传统上，我们依赖具备专家知识的工程师 / DBA 进行分析诊断，但这些知识是否可以通过程序来提供，以方便我们的日常运维管理，甚至这些知识是否可以通过不断积累我们由不同真实案例而变得更智能更强大？作为 TiDB 迈向自服务的全新一步，我们希望对于集群运行情况的分析，风险预警和问题定位是可以作为智能服务来提供的：在 TiDB 6.0 发布的同时，新版本也引入了智能诊断服务 PingCAP Clinic 的预览版。PingCAP Clinic 从全生命周期确保集群稳定运行，预测并降低问题出现概率，快速定位并修复问题，加速问题解决效率。它集成了诊断数据采集、智能诊断、智能巡检、云诊断平台等功能，这些功能将逐步向用户开放。\n\nPingCAP Clinic 通过访问（经过用户允许）信息采集组件获取各类故障信息，在对各种问题进行排查的同时也不断增强自身的能力。PingCAP Clinic 将受益于我们面对的数千个场景迥异的用户所提供的各类集群运行数据。我们会不断将从问题中抽象出的规则固化到智能诊断中，并通过在线/离线升级的方式分发给 TiDB 用户，这使得用户在使用 TiDB 的同时也不断获得整个 TiDB 社区的积累。可以预见到的是，当 TiDB 获得更多云端客户时，PingCAP Clinic 也将更容易不断「学习」来提高自己。作为一个宏大目标的起点，我们欢迎大家的关注和讨论。关于更多 PingCAP Clinic 的信息，请阅读官方文档，并关注后续进展发布。\n\n### 面向非专家的可观测性\n\n作为可管理性的一个重要组成部分，可观测性是TiDB 一直以来都在不断加强可观测性。除了其他分布式系统都具备的基本监控和指标，从 4.0 起，TiDB 已陆续发布了诸如 Key Visualizer，SQL 统计和慢查询展示，监控关系图，持续 Profiling 等分布式数据库专有的功能，这些都是对 TiDB 的可观测性很好的补强，能帮助 DBA 和工程师更好地理解自己业务在 TiDB 上的运行情况，以更精准地定位问题和进行系统调优。但这些多多少少是专家向的特性，需要用户对系统有一定的技术理解。\n\n而从 6.0 开始，我们将引入更多的非专家向可观测性特性，让对分布式数据库和 TiDB 并不那么了解的用户也能排查系统问题。Top SQL 的推出是践行理念的第一步。\n\nTop SQL 是一个面向运维人员及应用开发者的一体化、自助的数据库性能观测和诊断功能。与现有 TiDB Dashboard 中各个面向数据库专家的诊断功能不同的是，Top SQL 完全面向非专家：你不需要观察几千张监控图表寻找相关性，也不需要理解诸如 Raft Snapshot、RocksDB、MVCC、TSO 等 TiDB 内部机制，仅需要知道常见数据库概念，如索引、锁冲突、执行计划等，即可开始使用它来快速分析数据库负载情况，并提升应用程序的性能。Top SQL 以用户自助使用、判断分析的方式，与 PingCAP Clinic 自动化规则一起，共同为用户提供从常见到复杂罕见的不同性能场景的覆盖方案。\n\nTop SQL 无需额外配置，在 TiDB 6.0 版本中开箱即用，集成于 TiDB Dashboard 图形化界面，且不影响数据库现有应用程序性能。当前版本 Top SQL 率先提供各个节点 30 天的 CPU 负载情况，你可以直观了解各节点的高 CPU 负载是来自于哪些 SQL 语句，从而快速分析诸如数据库热点、突发的负载升高等场景。在未来版本中我们还将持续迭代改进 Top SQL，重组整合流量可视化、慢查询、锁视图等现有的专家功能到 Top SQL 中，以一体化的、面向非专家的功能形式，帮助运维人员及应用开发者更简单、更全面地分析数据库性能问题。\n\n![3.png](https://img1.www.pingcap.com/prod/3_173646c19e.png)\n\n## 更成熟的 HTAP 能力\n\nTiDB 5.0 是其分析引擎架构初步成型的版本，这个版本中我们引入了 MPP 执行模式，从而得以服务于更广的用户场景。这一年来 TiDB HTAP 也经受了严苛的考验，无论是双十一场景下数十万 TPS 写入合并数十张实时报表中高频刷新，交易分析混合下优化器自动路由完成的高并发数据服务，这些用例都成为 TiDB HTAP 不断成熟的依托。相较 TiDB 5.0，最新版本中分析引擎 TiFlash 拥有了：\n\n- 更多算子和函数支持：相较 5.0，TiDB 分析引擎新增加了 110 多个常用内建函数以及若干表关联算子。这将使得更多计算能享受 TiDB 分析引擎的加速带来的数量级性能提升。\n- 更优的线程模型：在 MPP 模式下，以往 TiDB 对于线程资源是相对无节制的。这样实现的后果是，当系统需要处理较高并发的短查询时，由于过多的线程创建和销毁带来的开销，系统无法将 CPU 资源用满，从而带来大量资源浪费。另外，当进行复杂计算的时候，MPP 引擎也会占用过多线程，带来性能和稳定性的双重问题。针对这个问题，最新版中引入了全新的弹性线程池，并对算子持有线程的方式进行了较大重构，这使得 TiDB MPP 模式下的资源占用更为合理，在短查询下达到同等计算资源倍增的计算性能，且在高压力查询时稳定性更佳。\n- 更高效的列存引擎：通过调整存储引擎底层文件结构和 IO 模型，优化了访问不同节点上副本和文件区块的计划，优化了写放大以及普遍的代码效率。经客户实景验证，在极高读写混合负载下提升超过 50%～100% 以上并发能力，同等负载下大幅度降低 CPU / 内存资源使用率。\n\n## 强化的容灾能力\n\n除了可管理性之外，作为数据容灾的关键组件，TiCDC 也迎来了核心能力增强：通过对整个处理增量数据处理过程的优化、控制拉取事务日志速度等方式，TiCDC 在大规模集群数据容灾方面的能力有了长足的进步。\n\nTiCDC 对于增量数据的提取、排序、加载、投递等多个处理流程都进行了优化，降低在处理每一张表的增量数据时所需要使用的 CPU、内存量、减少进程间的通信次数。 这极大地提升了 TiCDC 在大规模集群下同步数据的稳定性、并降低了资源消耗和数据延迟。 真实用户场景测试显示， 6.0 版本的 TiCDC 可以在上游集群的规模达到 100K 张表、集群每秒钟数据改变行数低于 20 K/s、数据改变量低于 20 MB/s 的情况下，确保 99.9% 的数据延迟时间低于 10 秒钟， RTO < 5 分钟，RPO < 10 分钟。就整体而言，在上游集群 TiDB 集群节点进行计划内升级或者停机的场景中，可以将延迟控制在 1 分钟之内。\n\n另外，为了降低数据复制过程中对上游集群的性能影响，保证数据复制过程中业务无感知， TiCDC 增加了对于主集群事务日志扫描的限流功能。在绝大多数情况下，确保TiCDC 对于上游集群的 QPS、 SQL 语句平均响应时间的影响不超过 5%。\n\n## 面向企业级版本的锚定\n\n随着对版本发布的节奏把控不断成熟，随着 TiDB 6.0 发布，针对企业级用户的稳定性要求，我们也再次进行发版模型调整。从 6.0 版本开始，在 2 个月为周期内的版本迭代基础上，TiDB 发版策略将引入半年为发布周期的 LTS（Long Term Support）版本，同时为用户提供只包含修复的长期稳定版和快速迭代版以兼顾不同倾向的版本需求。其中 LTS 版本面向不需求最新功能，但希望不断收到问题修复的用户，生命周期为 2 年；而非 LTS 版本则拥有更高的迭代速度，只维护 2 个月，面向对最新功能有需求且稳定性需求不高的非生产场合。规划中的 TiDB 6.1 将作为第一个 LTS 版本发布。\n\n## 展望\n\n由于云数据库并不强调版本，因此在前文中我们没有对 [TiDB Cloud](https://tidbcloud.com/free-trial) 进行过多赘述。但是可以看到，6.0 版本不但是 TiDB 迈向企业级 HTAP 数据库的又一个全新版本，也是 TiDB 向云数据库进发的新起点。诸如可管理性主题，数据放置框架，Clinic 自动诊断兼顾了私有部署的使用，但实际上它们都将在云端形态下拥有更大的潜力。 \n\n云原生数据库是一个很有趣的话题。我们对云数据库的认识随着持续的摸索在不断提升中，从在云上可运行的数据库，到借助云基础设施实现的数据库，再到在云上可自运维数据库，6.0 版本是我们践行这个理念的重要一步。试想，结合良好的可管理性，当云数据库服务为成千上万用户提供支持的同时，也可以采集到远超于现在的非敏感的集群运行数据，这些数据将作为数据库自运维自服务的基础信息，不断学习不断进化，在用户体验提升的前提下也解放服务后端团队更多的资源，集中精力更好地提供用户所需的产品，这将带来私有部署形态无法替代的优势。 \n\n而在后续的版本规划中，我们将尝试通过借助云存储服务和资源按需启停等技术，为用户提供超越以往形态的使用体验。借助开源的力量，让用户觉得云服务相比免费使用私有部署更值得，转化为我们新的推力，是我们和整个整个社区双赢的共同目标。\n\n查看 TiDB 6.0.0 [Release Notes](https://docs.pingcap.com/zh/tidb/v6.0/release-6.0.0-dmr)，立即[下载试用](https://pingcap.com/zh/product/#SelectProduct)，开启 TiDB 6.0.0 企业级云数据库之旅。\n\n\n","author":"PingCAP","category":3,"customUrl":"tidb-6.0-release","fillInMethod":"writeDirectly","id":371,"summary":"2022 年 4 月 7 日，TiDB 6.0 发版。在该版本中，我们大幅度加强了作为企业级产品的可管理性，与此同时也加入了诸多云原生数据库所需的基础设施，让 TiDB 在成熟的企业级云数据库维度更向前迈进。","tags":["TiDB","Release"],"title":"TiDB 6.0 发版：向企业级云数据库迈进"}}]}}}, "staticQueryHashes": ["1327623483","1820662718","3081853212","3430003955","3649515864","4265596160","63159454"]}