自 TiDB 5.0 发布以来,陆续在金融、互联网 & 新经济、物流等行业用户的生产环境得到应用,收获不少用户的积极评价:
TiDB 服务 58 金融、安居客等数仓报表的复杂读取与关联查询,在多表关联查询中,相比 4.0 版本性能最高提升达 90%;
经过网易互娱场景实测,与 4.0 相比 TiDB 5.0 整体性能表现更加稳定,没有出现明显的抖动;
TiDB 5.0 在汽车之家大数据 join 与聚合场景的应用中,MPP 体现出明显的优势,与 MySQL 相比总体效能提升 20 - 50 倍。
“用户的反馈激励我们不断前行,我们的使命是持续提升开发者和 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 的效率,增强代码的可维护性。
5.1 版本进一步增强TiFlash MPP 计算引擎的综合能力,帮助用户提升业务决策速度:
在金融类业务场景下,技术人员每天会对数据进行高压力的跑批计算,生成最新的市场和营销分析报告,以辅助商业决策。跑批流程对连续性要求极高,无法容忍中间过程出错。针对该场景,5.1 版本优化了 TiDB 的请求重试机制和 TiKV 的请求处理机制,显著降低了在高负载下由于 TiFlash 同步数据不及时导致的 Region Unavailable 出错概率。
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 适用于读多写少并且能够容忍读到旧数据的场景。例如 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 风险:
TiCDC 5.1 在无需人工干预的情况下提供同步链路的可靠性:当发生环境扰动或硬件故障时,TiCDC 可以保证同步持续进行;即使发生同步中断,TiCDC 也会根据实际情况自动进行重试。
最后,特别感谢小米、奇虎 360、知乎、爱奇艺、理想汽车、新浪、虎牙、小电、跨越速运、亿玛科技等公司和社区开发者们在 TiDB 5.1 版本的设计、开发和测试过程中做出的贡献,是你们一如既往的支持,帮助 TiDB 在实际场景中持续提升开发者和 DBA 的使用体验,让 TiDB 变得更加简单易用。
点击查看 TiDB 5.1 Release Notes,立即下载试用,开启 TiDB 5.1 之旅。
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。