TiDB 6.0 发版：向企业级云数据库迈进（tidb分布式数据库）

 ## 概览 我们很高兴为大家带来 TiDB 最新版 6.0 的介绍。虽然是一个开源数据库，但 TiDB 的定位一直都是面向企业级和云的数据库，而 TiDB 6.0 也是围绕这个主题而研发的。在最新版本中，我们大幅度加强了作为企业级产品的可管理性，与此同时也加入了诸多云原生数据库所需的基础设施。 对于企业级和云数据库，除了性能，可用性和功能等常规维度外，一个重要维度就是可管理性。除了提供必备的「硬」能力以完成用户的技术及业务目标，是否「好用」，是用户做选择时的重要考量，可管理性维度也会很深地影响用户实际使用数据库的隐性成本。而这点对于云数据库则更为明显，将数据库作为云服务提供，将使得可管理性的重要程度被放大：一个可运维性更好的数据库，在固定的运维和支持资源下，将为用户提供更好的服务。 针对这个方向，TiDB 6.0 引入数据放置框架（Placement Rules In SQL），增加了企业级集群管理组件 TiDB Enterprise Manager ，开放了智能诊断服务 PingCAP Clinic 的预览，大幅加强了生态工具的可运维性，并针对热点问题为用户提供了更多的手段。这些努力加在一起，将使用户无论使用的是公有云服务，还是私有部署，都获得体验更平滑和近似的使用体验，让 TiDB 在成熟的企业级云数据库维度更向前迈进。 除此之外，在这一年的时间内 TiDB 6.0 相较于前序版本也有了长足的进步，修复了 137 个 Issues，并融入了 77 个严苛的真实环境锤炼带来的增强。而社区一直期望的 [TiFlash 开源](https://github.com/pingcap/tiflash)也实现了，欢迎广大社区开发者一起参与。 ## 全面加强可管理性 可管理性是数据库的一个重要能力维度：在满足业务需求的前提下，是否灵活易用，将决定了用户技术选择背后的隐性成本。这种成本可大可小，可以是一句抱怨，也可能会结合人因带来灾难性后果。在最新版本研发过程中，我们结合了客户和市场反馈，总结了当前的可管理性的问题仍存在的缺失，这包含了「复杂且不直观的集群的日常管理」、「无法控制数据的存储位置」、「数据生态套件难于使用」、「面对热点缺少解决方案」等多个维度，而 TiDB 6.0 从内核、数据生态套件、增强组件多个方面针对这些问题进行了加强。 ### 自主的数据调度框架 让我们先从内核部分开始。 TiDB 6.0 以 SQL 形式对用户暴露数据调度框架（Placement Rule In SQL）。以往，TiDB 的数据调度对于用户一直都是黑盒，TiDB 自行决定某一个数据块应该存在哪个节点，无论数据中心的物理边界和不同规格机器差异。这使得 TiDB 在多中心，冷热数据分离和大量写入所需的缓冲隔离等场景下无法提供灵活的应对。 我们先看两个有趣的场景： 1. 你有一个业务横跨多个城市，北京、上海和广州都设有数据中心。你希望将 TiDB 以跨中心的方式部署在这三个数据中心，分别覆盖华北、华东和华南的用户群，让不同区域的用户可以就近访问数据。在以往的版本中，用户的确可以跨中心的方式部署 TiDB 集群，但却无法如上述期望地将归属不同用户群的数据存放在不同的数据中心，只能任由 TiDB 按照热点和数据量均匀分布的逻辑将数据分散在不同中心。在高频访问的情况下，用户访问很可能会频繁跨越地域进而承受很高的延迟。 2. 你希望用一组导入专用节点专门用于隔离导入数据所带来的性能抖动，而后再将导入完的数据迁回工作节点；或者你希望用一组低配节点存放冷数据，接受低频历史数据访问。暂时，还没有特别的手段支持这样的用况。 TiDB 6.0 开放的数据调度框架提供了针对分区 / 表 / 库级数据在不同标签节点之间的自由放置接口，用户可以针对某张表、某个数据分区的存储位置做出自定义的选择。在新版本中，用户可以将一组节点给与标签，并为这组标签定义放置约束。例如你将所有位于纽约机房的 TiDB 存储节点定义放置策略： ``` CREATE PLACEMENT POLICY 'newyork' CONSTRAINTS = "[+region=nyc]"; ``` 然后将这个策略应用于表： ``` CREATE TABLE nyc_account (ID INT) PLACEMENT POLICY = 'newyork'; ``` 通过这种方式，所有 NYC_ACCOUNT 的数据将存放在纽约机房，而用户的数据访问请求也自然会被路由到本地机房。 类似的，用户可以为机械磁盘节点打标签用以冷存和低频访问以节省成本，并将旧数据分区放置在低成本节点。 ``` CREATE PLACEMENT POLICY storeonhdd CONSTRAINTS="[+disk=hdd]"; ALTER TABLE orders PARTITION p0 PLACEMENT POLICY = 'storeonhdd'； ``` 另外，该功能也可被用于多租户隔离场景。例如在同一集群中，用户可以将不同租户的数据经由放置规则分配到不同节点，而不同租户的负载也将自动由对应节点处理。这使得 TiDB 具备了租户隔离的能力，且辅以合理的权限设置，租户之间仍保有数据互访的可能。 虽然是一个大型功能引入，但实际上这个框架的主体部分，已经通过 TiFlash 的行列分离能力于 4.0 版本间接发布给用户使用了，且经过了超过一年的迭代和打磨。因此，虽然是一个重大变更，但该框架却已经拥有了成熟的案例。本次发布将 Placement Rules 能力借以 SQL 的形式向用户全面开放，除了解决上述问题之外，也希望借助社区无限的想象力，发掘更多有价值的用法。 ### 热点场景应对 分布式数据架构下，有一个恼人的话题：如何应对热点。在热点数据访问或锁冲突场景下，分布式数据库无法发挥多计算节点的性能优势，造成性能瓶颈，影响业务稳定和应用体验。TiDB 6.0 针对这类问题增加了多种解决方案。 #### 小表缓存 有时用户的业务同时涉及大表（例如订单）和若干小表（例如汇率表），其中大表的负载很容易通过分布式分担，但每次交易亦要访问的小表的数据却容易造成性能瓶颈。TiDB 6.0 新引入的小表缓存功能，支持显式将小的热点表缓存于内存中以大幅提高访问性能，提升吞吐，降低访问延迟，适用于高频访问低频更新的小表场景，例如配置表，汇率表等。 #### 内存悲观锁 通过将悲观锁事务缓存化，大幅降低悲观场景下的资源开销，CPU 和 IO 开销降低 20%左右，同时性能提升 5%-10% 左右。 除了上述新增功能外，TiDB 未来还将提供基于负载的热点 region 自动分裂能力，提升热点数据的访问吞吐，解决非预期突发热点访问造成的性能问题。 ### 数据生态套件可管理性提升 作为 TiDB 产品重要的一环，数据生态套件之于可管理性尤为重要。具体到数据迁移场景，当用户在对大规模的MySQL Sharding 系统进行迁移时，需要有很多的迁移任务、迁移规则、源端和目标端表相关的配置和管理工作。 在数据同步环境的日常管理过程中，经常需要对数据同步任务进行监控、诊断、创建、删除等管理操作。 命令行的操作在进行复杂运维操作，或者大量任务操作时，通常会效率很低，而且容易出错。由此，在新版本中，DM 推出了基于 Web 的图形管理工具，帮助用户更加方便的对整个数据迁移环境进行管理。它包含了如下功能： - Dashboard： 包含了 DM 中同步任务的主要监控信息和运行状态信息，帮助用户快速了解任务的整体运行状况，以及与延迟、性能相关的重要信息。 - 数据迁移任务管理功能，帮助用户监控、创建、删除、配置复制任务。 - 数据迁移上游管理功能，帮助用户管理数据迁移环境中的上游配置，包含了，新增、删除上游配置、监控上游配置对应的同步任务状态、修改上游配置等相关的管理功能。 - 迁移任务详细信息管理功能，根据用户指定的筛选条件查看同步任务的具体配置和状态信息，包括，上下游配置信息，上下游数据库名称、表名称等。 - 集群成员信息管理功能，帮助用户查看当前 DM 集群的配置信息和各个 worker 的状态信息。  ### 全新的管理平台和智能诊断套件 #### TiEM 管理平台 从最初版本至今，TiDB 的日常运维都是以命令行操控为主。虽然 TiDB 从 4.0 开始推出 TiUP 工具对 TiDB 集群进行安装部署和运维操作，降低了管理复杂度，然而它终究是命令行工具，学习成本较高，对相当多的企业用户而言，并不合意。除此之外，我们也经常遇到用户同时管理多个业务的多套集群，且配置和规格各不相同，任何集群变更和监控都是一个很大的挑战。一个无心的疏忽登录了错误的管理节点，应用了错误的变更，就可能带来无法挽回的损失。我们曾经遇到过仅仅因为切错命令行分页，而将生产集群当做测试集群关闭的惨况。现下诸多企业级数据库都拥有图形化管理界面，而 TiDB 6.0 中，也引入了 TiEM（TiDB Enterprise Manager）。  在当前版本中，TiEM 集成了资源管理，多集群管理，参数组管理，数据的导入导出，系统监控等诸多功能。用户可以通过 TiEM 在同一界面管理多套集群，扩缩容，数据备份恢复，统一参数变更，版本升级，主备集群切换等。TiEM 还内置了监控和日志管理，让集群巡检变得轻松高效，不再需要在多套工具和监控之间不断切换。通过 TiEM 的管理平台，除了方便的统一界面进行多集群管理外，也将很大程度避免人为疏失带来的灾难，而用户也可以从繁杂易错的工作中解脱。 #### PingCAP Clinic 自动诊断服务（预览版） 和其他数据库系统一样，TiDB 本身存在一定的内在的复杂性，问题诊断和解决并不是非常容易的事情。而对于云环境下，服务提供商更需要面对大量不同用况的用户，对于集群的问题定位，诊断，问题解决都提出了全新的挑战。为了更好更高效地应对问题诊断，定位和修复，TiDB 必须用不同以往的方式面对。究极而言，我们希望数据库是可以智能地自调整自修复，但这却是一个非常宏大的目标。 传统上，我们依赖具备专家知识的工程师 / DBA 进行分析诊断，但这些知识是否可以通过程序来提供，以方便我们的日常运维管理，甚至这些知识是否可以通过不断积累我们由不同真实案例而变得更智能更强大？作为 TiDB 迈向自服务的全新一步，我们希望对于集群运行情况的分析，风险预警和问题定位是可以作为智能服务来提供的：在 TiDB 6.0 发布的同时，新版本也引入了智能诊断服务 PingCAP Clinic 的预览版。PingCAP Clinic 从全生命周期确保集群稳定运行，预测并降低问题出现概率，快速定位并修复问题，加速问题解决效率。它集成了诊断数据采集、智能诊断、智能巡检、云诊断平台等功能，这些功能将逐步向用户开放。 PingCAP Clinic 通过访问（经过用户允许）信息采集组件获取各类故障信息，在对各种问题进行排查的同时也不断增强自身的能力。PingCAP Clinic 将受益于我们面对的数千个场景迥异的用户所提供的各类集群运行数据。我们会不断将从问题中抽象出的规则固化到智能诊断中，并通过在线/离线升级的方式分发给 TiDB 用户，这使得用户在使用 TiDB 的同时也不断获得整个 TiDB 社区的积累。可以预见到的是，当 TiDB 获得更多云端客户时，PingCAP Clinic 也将更容易不断「学习」来提高自己。作为一个宏大目标的起点，我们欢迎大家的关注和讨论。关于更多 PingCAP Clinic 的信息，请阅读官方文档，并关注后续进展发布。 ### 面向非专家的可观测性 作为可管理性的一个重要组成部分，可观测性是TiDB 一直以来都在不断加强可观测性。除了其他分布式系统都具备的基本监控和指标，从 4.0 起，TiDB 已陆续发布了诸如 Key Visualizer，SQL 统计和慢查询展示，监控关系图，持续 Profiling 等分布式数据库专有的功能，这些都是对 TiDB 的可观测性很好的补强，能帮助 DBA 和工程师更好地理解自己业务在 TiDB 上的运行情况，以更精准地定位问题和进行系统调优。但这些多多少少是专家向的特性，需要用户对系统有一定的技术理解。 而从 6.0 开始，我们将引入更多的非专家向可观测性特性，让对分布式数据库和 TiDB 并不那么了解的用户也能排查系统问题。Top SQL 的推出是践行理念的第一步。 Top SQL 是一个面向运维人员及应用开发者的一体化、自助的数据库性能观测和诊断功能。与现有 TiDB Dashboard 中各个面向数据库专家的诊断功能不同的是，Top SQL 完全面向非专家：你不需要观察几千张监控图表寻找相关性，也不需要理解诸如 Raft Snapshot、RocksDB、MVCC、TSO 等 TiDB 内部机制，仅需要知道常见数据库概念，如索引、锁冲突、执行计划等，即可开始使用它来快速分析数据库负载情况，并提升应用程序的性能。Top SQL 以用户自助使用、判断分析的方式，与 PingCAP Clinic 自动化规则一起，共同为用户提供从常见到复杂罕见的不同性能场景的覆盖方案。 Top SQL 无需额外配置，在 TiDB 6.0 版本中开箱即用，集成于 TiDB Dashboard 图形化界面，且不影响数据库现有应用程序性能。当前版本 Top SQL 率先提供各个节点 30 天的 CPU 负载情况，你可以直观了解各节点的高 CPU 负载是来自于哪些 SQL 语句，从而快速分析诸如数据库热点、突发的负载升高等场景。在未来版本中我们还将持续迭代改进 Top SQL，重组整合流量可视化、慢查询、锁视图等现有的专家功能到 Top SQL 中，以一体化的、面向非专家的功能形式，帮助运维人员及应用开发者更简单、更全面地分析数据库性能问题。  ## 更成熟的 HTAP 能力 TiDB 5.0 是其分析引擎架构初步成型的版本，这个版本中我们引入了 MPP 执行模式，从而得以服务于更广的用户场景。这一年来 TiDB HTAP 也经受了严苛的考验，无论是双十一场景下数十万 TPS 写入合并数十张实时报表中高频刷新，交易分析混合下优化器自动路由完成的高并发数据服务，这些用例都成为 TiDB HTAP 不断成熟的依托。相较 TiDB 5.0，最新版本中分析引擎 TiFlash 拥有了： - 更多算子和函数支持：相较 5.0，TiDB 分析引擎新增加了 110 多个常用内建函数以及若干表关联算子。这将使得更多计算能享受 TiDB 分析引擎的加速带来的数量级性能提升。 - 更优的线程模型：在 MPP 模式下，以往 TiDB 对于线程资源是相对无节制的。这样实现的后果是，当系统需要处理较高并发的短查询时，由于过多的线程创建和销毁带来的开销，系统无法将 CPU 资源用满，从而带来大量资源浪费。另外，当进行复杂计算的时候，MPP 引擎也会占用过多线程，带来性能和稳定性的双重问题。针对这个问题，最新版中引入了全新的弹性线程池，并对算子持有线程的方式进行了较大重构，这使得 TiDB MPP 模式下的资源占用更为合理，在短查询下达到同等计算资源倍增的计算性能，且在高压力查询时稳定性更佳。 - 更高效的列存引擎：通过调整存储引擎底层文件结构和 IO 模型，优化了访问不同节点上副本和文件区块的计划，优化了写放大以及普遍的代码效率。经客户实景验证，在极高读写混合负载下提升超过 50%～100% 以上并发能力，同等负载下大幅度降低 CPU / 内存资源使用率。 ## 强化的容灾能力 除了可管理性之外，作为数据容灾的关键组件，TiCDC 也迎来了核心能力增强：通过对整个处理增量数据处理过程的优化、控制拉取事务日志速度等方式，TiCDC 在大规模集群数据容灾方面的能力有了长足的进步。 TiCDC 对于增量数据的提取、排序、加载、投递等多个处理流程都进行了优化，降低在处理每一张表的增量数据时所需要使用的 CPU、内存量、减少进程间的通信次数。 这极大地提升了 TiCDC 在大规模集群下同步数据的稳定性、并降低了资源消耗和数据延迟。 真实用户场景测试显示， 6.0 版本的 TiCDC 可以在上游集群的规模达到 100K 张表、集群每秒钟数据改变行数低于 20 K/s、数据改变量低于 20 MB/s 的情况下，确保 99.9% 的数据延迟时间低于 10 秒钟， RTO < 5 分钟，RPO < 10 分钟。就整体而言，在上游集群 TiDB 集群节点进行计划内升级或者停机的场景中，可以将延迟控制在 1 分钟之内。 另外，为了降低数据复制过程中对上游集群的性能影响，保证数据复制过程中业务无感知， TiCDC 增加了对于主集群事务日志扫描的限流功能。在绝大多数情况下，确保TiCDC 对于上游集群的 QPS、 SQL 语句平均响应时间的影响不超过 5%。 ## 面向企业级版本的锚定 随着对版本发布的节奏把控不断成熟，随着 TiDB 6.0 发布，针对企业级用户的稳定性要求，我们也再次进行发版模型调整。从 6.0 版本开始，在 2 个月为周期内的版本迭代基础上，TiDB 发版策略将引入半年为发布周期的 LTS（Long Term Support）版本，同时为用户提供只包含修复的长期稳定版和快速迭代版以兼顾不同倾向的版本需求。其中 LTS 版本面向不需求最新功能，但希望不断收到问题修复的用户，生命周期为 2 年；而非 LTS 版本则拥有更高的迭代速度，只维护 2 个月，面向对最新功能有需求且稳定性需求不高的非生产场合。规划中的 TiDB 6.1 将作为第一个 LTS 版本发布。 ## 展望 由于云数据库并不强调版本，因此在前文中我们没有对 [TiDB Cloud](https://tidbcloud.com/signup) 进行过多赘述。但是可以看到，6.0 版本不但是 TiDB 迈向企业级 HTAP 数据库的又一个全新版本，也是 TiDB 向云数据库进发的新起点。诸如可管理性主题，数据放置框架，Clinic 自动诊断兼顾了私有部署的使用，但实际上它们都将在云端形态下拥有更大的潜力。 云原生数据库是一个很有趣的话题。我们对云数据库的认识随着持续的摸索在不断提升中，从在云上可运行的数据库，到借助云基础设施实现的数据库，再到在云上可自运维数据库，6.0 版本是我们践行这个理念的重要一步。试想，结合良好的可管理性，当云数据库服务为成千上万用户提供支持的同时，也可以采集到远超于现在的非敏感的集群运行数据，这些数据将作为数据库自运维自服务的基础信息，不断学习不断进化，在用户体验提升的前提下也解放服务后端团队更多的资源，集中精力更好地提供用户所需的产品，这将带来私有部署形态无法替代的优势。 而在后续的版本规划中，我们将尝试通过借助云存储服务和资源按需启停等技术，为用户提供超越以往形态的使用体验。借助开源的力量，让用户觉得云服务相比免费使用私有部署更值得，转化为我们新的推力，是我们和整个整个社区双赢的共同目标。 查看 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 企业级云数据库之旅。