Tidb性能对比(v3.0.12 VS v4.0.0-rc)

1、环境说明

一、集群部署以及配置

Tidb性能对比(v3.0.12 VS v4.0.0-rc)

二、部署状况

a、在一套服务器上同时部署v3和v4两个版本的两个集群,可是不一样时启动,压测哪一个版本的时候启动哪一个集群,保证两个集群不相互影响,同时也保证了底层的硬件资源环境相同
b、部署集群用的参数都是默认参数,没有作过特殊修改sql

2、测试

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

一、测试结果

Tidb性能对比(v3.0.12 VS v4.0.0-rc)

二、测试说明

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

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(64) NOT NULL DEFAULT '' COMMENT '',
  `storage_type` int(11) NOT NULL COMMENT '',
  `bucket_type` int(11) NOT NULL COMMENT '',
  `bucket_name` varchar(64) 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、Tidb三、Tidb4的速度ide

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工具

三、测试过程

a、下图是Mysql上的结果,这个SQL跑出来须要8分钟4秒
Tidb性能对比(v3.0.12 VS v4.0.0-rc)
b、下图是v4.0.0-rc版本,没有开启tiflash副本的结果,这个SQL跑出来须要25秒
Tidb性能对比(v3.0.12 VS v4.0.0-rc)
Tidb性能对比(v3.0.12 VS v4.0.0-rc)性能

c、下图是v4.0.0-rc版本,开启1个tiflash副本的结果,这个SQL跑出来须要7.5秒
Tidb性能对比(v3.0.12 VS v4.0.0-rc)
d、下图是v3.0.12的版本,这个SQL跑出来须要32秒
Tidb性能对比(v3.0.12 VS v4.0.0-rc)测试

3、总结

一、Tidb 4.0 对于AP场景,在不开启Tiflash的状况下,相对于3.0的版本性能 提高不太明显,可是开启Tiflash副本的话,性能提高特别大,我上面的场景提高了4倍
二、咱们使用Tidb主要是两个场景,一个是大数据量解决Mysql分库分表的问题,不须要业务方写业务逻辑,也不依赖中间件,平滑从Mysql迁移到Tidb;另外一个场景是AP场景,咱们把生产环境的多个库经过DM汇聚到Tidb集群作报表、统计相关业务
三、Tidb 4.0,最吸引个人就是数据存储同时支持行存(tikv)+列存(tiflash),而且能够独立分开部署,相互不影响,用户无需关系本身的查询是AP仍是TP,Tidb会本身判断
四、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上没法执行,这个也反馈给官方大数据

相关文章
相关标签/搜索