共计 5145 个字符，预计需要花费 13 分钟才能阅读完成。
“当用户应用软件时，会须要面对的两个鸿沟：一个是执行的鸿沟，在这里，用户要弄清楚如何操作，与软件「对话」；另一个是评估的鸿沟，用户要弄清楚操作的后果。”PingCAP 联结创始人兼 CTO 黄东旭在《做出让人爱不释手的根底软件》中提到，“咱们作为设计师的使命就是帮忙用户打消可观测性和可交互性这两个鸿沟。”
2021 年 11 月 30 日，TiDB 5.3.0 版本正式上线，该版本推出继续性能剖析（Continuous Profiling) 性能（目前为试验个性），逾越可观测性的鸿沟，为用户带来数据库源码程度的性能洞察，彻底解答每一个数据库问题。
在晋升数据可观测性的同时，TiDB 5.3.0 实现了 HTAP 性能和稳定性的大幅晋升，数据迁徙效率、高可用性和易用性也实现了大幅晋升，为所有用户带来重磅福利。
5.3.0 性能亮点与用户价值
- 反对继续性能剖析 (Continuous Profiling)，引领数据库的可观测性潮流
- 深度优化分布式工夫戳获取技术，晋升零碎的整体性能
- 继续优化存储和计算引擎，提供更麻利更牢靠的 HTAP 服务
- 进一步升高上游零碎同步数据至 TiDB 的提早，助力高峰期业务增长
- 新增并行导入性能，晋升全量数据迁徙效率
- 引入长期表，一条 SQL 语句简化业务逻辑并晋升性能
反对继续性能剖析，引领数据库的可观测性潮流
在企业遭逢的 IT 故障中，约有 30% 与数据库相干。当这些故障波及到利用零碎、网络环境、硬件设施时，复原工夫可能达到数小时，对业务连续性造成毁坏，影响用户体验甚至营收。在简单分布式系统场景下，如何进步数据库的可观测性，帮忙运维人员疾速诊断问题，优化故障解决流程始终是困扰着企业的一大难题。在 TiDB 5.3.0 版本中，PingCAP 率先在数据库畛域推出了继续性能剖析 (Continuous Profiling) 个性（目前为试验个性），为企业提供了数据库源码程度的性能洞察。
继续性能剖析以低于 0.5% 的性能损耗实现了对数据库外部运行状态继续打快照（相似 CT 扫描），以火焰图的模式从零碎调用层面解读资源开销。让本来 黑盒 的数据库变成 白盒。在 TiDB Dashboard 上一键开启继续性能剖析后，运维人员能够不便疾速定位性能问题的根因，无论过来当初皆可回溯。
- 当数据库意外宕机时，可升高至多 50% 诊断工夫
在互联网行业的一个案例中，当客户集群呈现报警业务受影响时，因短少数据库间断性能剖析后果，运维人员难以发现故障根因，消耗 3 小时才定位问题复原集群。如果应用 TiDB 的继续性能剖析性能，运维人员可比对日常和故障的剖析后果，仅需 20 分钟就可复原业务，极大缩小损失。 - 在日常运行中，可提供集群巡检和性能剖析服务，保障集群继续稳固运行
继续性能剖析是 TiDB 集群巡检服务的要害，为商业客户提供了集群巡检和巡检后果数据上报。客户能够自行发现和定位潜在危险，执行优化倡议，保障每个集群继续稳固运行。 - 在数据库选型时，提供更高效的业务匹配
在进行数据库选型时，企业往往须要在短时间内实现性能验证、性能验证的流程。继续性能剖析性能可能帮助企业更直观地发现性能瓶颈，疾速进行多轮优化，确保数据库与企业的业务特色适配，进步数据库的选型效率。
注：性能剖析后果存储在监控节点上，不会对解决业务流量的节点产生影响。
深度优化分布式工夫戳获取技术，为海量业务数据处理提供刚强后盾
当互联网行业的外围业务零碎具备宏大的用户数量和业务数据时，在高并发拜访的场景下，可能会呈现数据库工夫戳获取提早增大而导致业务响应变慢、超时频发、用户体验急剧下降的状况。海量的业务数据要求数据库领有良好的扩展性。TiDB 自身领有可能程度扩大的劣势，然而一直增长的业务数据量使工夫戳获取能力逐步成为妨碍集群扩大的瓶颈，最终限度集群整体的扩大。
为进一步晋升工夫戳获取能力，在 TiDB 5.3.0 版本中，TiDB 在放弃原有的全局工夫戳治理形式的根底上，新增两个工夫戳解决调优参数，在 PD 负载达到瓶颈的状况下，能够无效加重负载，升高了工夫戳获取提早，大大晋升了零碎的整体性能：
- 反对参数设置 PD follower proxy 开关，开启后容许 follower 批量转发工夫戳解决申请。
- 反对设置 PD client 批量解决工夫戳的最大等待时间参数，进步工夫戳申请的解决带宽。
通过本次优化，TiDB 可能更好地撑持百 TB 或百万 QPS 大规模集群的扩大。通过 Sysbench 512 线程的测试验证，工夫戳解决流程优化后，TiDB 集群整体 QPS 吞吐晋升了 100% 以上。具体测试环境如下：
| 角色 | 数量 | 规格 |
|---|---|---|
| TiDB | 26 | 8 cores |
| PD | 3 | 4 cores |
| TiKV | 5 | 12 cores |
本次优化实用于以下场景：
- 领有百 TB 或 百万 QPS 以上超大规模集群，须要实现大规模集群的扩大。
- 领有中等规模集群，但随着业务的急速增长，数据的成倍增加，须要实现集群的有限扩大。
继续优化存储和计算引擎，提供更麻利更牢靠的 HTAP 服务
在大型物流和金融服务类企业中，在线交易和实时业务监控等利用场景对数据有较高的一致性和时效性要求，尤其是当读写混合负载大时，会对数据库管理系统的性能和稳定性造成较大挑战。在年度流量峰值时段，数据平台的写入 / 更新和剖析工作往往会激增数倍。例如，某合作伙伴（物流龙头）在双十一期间，每天解决超 2500 亿条更新和插入记录，同时还要兼顾海量历史数据（50 亿～100 亿）的剖析工作。
TiDB HTAP 致力于为企业的规模化在线交易和实时剖析利用提供一栈式数据服务平台，晋升要害业务的时效性，升高数据技术栈的复杂性。在已有产品根底上，TiDB 5.3.0 进一步优化了 HTAP 的性能和稳定性，大幅改善了高混合负载场景下并发查问能力和查问工作的执行速度。次要的改良包含：
- 性能大幅晋升（50%～100%），CPU / 内存资源使用率进一步优化，查问失败缩小：TiDB 5.3.0 优化了列式存储引擎，调整了存储引擎底层文件构造和 IO 模型，优化了拜访节点正本和文件区块的打算，弛缓了写放大问题以及改良了广泛的代码效率。总体上高负载时因资源有余造成的失败情况大大缓解。
- 近程数据读取提速，工作成功率进步，告警可读性加强：优化了 MPP 计算引擎，反对更多的字符串 / 工夫和其余函数 / 算子下推至 MPP 引擎，并改善了存储层写入 / 更新事务量较大时数据期待造成外部过程超时的问题，同时还优化了查问申请的告警信息，便于追踪和定位问题。
- 轻松扩大节点：在 TiDB 5.3.0 中，TiDB HTAP 架构可随业务增长轻松扩大到 200 节点甚至更大的集群规模，并且确保 OLTP 与 OLAP 之间原则上不产生资源抵触和互相性能影响。
- 加强运维能力：欠缺了数据校验，解决了节点重启时外部解决可能呈现的问题；同时进一步晋升了 SQL 告警信息和加强了日志收集、检索性能。
低提早同步至 TiDB，助力企业业务持续增长
随同着业务持续增长，企业订单零碎的数据库压力也一直减少。外围交易库写流量微小，造成订单提交工夫变长，影响网站用户体验。面对这一典型的业务场景，为了帮忙晋升企业缩短订单提交工夫，TiDB 反对作为上游只读从库提供业务查问服务，为外围交易系统减压。
TiDB Data Migration (DM) 作为一款实时的数据同步工具，反对将数据从与 MySQL 协定兼容的数据库同步到 TiDB，实现业务分流，加重高峰期前端订单写入时的压力。而交易场景高度的即时性，要求业务查问提早极低、数据实时性极高，这给 DM 的同步性能带来了极大挑战。
为了保障低提早，数据迁徙工具 DM 在 v5.3.0 实现了两项优化：
- 合并单行数据的屡次变更，缩小同步到上游的 SQL 数量，进步迁徙效率，升高数据提早，为网站用户更快地提供业务查问服务；
- 批量的点查更新合并为繁多的语句操作，缩小近程过程调用申请的数量，同样数量的 binlog 能够更快地同步实现，进而升高提早，为网站用户更精确地提供业务查问服务。
极低的同步提早保障了上游 TiDB 数据查问实时性，企业在放弃现有架构的状况下，无需进行大规模革新，就能疾速引入 TiDB 以加强实时查问剖析能力，更好更快萃取数据价值。
经场景实测，在 300K QPS 数据同步流量下，99.9% 工夫内 DM 同步提早升高至 1 秒以内，尤其实用于高负载业务压力下 TiDB 作为只读从库的场景。
新增并行导入性能，晋升全量数据迁徙效率
目前 MySQL 分库分表架构日益广泛，很多企业的数据量曾经达到百 TB 级别。随着企业数据量的增长，从集中式数据库迁徙到以 TiDB 为代表的分布式数据库曾经成为必然，然而存量零碎外面的 100 TB 数据没有不便高效的工具进行迁徙。
为解决此问题，TiDB 5.3.0 公布了 [TiDB Lightning](https://docs.pingcap.com/zh/t…
) 并行导入性能，提供了高效的 TiDB 集群初始化能力。用户能够同时启动多个 TiDB Lightning 实例，并行地将单表或者多表数据迁徙到 TiDB，速度能够横向扩大，极大地提高了数据迁徙效率。
并行导入示意图如下。用户能够应用多个 TiDB Lightning 实例导入 MySQL 的分表到上游的 TiDB 集群。
并行导入性能反对多种数据源，包含：CSV/SQL 格局的文本数据、MySQL 分表导出数据。反对的最大单表规模在 20 TB ～ 30 TB 之间，导入单表数据倡议应用 1 个 ～ 8 个 TiDB Lightning 实例，每个实例最佳规模放弃在 2 TB～ 5 TB。对于多表总规模和应用 Lightning 的个数没有下限要求。
经测试，应用 10 台 TiDB Lightning，20 TB 规模的 MySQL 数据能够在 8 小时内导入到 TiDB，单台 TiDB Lightning 能够反对 250 GB/s 的导入速度，整体效率晋升了 8 倍。
引入长期表，一条 SQL 语句简化业务逻辑并晋升性能
业务长期两头数据存储不易
在数据量大的场景下，用户业务经常须要解决宏大的两头数据。如果业务须要重复应用数据中的一部分子集，用户通常会长期保留这部分数据，用完后开释。因而，DBA 不得不频繁地建表和删表，可能还须要自行设计数据存储构造，把两头数据存储至业务模块中。这不仅减少了业务复杂度，也造成了宏大的内存开销，而且如果治理不善，还存在内存透露导致系统解体的危险。
TiDB 长期表帮忙用户简化业务逻辑并晋升性能
为帮忙用户解决以上痛点，TiDB 在 5.3.0 版本中引入了长期表性能。该性能针对业务两头计算结果的长期存储问题，让用户免于频繁地建表和删表等操作。用户可将业务上的两头计算数据存入长期表，用完后主动清理回收，防止业务过于简单，缩小表治理开销，并晋升性能。
TiDB 长期表次要利用于以下业务场景：
- 缓存业务的两头长期数据，计算实现后将数据转储至惯例表，长期表会主动开释。
- 短期内对同一数据进行屡次 DML 操作。例如在电商购物车利用中，增加、批改、删除商品及实现结算，并移除购物车信息。
- 疾速批量导入两头长期数据，晋升导入长期数据的性能。
批量更新数据。将数据批量导入到数据库的长期表，批改实现后再导出到文件。
一条 SQL 语句轻松创立长期表
可通过 CREATE [GLOBAL] TEMPORARY TABLE 语句创立长期表。长期表中的数据均保留在内存中，用户可通过 tidb_tmp_table_max_size 变量限度长期表的内存大小。
TiDB 提供的长期表分为 Global 和 Local 两类，无论应用哪种长期表，都能 无效帮忙用户简化业务逻辑并晋升性能：
- Global 长期表：
- 对集群内所有 Session 可见，表构造长久化。
- 提供事务级别的数据隔离，数据只在事务内无效，事务完结后主动删除数据。
- Local 长期表：
- 只对以后 Session 可见，表构造不长久化。
- 反对重名，用户无需为业务设计简单的表命名规定。
提供会话级别的数据隔离，升高业务设计复杂度，会话完结后删除长期表。
结语
本次公布的 5.3.0 版本 进一步欠缺了零碎的可观测性、晋升了分布式数据库可扩展性、保障了数据的低提早同步、大幅晋升了全量数据迁徙效率、晋升了实时剖析的稳定性，是 TiDB 迈向成熟企业级 HTAP 平台的一个重要里程碑。
PingCAP 首席架构师唐刘示意：TiDB HTAP 的使命不仅仅局限于对传统数据库的降级或者是交易和剖析解决性能的晋升，实质上 TiDB HTAP 是一个凋谢的生态体系，在企业中承当着反对数据服务生产化和构建对立实时数据服务平台的角色，为用户带来业务与架构的翻新与晋升。
TiDB 的每一次发版和提高都离不开每一位用户的反馈、每一位开发者的 PR 合并、每一位质量保证人员的测试。感激所有人的奉献，TiDB 在后续版本中会不断加强大规模场景下的稳定性和易用性，不忘初心，砥砺前行，成为一款让人爱不释手的根底软件，给用户带来更好的应用体验。
查看 TiDB 5.3.0 Release Notes，立刻下载试用，开启 TiDB 5.3.0 之旅。
