继续,来看看 TiDB 3.0 在 AP 方面的进步

第一篇: 周末了,一起来看看 TiDB 的 AP 能力

第一篇文章中,我们测试了 TiDB 2.1.15 在 AP 方面的能力,并且对比了我们自身 HE 的情况。本周继续文章结尾的结论,对比下今年发布的 TiDB 3.0 的 AP 性能。

这次偷个懒——上周太忙了——主要的测试环境/场景/方法就不赘言了,请见上文

测试报告的地址不变,依然是 http://106.75.77.137:8080/#/share/app/74BAA972/dashboard/F5EBF24C ,这次就不截图了,大家可以自己去看

我们重点关注一下测试报告的以下 3 个页面中 TiDB 2.1.15 和 3.0.0 的表现

http://106.75.77.137:8080/#/share/app/74BAA972/infographic/F5EBF24C/chart/4A1B60ED

http://106.75.77.137:8080/#/share/app/74BAA972/infographic/F5EBF24C/chart/BF18EE38

http://106.75.77.137:8080/#/share/app/74BAA972/infographic/F5EBF24C/chart/7E065BDA

目前看来,3 个柱状图中包含有 14 个 SQL 场景,其中 2 倍的提升有 2 个,不到 2 倍的有 11 个,差不多的有 1 个,也就是说绝大部分的 SQL 在 TiDB 2.1.15 和 TiDB 3.0.0 之间的差距在 1-2 倍的时间。

而在第一个柱状图的 Dashboard 场景中,回忆一下上文,打开 Dashboard 之后,会有 8 条 SQL 语句并发查询,而如下图所示,TiDB 2.1.5 和 3.0.0 之间的差距有 3 倍以上;可以看出从 2.1.15 到 TiDB 3.0.0,相对于上述 14 个单条 SQL 语句执行场景中的性能提升, TiDB 在处理 AP 的并发能力方面有了非常惊艳的提升。

初步测试, TiDB 3.0 作为 HTAP 系统,在典型业务场景并行查询和特定 SQL 查询性能上表现已经接近了即席查询的需求,作为含有 OLTP 功能的数据库,性能还是很让人惊艳的。在希望直接用业务数据库做部分分析需求的场景下,应该会有非常不错的表现。

行文至此,PingCAP 的同学告诉我们会有一个内部的 3.0 优化版本,会在这方面还有一定的提升,可以测试看看;同时,月底TiFlash内部版本如果可以上线的话,到时也可以做一个对比。我个人对此非常期待,等待下文吧(当然,还有我们承诺并漏掉的去 CAST 测试)。

3赞

棒~期待下文~

学习了,期待下一篇 :+1:

赞,tiflash 应该还会有进一步比较明显的提升

给力!

题主这个是三台server,1500w和1.5亿行数据量全表聚合查询吗? 水平扩展服务器对性能的增幅有多大呢,谢谢题主的贴子,最近选型愁在这呢。

是的,我们的场景也是直接怼明细表出结果,除了那种百亿级别以上需要跑批的 水平扩展主要看各自的设计了,一般数仓来说都会有线性的提升,从这个测试结果看,TiDB 3.0 相对于 2.0 的主要改善是在并发能力上,之前即使水平扩展,也可能受制于前端并发的增长而变得逐渐不可服务,这一点也是需要测试考虑的。 最近有点忙,这个系列好久没有更新了,后续考虑接着做完它

1赞

二级索引多字段多列聚合,几百秒出结果,我理解已经很优秀了,还是百亿级数据量,可以当近实时了吧。

这个执行是一定返回结果吗?有没有超时时间设置 另外发现没有提到索引的事,这个是不是完全没加索引?加索引会对聚合结果有很大优化吗,望回复谢谢。