{ "componentChunkName": "component---src-templates-blog-blog-detail-tsx", "path": "/blog/first-try-of-cached-table-in-tidb-6.0", "result": {"pageContext":{"blog":{"id":"Blogs_400","title":"TiDB v6.0.0 (DMR) ：缓存表初试丨TiDB Book Rush","tags":["TiDB"],"category":{"name":"案例实践"},"summary":"TiDB v6.0.0 (DMR) 版本推出了缓存表的功能，以应对很少新增记录项的小表上频繁的读请求。在金融场景的订单表、汇率表，银行分行或者网点信息表，物流行业的城市、仓号库房号表，电商行业的地区、品类相关的字典表等等场景下能够很大程度地提高效率。本文通过测试验证了 TiDB 缓存表的性能表现。","body":"> 本文源自“TiDB 6.0 Book Rush” 投稿。作者：啦啦啦啦啦，TiDB 老粉，目前就职于京东物流，社区资深用户。\n\n## 背景\n\n一般情况下使用 TiDB 单表大小为千万级别以上在业务中性能最优，但是在实际业务中总是会存在小表。例如配置表对写请求很少，而对读请求的性能的要求更高。TiDB 作为一个分布式数据库，大表的负载很容易利用分布式的特性分散到多台机器上，但当表的数据量不大，访问又特别频繁的情况下，数据通常会集中在 TiKV 的一个 Region 上，形成读热点，更容易造成性能瓶颈。 \n\nTiDB v6.0.0(DMR) 版本推出了缓存表的功能，第一次看到这个词的时候让我想到了 MySQL 的内存表。MySQL 内存表的表结构创建在磁盘上，数据存放在内存中。内存表的缺点很明显：当 MySQL 启动着的时候，表和数据都存在，当 MySQL 重启后，表结构存在，数据消失。TiDB 的缓存表不存在这个问题。从 asktug 论坛中看到很多小伙伴都很期待缓存表的表现，个人也对它的性能很期待，因此在测试环境中实际看看缓存表的性能如何。\n\n## 缓存表的使用场景\n\n以下部分内容来自官方文档，详情见[缓存表](https://docs.pingcap.com/zh/tidb/v6.0/cached-tables#%E7%BC%93%E5%AD%98%E8%A1%A8) \n\n> TiDB 缓存表功能适用于以下特点的表： \n\n- 表的数据量不大\n- 只读表，或者几乎很少修改\n- 表的访问很频繁，期望有更好的读性能\n\n关于第一点官方文档中提到缓存表的大小限制为包含索引在内的所有 key-value 记录的总大小不能超过 64 MB。实际测试使用 Sysbench 生成下文中表结构的表，将数据量从 20w 提高到 30w 后就无法将普通表转换为缓存表，因此生产环境中实际使用缓存表的场景应该最多不超过几十万级别的数据量。关于缓存表对包含读写操作方面的性能，使用多种不同的读写请求比例进行了测试，相较普通表均没有达到更好的性能表现。这是因为为了读取数据的一致性，在缓存表上执行修改操作后，租约时间内写操作会被阻塞，最长可能出现 [tidb_table_cache_lease](https://docs.pingcap.com/zh/tidb/v6.0/system-variables#tidb_table_cache_lease%E4%BB%8E-v600-%E7%89%88%E6%9C%AC%E5%BC%80%E5%A7%8B%E5%BC%95%E5%85%A5) 变量值时长的等待，会导致 QPS 降低。因此缓存表更适合只读表，或者几乎很少修改的场景。\n\n缓存表把整张表的数据从 TiKV 加载到 TiDB Server 中，查询时可以不通过访问 TiKV 直接从 TiDB Server 的缓存中读取，节省了磁盘 IO 和网络带宽。使用普通表查询时，返回的数据量越多索引的效率可能越低，直到和全表扫描的代价接近优化器可能会直接选择全表扫描。缓存表本身数据都在 TiDB Server 的内存中，可以避免磁盘 IO，因此查询效率也会更高。以配置表为例，当业务重启的瞬间，全部业务连接一起加载配置，会造成较高的数据库读延迟。如果使用了缓存表，读请求可以直接从内存中读取数据，可以有效降低读延迟。在金融场景中，业务通常会同时涉及订单表和汇率表。汇率表通常不大，表结构很少发生变化因此几乎不会有 DDL，加上每天只更新一次，也非常适合使用缓存表。其他业务场景例如银行分行或者网点信息表，物流行业的城市、仓号库房号表，电商行业的地区、品类相关的字典表等等，对于这种很少新增记录项的表都是缓存表的典型使用场景。\n\n## 测试环境\n\n### 1. 硬件配置及集群拓扑规划\n\n使用 2 台云主机，硬件配置为 4C 16G 100G 普通 SSD 硬盘。 \n\n![测试环境硬件配置.jpeg](https://img1.www.pingcap.com/prod/_d8c7612ba1.jpeg)\n\n\n### 2. 软件配置\n\n![软件配置.jpeg](https://img1.www.pingcap.com/prod/_45e4a7f540.jpeg)\n\n\n### 3. 参数配置‍\n\n```\nserver_configs:\ntidb:\nlog.slow-threshold: 300\nnew_collations_enabled_on_first_bootstrap: true\n\ntikv:\nreadpool.coprocessor.use-unified-pool: true\nreadpool.storage.use-unified-pool: false\npd:\nreplication.enable-placement-rules: true\n replication.location-labels:\n - host\n```\n\n由于硬件条件受限，只有 2 台普通性能的云主机混合部署的集群（实际上和单机部署也差不多了）。单机 CPU 核数较少且 TiDB Server 没有做负载均衡所以并发无法调整太高。以下测试均使用一个 TiDB Server 节点进行压测，因此不用特别关注本次测试的测试数据，可能会跟其他测试结果有所出入，不代表最佳性能实践和部署，测试结果仅限参考。\n\n\n## 性能测试\n\nSysbench 生成的表结构 \n\n```\nCREATE TABLE sbtest1 (\nid int(11) NOT NULL AUTO_INCREMENT,\nk int(11) NOT NULL DEFAULT '0',\nc char(120) NOT NULL DEFAULT '',\npad char(60) NOT NULL DEFAULT '',\nPRIMARY KEY (id),\nKEY k_1 (k)\n) ENGINE = InnoDB CHARSET = utf8mb4 COLLATE = utf8mb4_bin AUTO_INCREMENT = 1\n```\n\n### 读性能测试\n\n**测试主要参数** \n\n**oltp_point_select** 主键查询测试（点查，条件为唯一索引列） \n\n主要 SQL 语句： \n\n`SELECT c FROM sbtest1 WHERE id=?` \n\n**select_random_points** 随机多个查询（主键列的 select in 操作） \n\n主要 SQL 语句： \n\n`SELECT id, k, c, pad FROM sbtest1 WHERE k IN (?, ?, ?, ?, ?, ?, ?, ?, ?, ?)` \n\n**select_random_ranges** 随机范围查询（主键列的 select between and 操作） \n\n主要 SQL 语句： \n\n`SELECT count(k) FROM sbtest1 WHERE k BETWEEN ? AND ? OR k BETWEEN ? AND ? OR k BETWEEN ? AND ? OR k BETWEEN ? AND ? OR k BETWEEN ? AND ? OR k BETWEEN ? AND ? OR k BETWEEN ? AND ? OR k BETWEEN ? AND ? OR k BETWEEN ? AND ? OR k BETWEEN ? AND ?` \n\n**oltp_read_only** 只读操作（包含聚合、去重等） \n\n主要 SQL 语句： \n\n```\nSELECT c FROM sbtest1 WHERE id=?\nSELECT SUM(k) FROM sbtest1 WHERE id BETWEEN ? AND ?\nSELECT c FROM sbtest1 WHERE id BETWEEN ? AND ? ORDER BY c\nSELECT DISTINCT c FROM sbtest1 WHERE id BETWEEN ? AND ? ORDER BY c\n```\n\n**Sysbench 测试命令示例**\n\n```\nsysbench --mysql-host=10.0.0.1 --mysql-port=4000 --mysql-db=sbtest --mysql-user=root --time=600 \\\n--threads=8 --report-interval=10 --db-driver=mysql oltp_point_select --tables=1 --table-size=5000 run\n\nsysbench --mysql-host=10.0.0.1 --mysql-port=4000 --mysql-db=sbtest --mysql-user=root --time=600 \\\n--threads=8 --report-interval=10 --db-driver=mysql oltp_read_only --tables=1 --table-size=5000 run\n\nsysbench --mysql-host=10.0.0.1 --mysql-port=4000 --mysql-db=sbtest --mysql-user=root --time=600 \\\n--threads=8 --report-interval=10 --db-driver=mysql select_random_points --tables=1 --table-size=5000 run\n\nsysbench --mysql-host=10.0.0.1 --mysql-port=4000 --mysql-db=sbtest --mysql-user=root --time=600 \\\n--threads=8 --report-interval=10 --db-driver=mysql select_random_ranges --tables=1 --table-size=5000 run\n```\n\n#### 一、使用普通表\n\n**1.单表数据量 5000，测试 QPS** \n\n![单表数据量 5000.jpeg](https://img1.www.pingcap.com/prod/5000_0f0ae28fbc.jpeg)\n\n\n**2.单表数据量 50000，测试 QPS**\n\n![单表数据量 50000.jpeg](https://img1.www.pingcap.com/prod/50000_9138032194.jpeg)\n\n\n#### 二、使用缓存表\n\n**1.单表数据量 5000，测试 QPS**\n\n![缓存表单表数据量 5000.jpeg](https://img1.www.pingcap.com/prod/5000_b0f0354e94.jpeg)\n\n\n**2.单表数据量 50000，测试 QPS**\n\n![缓存表单表数据量 50000.jpeg](https://img1.www.pingcap.com/prod/50000_8ec961bb42.jpeg)\n\n\n#### 三、性能对比\n\n![性能对比 1.png](https://img1.www.pingcap.com/prod/1_aa3b00bc28.png)\n\n![性能对比 2.png](https://img1.www.pingcap.com/prod/2_97e1bd1d60.png)\n\n![性能对比 3.png](https://img1.www.pingcap.com/prod/3_1fd558342b.png)\n\n![性能对比 4.png](https://img1.www.pingcap.com/prod/4_5394a76315.png)\n\n\n### 读写混合性能测试\n\n**测试主要场景参数** \n\noltp_read_write 表示混合读写 \n\npoint_selects（每个事务里点查的数量) \n\ndelete_inserts（每个事务里插入/删除组合的数量） \n\n主要 SQL 语句：\n \n```\nINSERT INTO sbtest1 (id, k, c, pad) VALUES (?, ?, ?, ?)\nDELETE FROM sbtest1 WHERE id=?\nSELECT c FROM sbtest1 WHERE id=?\n```\n\n本次测试通过单个事务中请求类型的数量 --delete_inserts 固定为 10 且调整 --point_selects 参数的值来模拟不同读写比例下的性能差异，其余请求参数使用默认值，具体命令可参考下面 Sysbench 测试命令示例。\n\n**Sysbench 测试命令示例** \n\n`sysbench --mysql-host=10.0.0.1 --mysql-port=4000 --mysql-db=sbtest --mysql-user=root --time=600 --threads=8 --report-interval=10 --db-driver=mysql oltp_read_write --tables=1 --table-size=5000 --point_selects=10 --non_index_updates=0 --delete_inserts=10 --index_updates=0 run`\n\n#### 一、使用普通表\n\n**1.单表数据量 5000，测试 QPS** \n\n![sysbench 单表 5000.jpeg](https://img1.www.pingcap.com/prod/sysbench_5000_27780cb069.jpeg)\n\n\n**2.单表数据量 50000，测试 QPS** \n\n![sysbench 单表 50000.jpeg](https://img1.www.pingcap.com/prod/sysbench_50000_aea3dbc997.jpeg)\n\n\n#### 二、使用缓存表\n\n**1.单表数据量 5000，测试 QPS** \n\n![sysbench 缓存表 5000.jpeg](https://img1.www.pingcap.com/prod/sysbench_5000_62ad5d08f1.jpeg)\n\n\n**2.单表数据量 50000，测试 QPS**\n\n![sysbench 缓存表 50000.jpeg](https://img1.www.pingcap.com/prod/sysbench_50000_a59f4f864b.jpeg)\n\n\n#### 三、性能对比\n\n![性能对比01.png](https://img1.www.pingcap.com/prod/01_957950e6f6.png)\n\n![性能对比 02.png](https://img1.www.pingcap.com/prod/02_15384f2fd7.png)\n\n![性能对比 03.png](https://img1.www.pingcap.com/prod/03_683a72430f.png)\n\n![性能对比 04.png](https://img1.www.pingcap.com/prod/04_c61a9551e9.png)\n\n\n## 遇到的问题\n\n- 尝试将 30w 数据的表改为缓存表时报错 。ERROR 8242 (HY000): 'table too large' is unsupported on cache tables。 \n\n目前 TiDB 对于每张缓存表的大小限制为 64 MB，因此太大的表无法缓存在内存中。另外，缓存表无法执行普通的 DDL 语句。若要对缓存表执行 DDL 语句，需要先使用 ALTER TABLE xxx NOCACHE 语句去掉缓存属性，将缓存表设回普通表后，才能对其执行其他 DDL 语句。\n\n- 测试过程中缓存表性能出现了不稳定的情况，有些时候缓存表反而比普通表读取性能差，使用 trace 语句（TRACE SELECT * FROM sbtest1;）查看发现返回结果中出现了regionRequest.SendReqCtx，说明 TiDB 尚未将所有数据加载到内存中，多次尝试均未加载完成。把 tidb_table_cache_lease 调整为 10 后没有出现该问题。\n\n在 asktug 中向研发大佬提出了这个问题得到了解答。根据 中的描述，当机器负载较重时，load table 需要 3s 以上 ，但是默认的 tidb_table_cache_lease 是 3s， 表示加载的数据是立即过时的，因此需要重新加载，并且该过程永远重复。导致了浪费了大量的 CPU 资源并且降低了 QPS。目前可以将 tidb_table_cache_lease 的值调大来解决，该问题在 master 分支中已经解决，后续版本应该不会出现。 \n\n- 根据测试结果，写入较为频繁的情况下缓存表的性能是比较差的。在包含写请求的测试中，缓存表相较于普通表的性能几乎都大幅下降。\n\n在 lease 过期之前，无法对数据执行修改操作。为了保证数据一致性，修改操作必须等待 lease 过期，所以会出现写入延迟。例如 tidb_table_cache_lease 为 10 时，写入可能会出现较大的延迟。因此写入比较频繁或者对写入延迟要求很高的业务不建议使用缓存表。\n\n## 测试总结\n\n### 读性能\n\n单表 5000，缓存表相比普通表提升的百分比\n\n![读性能提升.jpeg](https://img1.www.pingcap.com/prod/_3ca95e6878.jpeg)\n\n单表 50000，缓存表相比普通表提升的百分比\n![读性能提升 50000.jpeg](https://img1.www.pingcap.com/prod/50000_013c093d21.jpeg)\n\n### 读写混合\n\n单表 5000，缓存表相比普通表提升的百分比（负增长符合预期） \n\n![读写混合单表 5000.jpeg](https://img1.www.pingcap.com/prod/5000_4088ab7876.jpeg)\n\n单表 50000，缓存表相比普通表提升的百分比（负增长符合预期） \n\n![读写混合单表 50000.jpeg](https://img1.www.pingcap.com/prod/50000_fcd5f99a43.jpeg)\n\n\n结果显示，相比于普通表，缓存表在 oltp_point_select、oltp_read_only、select_random_points、select_random_ranges 几种只读的场景下性能有非常大的提升，但在包含写请求的测试中无法提供更好的性能。它的机制决定了使用场景目前仅限于表的数据量不大的只读表，或者几乎很少修改的小表。综上，虽然缓存表目前的使用场景相对比较单一，但是在合适的场景下确实是一个解决了业务痛点的好功能，也期待在后续的版本中能有更高的稳定性和更优秀的性能表现。\n\n","date":"2022-06-27","author":"啦啦啦啦啦","fillInMethod":"writeDirectly","customUrl":"first-try-of-cached-table-in-tidb-6.0","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"]}