首页 > 数据库 > 国内数据库 > TiDB 5.1 发版,打造更流畅的企业级数据库体验
自 TiDB 5.0 发布以来,陆续在金融、互联网 & 新经济、物流等行业用户的生产环境得到应用,收获不少用户的积极评价:
“ 用户的反馈激励我们不断前行,我们的使命是持续提升开发者和 DBA 的体验,让用户用得省心,用得顺手。 ” PingCAP 联合创始人兼 CTO 黄东旭说,“ TiDB 每一个版本的发布都立足于解决 DBA 的痛点 。真实场景就是最好的架构师,从 5.0 版本开始 TiDB 缩短了发版周期,采用了更灵活、更敏捷的火车发版模型,每一个用户真实场景需求的输入,在两个月周期内就有可能成为下一个版本交付的功能。”
得益于大量用户真实应用场景的快速反馈,TiDB 5.1 提速发版,进一步打造更流畅的企业级数据库体验。 TiDB 5.1 拥有更加稳定的响应延迟表现,更优的 MPP 性能与稳定性,更便捷的可运维性,开发者和 DBA 可以轻松地基于 TiDB 5.1 构建任意规模的关键业务应用。
TiDB 5.1 功能亮点和用户价值
在金融交易类场景,由于业务的客观复杂性,有时候会写出长达 2000 行的单条 SQL 语句,其中包含大量的聚合和多层子查询嵌套,维护此类 SQL 堪称开发人员的噩梦。 5.1 版本支持 ANSI SQL 99 标准的Common Table Expression(CTE)及递归的写法 ,极大提升开发人员和 DBA 编写复杂业务逻辑 SQL 的效率,增强代码的可维护性。
进一步提升 MPP 的性能和稳定性
5.1 版本进一步增强 TiFlash MPP 计算引擎 的综合能力,帮助用户提升业务决策速度:
提升高压力负载下查询分析的稳定性
在金融类业务场景下,技术人员每天会对数据进行高压力的跑批计算,生成最新的市场和营销分析报告,以辅助商业决策。跑批流程对连续性要求极高,无法容忍中间过程出错。针对该场景,5.1 版本优化了 TiDB 的请求重试机制和 TiKV 的请求处理机制,显著降低了在高负载下由于 TiFlash 同步数据不及时导致的 Region Unavailable 出错概率。
无缝集成 TiSpark
TiSpark 5.1 版本实现了对含有聚簇索引表的读写支持,不带来任何额外的性能开销,对用户完全透明,用户可以立刻迁移到新版 TiSpark 来体验与 TiDB 5.1 的无缝集成。
在延迟敏感的应用场景下,当线上产生突发写流量、操作 TiDB 扩缩容、后台执行统计任务,以及在线数据导入和备份时,可能造成数据库的 P99 和 P999 百分位的延迟抖动,对长尾查询产生一定影响TiDB 5.1 加强了 对磁盘读写链路的管理,限制后台任务对磁盘资源的使用,大幅降低上述场景对线上业务的干扰,改善读写链路的效率和稳定性 。在 AWS EC2 r5b.4xlarge 实例挂载 EBS gp3 盘的环境下,通过 TPC-C 基准测试(10k WH)的实测结果:
支持列类型变更
在典型的 TiDB 应用场景中,经常借助 binlog 将多个 MySQL 上游数据汇聚到一个 TiDB 集群。原先 TiDB 不支持变更列类型的操作,如果上游 MySQL 修改表的字段类型会导致与 TiDB 数据同步的中断。5.1 版本新增对修改列类型 DDL 语句的支持,彻底解决上述问题并进一步提升MySQL 兼容性。
Stale Read
Stale Read 适用于读多写少并且能够容忍读到旧数据的场景。例如 Twitter 用户发出一条消息后,系统会产生成千上万甚至上亿次读取,并且新发出的消息在一定时间后被读到是可以容忍的。该场景给数据库带来相当大的读并发压力,可能会产生读热点,导致节点的负载分布不均,整体吞吐成为瓶颈。借助 Stale Read, 用户可以指定一个过去的时间点从任意一个数据副本读取数据(不必从 leader 读取) ,从而显著分散节点的压力负载,使得整体读吞吐能力提升近一倍。
/* 例如:可以通过设置当前事务为查询 5 秒之前的数据状态来开启 Stale Read */ > SET TRANSACTION READ ONLY AS OF TIMESTAMP NOW() - INTERVAL 5 SECOND; > SELECT * FROM T;
快速定位锁冲突 (实验特性)
业务开发需要很谨慎地处理数据库并发事务,一旦发生锁表会给线上业务带来巨大影响,而 DBA 需要快速定位锁表原因以保证业务能够恢复正常。TiDB 5.1 中新增 Lock View 系统表视图,可以快速定位到引起锁表的事务和相关 SQL 语句,从而 提高锁冲突问题的处理效率 。下面一个小例子展示如何使用 Lock View 快速定位发生锁表的事务和 SQL 语句。
更快更准的统计信息分析
随着业务数据持续不断的变更,表的统计信息也会变得陈旧,进而导致优化器执行计划准确度降低,使得查询变慢。DBA 通过执行 ANALYZE 操作,对表的统计信息进行重建。 TiDB 5.1 对 ANALYZE 采样算法的性能进行了优化,生成统计信息的平均时间缩减为三分之一 ,同时新增一项新的统计数据类型,让优化器选择索引更加准确。
超多数量表的备份优化
优化超多数量表的备份,在 50k 张表的量级下,TiDB 集群全量备份时间降低到之前的 30~40% 。此外, 5.1 版本优化了备份模块的元信息文件组织形式(简称v2),启动 BR 时可以通过指定参数 “--backupmeta-version=2” 来启用 v2,从而减少单次写入量来降低内存消耗,有效避免低规格内存(≤8GB)环境下的异常退出。
提升大规模集群运维可靠性
TiDB 集群规模越大对生产集群扩缩容、硬件升级以及节点搬迁等日常运维操作的耗时就越久。TiDB 5.1 显著提升了扩缩容时数据迁移的性能,以下是两组测试结果:
优化内存使用
内存溢出(Out Of Memory)一直是困扰数据库行业的典型问题,5.1 版本针对 TiDB 的内存使用进行了一系列优化,从而降低 OOM 风险:
提升 CDC 同步链路可靠性
TiCDC 5.1 在无需人工干预的情况下提供同步链路的可靠性:当发生环境扰动或硬件故障时,TiCDC 可以保证同步持续进行;即使发生同步中断,TiCDC 也会根据实际情况自动进行重试。
最后,特别感谢小米、奇虎 360、知乎、爱奇艺、理想汽车、新浪、虎牙、小电、跨越速运、亿玛科技等公司和社区开发者们在 TiDB 5.1 版本的设计、开发和测试过程中做出的贡献,是你们一如既往的支持,帮助 TiDB 在实际场景中持续提升开发者和 DBA 的使用体验,让 TiDB 变得更加简单易用。
点击 【文末链接】 查看 TiDB 5.1 Release Notes,立即 下载试用 ,开启 TiDB 5.1 之旅。
来自 “ ITPUB博客 ” ,链接:https://blog.itpub.net/69994146/viewspace-2779387/ ,如需转载,请注明出处,否则将追究法律责任。