【TiDB 4.0 试玩体验】TiDB 性能对比(v3.0.12 VS v4.0.0-rc)

一、环境说明

1、集群部署以及配置

IP 配置 部署角色 部署版本
172.21.xx.43 8C16G 500G SSD PD、Tidb v3.0.12、v4.0.0-rc
172.21.xx.44 4C8G 500G SSD PD、Monitoring v3.0.12、v4.0.0-rc
172.21.xx.45 4C8G 500G SSD PD v3.0.12、v4.0.0-rc
172.21.xx.46 8C16G 500G SSD Tikv v3.0.12、v4.0.0-rc
172.21.xx.47 8C16G 500G SSD Tikv v3.0.12、v4.0.0-rc
172.21.xx.48 8C16G 500G SSD Tikv v3.0.12、v4.0.0-rc
172.21.xx.49 8C16G 500G SSD Tiflash v4.0.0-rc
172.21.yy.4 16G32G 5T SSD Mysql 5.6.29

2、部署情况

a、在一套服务器上同时部署v3和v4两个版本的两个集群,但是不同时启动,压测哪个版本的时候启动哪个集群,保证两个集群不相互影响,同时也保证了底层的硬件资源环境相同

b、部署集群用的参数都是默认参数,没有做过特殊修改

二、测试

关于使用性能测试工具的测试结果,官方有相关数据,我这里用我们具体的一个业务场景来测试,就是一个统计的SQL

1、测试结果

表数据量 查询对象 查询耗时
9860万 Mysql 8分钟4秒
9860万 Tidb V3 32秒
9860万 Tidb V4 for Tikv 25秒
9860万 Tidb V4 for Tiflash 7.5秒

2、测试说明

a、这是一个记录对象存储文件记录的表,表里面的数据量大概是9860万,下面是表结构

CREATE TABLE `ois_file_record` (

  `id` int(11) unsigned NOT NULL AUTO_INCREMENT COMMENT '代理主键',

  `file_name` varchar(128) NOT NULL DEFAULT '' COMMENT '文件名称(包含后缀名)',

  `file_folder` varchar(64) NOT NULL DEFAULT '' COMMENT '文件夹名称(长度限制)',

  `file_key` varchar(255) DEFAULT NULL COMMENT '',

  `file_type` int(11) NOT NULL DEFAULT '6' COMMENT '',

  `file_size` bigint(11) NOT NULL DEFAULT '0' COMMENT '',

  `identify` varchar(32) NOT NULL DEFAULT '' COMMENT '',

  `storage_type` int(11) NOT NULL COMMENT '',

  `bucket_type` int(11) NOT NULL COMMENT '',

  `bucket_name` varchar(32) NOT NULL DEFAULT '' COMMENT '',

  `status` int(11) NOT NULL DEFAULT '1' COMMENT '',

  `is_delete` int(11) NOT NULL DEFAULT '0' COMMENT '',

  `create_time` datetime DEFAULT CURRENT_TIMESTAMP COMMENT '创建时间',

  `update_time` datetime DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP COMMENT '修改时间',

  PRIMARY KEY (`id`),

  KEY `idx_file_key` (`file_key`) USING HASH COMMENT '',

  KEY `idx_identify` (`identify`) USING HASH COMMENT ''

) ENGINE=InnoDB AUTO_INCREMENT=98603554 DEFAULT CHARSET=utf8 COMMENT='文件记录表' |

b、下面这个SQL是业务方用到的一个统计SQL,我们就用这个SQL对比下MySQL、TiDB3、TiDB4的速度

SELECT SUM(file_size) as fileSize,COUNT(id) as fileCount,DATE_FORMAT(create_time,'%Y-%m-%d') as dateTime FROM ois_file_record WHERE identify = 'vehicle' and storage_type = 4 and bucket_type = 2 and is_delete = 0 and create_time > '2019-12-01 00:00:00' and file_key LIKE '%/video_data/%' GROUP BY DATE_FORMAT(create_time,'%Y-%m-%d') \G

2、测试过程

a、下图是MySQL上的结果,这个SQL跑出来需要8分钟4秒

b、下图是v4.0.0-rc版本,没有开启TiFlash副本的结果,这个SQL跑出来需要25秒 c、下图是v4.0.0-rc版本,开启1个TiFlash副本的结果,这个SQL跑出来需要7.5秒 d、下图是v3.0.12的版本,这个SQL跑出来需要32秒

三、总结

1、TiDB 4.0 对于AP场景,在不开启TiFlash的情况下,相对于3.0的版本性能 提升不太明显,但是开启TiFlash副本的话,性能提升特别大,我上面的场景提升了4倍。

2、我们使用TiDB主要是两个场景,一个是大数据量解决MySQL分库分表的问题,不需要业务方写业务逻辑,也不依赖中间件,平滑从MySQL迁移到TiDB;另一个场景是AP场景,我们把生产环境的多个库通过DM汇聚到TiDB集群做报表、统计相关业务。

3、TiDB 4.0,最吸引我的就是数据存储同时支持行存(TiKV)+列存(TiFlash),并且可以独立分开部署,相互不影响,用户无需关系自己的查询是AP还是TP,TiDB会自己判断

4、4.0毕竟刚RC了几天,还是有些小问题的,但是官方响应很积极,我觉得这也是为啥TiDB能发展这么好很重要的原因吧,我测试过程中遇到几个问题如下:

a、TiUP部署的时候,Y/N那块如果输入一个其他字符,程序就直接退出了,我觉得这块应该优化下,判断用户输入的不是Y或者N的话就一直让用户输入,而不是直接退出

b、TiUP用普通用户部署的时候不成功,我的这个普通用户从中控机到目标机已经做好了ssh免密码登录,并且有sudo权限,这块也反馈给官方了。

c、集群停止在启动之后,监控页面Services Port Status没数据了,这块也反馈给官方了。

d、4.0和3.0对于only_full_group_by的处理应该是不一样了,我3.0和4.0的sql_mode完全一样,但是上面的SQL在4.0上无法执行,这个也反馈给官方。

7赞

抱歉,由于 date_format 函数阻止了 TiFlash 进一步加速(主要是聚合就没办法在 TiFlash 计算了),因此其实这个对比测试性能还是低于研发这边的期望不少的,可以去掉这个函数试试看。date_format 支持正在进行中,我们会第一时间更新。也欢迎大家联系我们,这样可以得到更详细的建议和更及时的优化更新。

给力!

感谢投稿 TiDB 4.0 试玩体验文章,这篇干货经验将帮助广大 TiDB 用户更好的使用 TiDB !

我们将为您寄出 TiDB 限量 T 恤及日历文具礼盒一份,请联系 TiDB Robot(Wechat ID: tidbai)提供邮寄地址哦~(请备注:投稿领取周边)。

1赞

太给力了

期待更多反馈 :robot: TiDB 4.0 捉“虫”竞赛也开启了,感兴趣的话也可以参与哦 : https://pingcap.com/community-cn/tidb-bug-hunting/