老房说数·第五期 ## TiDB 4.0 剧透

上一期的“老房说数”我和大家聊了聊大家对 TiDB 的第一印象,很多新老朋友都用三个词总结了自己的印象,出现频率最高的有兼容 MySQL、高可用、弹性扩展等。感谢大家的分享,希望能和社区的小伙伴一起共建社区,将 TiDB 打磨得更加稳定和易用。

上期踊跃参与话题的几位小伙伴 @haruki @samyubw @maiyang @benmaoer @James @navyaijm2017 @huoshao @kissdb @jiashiwen @xiamengyu @fushaofeng @secooler @aierui @jeanron100 @李文杰 @sh-hanson 也都获得了 “TiDB 初级学者”的徽章。小提示:在 AskTUG 积极收集徽章年底将会有小惊喜哦~

今天的老房说数想和大家分享一些 TiDB 4.0 版本的情况。据我了解,TiDB 4.0 在易用性、稳定性和性能上相比 3.0 将会有大幅提升,我这里简单挑选一些。

易用性:

  • 支持通过 SQL 收集和诊断 TiDB 集群所有节点的运行状态,以后的方向能用 SQL 解决的就不要脚本,会有大量的系统视图,select anything、我个人觉得这点很赞;
  • 规范错误码,完善日志内容,完善慢查询日志和 explain analyze 输出内容等;
  • 通过 statement summary 功能进一步提升调查异常性能问题的效率;
  • 通过 key Visualizer 快速定位热点问题;
  • 支持 10GB 的大事务,4.0 以后大部分业务都再也不用为拆分事务而烦恼了。

稳定性:

  • 提供更为完善的 View、Plan Cache、Generated Column 和 SQL Hint 等功能;
  • 通过 SQL Plan Baseline 进一步增加执行计划的稳定性,进一步降低索引选错的概率;
  • 支持 Hash Join 等算子将中间结果写入磁盘的功能,使得部分场景下 TiDB OOM 的风险进一步降低。

性能:

  • 优化 Index Join 和 Hash Aggregate;
  • 优化 TiDB 和 TiKV 之间数据传输格式;
  • 新增大量函数下推到 TiKV Coprocessor,这些都会使得 TiDB 4.0 的性能整体上相比于 3.0 有大幅提升。

新功能:

  • 新增支持快速备份和恢复的 BR 工具;
  • 支持基于存储层增量同步机制的 CDC,类似全局一致的 redo log;
  • Follower Read ,进一步解决极端场景下的热点问题;并且通过本地读、大大提升了跨 IDC 单表多活场景下的读性能;
  • 4.0 的 TiDB 还可以读取 TiFlash 列存副本,通过集群提供的隔离区和列存副本的功能,将在 HTAP 之路上迈出能够隔离和融合 TP、AP 查询的重要一步。

你期待 TiDB 4.0 的发布吗?对于以上的“剧透”有没有什么看法或建议呢?哪些是你最期待的?或则你有什么想提的需求吗?欢迎留言一起探讨

另外,下周一 AskTUG 将发布一个神秘活动,和⎡TiDB Roadmap⎦规划息息相关,请大家拭目以待~

6赞

房老师,TiDB 4.0什么时候GA?年期么?

1赞

4.0 真正 GA 预期明年 6 月份,不过之前我们把部分功能 pick 到 3.1(近期就会发)、3.2 版本(大概明年 2 月份)

2赞

非常期待,到时好好测测

1赞

666,期待~

1赞

期待啊

1赞

有了TiFlash列存引擎,TiSpart是不是逐渐的推出历史舞台?

1赞

非常期待,4.0 的写入性能还可以大幅度提升么 后续考虑和硬件结合做优化么,比如RDMA

1赞

TiFlash 出现后,还会有几个阶段,第一个阶段 TiFlash + Tispark、第二阶段 TiFlash + TiDB、第三阶段 TiDB 优化器会动态路由 TiKV + Tiflash,Tispark 作为一个独立计算引擎,还是会存在比较长时间的。

灰常期待,4.0的性能提升有数据嘛,读写场景下分别提升多少那?物理备份有消息么,几十T的数据逻辑备份搞不动那。。。

1赞

据我所知,4.0 会在软件层面去降低对硬件的要求,比如 单 TiKV instance 会降低到 8 vc、磁盘也会通过冷热分离的方式,支持将冷数据放到性能较低的磁盘上。TiDB 会很重视做通用方案,硬件强绑定的方案目前不会。

物理备份(BR 严格上属于逻辑物理备份)现在已经有个 beta 版,可以测试了。BR 也会在 3.1 版本里出现,3.1 版本只支持全量备份。

新增支持快速备份和恢复的 BR 工具;

先点个赞。

非常期待这个,想了解一下目前的实现效果,基于物理文件的快照,还是比如对 KV 层 checkpoint 的拷备,又或者是基于 DB 层的逻辑复制?

现在可以通过哪些渠道进行测试和了解呢?

最后再点个赞

1赞

房老师,4.0会上线统一线程池么

你说的 TiDB 层的线程池吗? 没有明确规划。

可以理解为 全局一致的 KV scan ,不在通过 TiDB 计算层。但也不是直接拷贝物理文件,测试效果和物理拷贝性能很接近。

3.1 发布就可以试用了,如果还着急,可以加下我微信,我们给你一个版本。

校长,关于 BR, CDC, Binlog 各自的适用场景能介绍下么?

Follower Read ,TiFlash,BR :ox:

厉害了

BR 工具,有点类似 MySQL extrbackup 或者 Oracle RMAN 的物理备份工具,跳过计算层,直接从存储层进行备份,用于存储的快速全量数据备份;

CDC 可以理解为通过存储做的增量日志,有点类似 oracle redo log,做增量数据备份,后面也可以考虑进行数据复制和订阅,类似 oracle logminer。

Binlog 类似 MySQL,是从计算层产生增量日志,目前用于数据的复制、和数据订阅,但因为 TiDB 计算节点是多节点,所以需要一个全局排序的操作,导致现在整个 binlog 链路很强,等 CDC 成熟后,会更多引导使用 CDC。