“当用户使用软件时,会需要面对的两个鸿沟:一个是执行的鸿沟,在这里,用户要弄清楚如何操作,与软件「对话」;另一个是评估的鸿沟,用户要弄清楚操作的结果。” PingCAP 联合创始人兼 CTO 黄东旭在《做出让人爱不释手的基础软件》中提到,“ 我们作为设计师的使命就是帮助用户消除可观测性和可交互性这两个鸿沟。”
2021年 11 月 30 日,TiDB 5.3.0 版本正式上线,该版本推出持续性能分析 (Continuous Profiling) 功能(目前为实验特性),跨越可观测性的鸿沟,为用户带来数据库源码水平的性能洞察,彻底解答每一个数据库问题。
在提升数据可观测性的同时,TiDB 5.3.0 实现了 HTAP 性能和稳定性的大幅提升,数据迁移效率、高可用性和易用性也实现了大幅提升,为所有用户带来重磅福利。
在企业遭遇的 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 负载达到瓶颈的情况下,可以有效减轻负载,降低了时间戳获取延迟,大大提升了系统的整体性能:
通过本次优化,TiDB 能够更好地支撑百 TB 或百万 QPS 大规模集群的扩展。经过 Sysbench 512 线程的测试验证,时间戳处理流程优化后,TiDB 集群整体 QPS 吞吐提升了 100% 以上。具体测试环境如下:
角色 | 数量 | 规格 |
---|---|---|
TiDB | 26 | 8 cores |
PD | 3 | 4 cores |
TiKV | 5 | 12 cores |
本次优化适用于以下场景:
在大型物流和金融服务类企业中,在线交易和实时业务监控等应用场景对数据有较高的一致性和时效性要求,尤其是当读写混合负载大时,会对数据库管理系统的性能和稳定性形成较大挑战。在年度流量峰值时段,数据平台的写入/更新和分析任务往往会激增数倍。例如,某合作伙伴(物流龙头)在双十一期间,每天处理超 2500 亿条更新和插入记录,同时还要兼顾海量历史数据(50 亿~100 亿)的分析任务。
TiDB HTAP 致力于为企业的规模化在线交易和实时分析应用提供一栈式数据服务平台,提升关键业务的时效性,降低数据技术栈的复杂性。在已有产品基础上,TiDB 5.3.0 进一步优化了 HTAP 的性能和稳定性,大幅改善了高混合负载场景下并发查询能力和查询任务的执行速度。主要的改进包括:
伴随着业务持续增长,企业订单系统的数据库压力也不断增加。核心交易库写流量巨大,造成订单提交时间变长,影响网站用户体验。面对这一典型的业务场景,为了帮助提升企业缩短订单提交时间,TiDB 支持作为下游只读从库提供业务查询服务,为核心交易系统减压。
TiDB Data Migration (DM) 作为一款实时的数据同步工具,支持将数据从与 MySQL 协议兼容的数据库同步到 TiDB,实现业务分流,减轻高峰期前端订单写入时的压力。而交易场景高度的即时性,要求业务查询延迟极低、数据实时性极高,这给 DM 的同步性能带来了极大挑战。
为了保证低延迟,数据迁移工具 DM 在 v5.3.0 实现了两项优化:
极低的同步延迟保障了下游 TiDB 数据查询实时性,企业在保持现有架构的情况下,无需进行大规模改造,就能快速引入 TiDB 以增强实时查询分析能力,更好更快萃取数据价值。
经场景实测,在 300K QPS 数据同步流量下,99.9% 时间内 DM 同步延迟降低至 1 秒以内,尤其适用于高负载业务压力下 TiDB 作为只读从库的场景。
目前 MySQL 分库分表架构日益普遍,很多企业的数据量已经达到百 TB 级别。随着企业数据量的增长,从集中式数据库迁移到以 TiDB 为代表的分布式数据库已经成为必然,然而存量系统里面的 100 TB 数据没有方便高效的工具进行迁移。
为解决此问题,TiDB 5.3.0 发布了 TiDB Lightning 并行导入功能,提供了高效的 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/h 的导入速度,整体效率提升了 8 倍。
在数据量大的场景下,用户业务常常需要处理庞大的中间数据。如果业务需要反复使用数据中的一部分子集,用户通常会临时保存这部分数据,用完后释放。因此,DBA 不得不频繁地建表和删表,可能还需要自行设计数据存储结构,把中间数据存储至业务模块中。这不仅增加了业务复杂度,也造成了庞大的内存开销,而且如果管理不善,还存在内存泄漏导致系统崩溃的风险。
为帮助用户解决以上痛点,TiDB 在 5.3.0 版本中引入了临时表功能。该功能针对业务中间计算结果的临时存储问题,让用户免于频繁地建表和删表等操作。用户可将业务上的中间计算数据存入临时表,用完后自动清理回收,避免业务过于复杂,减少表管理开销,并提升性能。
TiDB 临时表主要应用于以下业务场景:
可通过 CREATE [GLOBAL] TEMPORARY TABLE 语句创建临时表。临时表中的数据均保存在内存中,用户可通过 tidb_tmp_table_max_size 变量限制临时表的内存大小。
TiDB 提供的临时表分为 Global 和 Local 两类,无论使用哪种临时表,都能有效帮助用户简化业务逻辑并提升性能:
提供会话级别的数据隔离,降低业务设计复杂度,会话结束后删除临时表。
本次发布的 5.3.0 版本进一步完善了系统的可观测性、提升了分布式数据库可扩展性、保证了数据的低延迟同步、大幅提升了全量数据迁移效率、提升了实时分析的稳定性,是 TiDB 迈向成熟企业级 HTAP 平台的一个重要里程碑。
PingCAP 首席架构师唐刘表示:TiDB HTAP 的使命不仅仅局限于对传统数据库的升级或者是交易和分析处理性能的提升,本质上 TiDB HTAP 是一个开放的生态体系,在企业中承担着支持数据服务消费化和构建统一实时数据服务平台的角色,为用户带来业务与架构的创新与提升。
TiDB 的每一次发版和进步都离不开每一位用户的反馈、每一位开发者的 PR 合并、每一位质量保证人员的测试。感谢所有人的贡献,TiDB 在后续版本中会不断加强大规模场景下的稳定性和易用性,不忘初心,砥砺前行,成为一款让人爱不释手的基础软件,给用户带来更好的使用体验。
查看 TiDB 5.3.0 Release Notes,立即下载试用,开启 TiDB 5.3.0 之旅。