腾讯云数据库TDSQL--分布键的性能对比

目录

前序

一、腾讯云TDSQL架构

二、腾讯TDSQL的分布键性能对比

1、环境说明

2、测试结论

3、测试过程


前序

这篇文章我主要是用300万的表,来测试分布式的shadkey的性能优势;总的来说,多表关联查询时,如果走shardkey性能会根据分片数有质的提升,反之,如果不走shardkey,多表关联查询还不如单机;单表查询时,无论走不走分布键shadkey,性能都是优于单机的。

一、腾讯云TDSQL架构

TDSQL(MYSQL)是腾讯自研的一套基于MySQL内核云数据库,它集成数据库的运维、监控、备份、调优等于一身,优化传统数据库版本、集群、环境、监控比较混乱的情况,同时自主研发的区别传统的强同步功能和分布键shardkey,保证了数据的完整性的同时提高了数据库的性能,架构图摘自腾讯产品介绍:

二、腾讯TDSQL的分布键性能对比

1、环境说明

1.1此处我用了两套TDSQL集群,都是16C64G配置,一套为非分布式,类似单机,另外一套分布式4个分片;

1.2非分布式集群里有两个表lineitem_osk和orders_osk数据量都是300万,两表建有一个ORDERKEY字段值一样,其中lineitem_osk表里的ID字段和L_ORDERKEY,orders_osk表里的ID字段和O_ORDERKEY的值是一样的,目的是为了区分主键关联,非主键关联的查询性能,建表语句如下:

CREATE TABLE `orders_osk` (
  `id` bigint ,
  `O_ORDERKEY` bigint(20) unsigned NOT NULL ,
  `O_CUSTKEY` int(11) NOT NULL,
  `O_ORDERSTATUS` char(1) DEFAULT NULL,
  `O_TOTALPRICE` decimal(10,0) DEFAULT NULL,
  `O_ORDERDATE` date DEFAULT NULL,
  `O_ORDERPRIORITY` char(15) DEFAULT NULL,
  `O_CLERK` char(15) DEFAULT NULL,
  `O_SHIPPRIORITY` int(11) DEFAULT NULL,
  `O_COMMENT` varchar(79) DEFAULT NULL,
  PRIMARY KEY (`id`),
  UNIQUE KEY `O_ORDERKEY` (`id`)
);


CREATE TABLE `lineitem_osk` (
  `id` bigint ,
  `L_ORDERKEY` int(11) NOT NULL,
  `L_PARTKEY` int(11) NOT NULL,
  `L_SUPPKEY` int(11) NOT NULL,
  `L_LINENUMBER` int(11) NOT NULL,
  `L_QUANTITY` decimal(10,0) DEFAULT NULL,
  `L_EXTENDEDPRICE` decimal(10,0) DEFAULT NULL,
  `L_DISCOUNT` decimal(10,0) DEFAULT NULL,
  `L_TAX` decimal(10,0) DEFAULT NULL,
  `L_RETURNFLAG` char(1) DEFAULT NULL,
  `L_LINESTATUS` char(1) DEFAULT NULL,
  `L_SHIPDATE` date DEFAULT NULL,
  `L_COMMITDATE` date DEFAULT NULL,
  `L_RECEIPTDATE` date DEFAULT NULL,
  `L_SHIPINSTRUCT` char(25) DEFAULT NULL,
  `L_SHIPMODE` char(10) DEFAULT NULL,
  `L_COMMENT` varchar(44) DEFAULT NULL,
  PRIMARY KEY (`id`)
);

1.3分布式集群里有4个表(lineitem_osk和orders_osk,lineitem_ns和orders_ns),这两组表的区别是前面一组指定了分布键shardkey,后面一组没有指定,落在一个分片上,类似单机,建表语句:

CREATE TABLE `orders_osk` (
  `id` bigint ,
  `O_ORDERKEY` bigint(20) unsigned NOT NULL ,
  `O_CUSTKEY` int(11) NOT NULL,
  `O_ORDERSTATUS` char(1) DEFAULT NULL,
  `O_TOTALPRICE` decimal(10,0) DEFAULT NULL,
  `O_ORDERDATE` date DEFAULT NULL,
  `O_ORDERPRIORITY` char(15) DEFAULT NULL,
  `O_CLERK` char(15) DEFAULT NULL,
  `O_SHIPPRIORITY` int(11) DEFAULT NULL,
  `O_COMMENT` varchar(79) DEFAULT NULL,
  PRIMARY KEY (`id`),
  UNIQUE KEY `O_ORDERKEY` (`id`)
) shardkey=id;


CREATE TABLE `lineitem_osk` (
  `id` bigint ,
  `L_ORDERKEY` int(11) NOT NULL,
  `L_PARTKEY` int(11) NOT NULL,
  `L_SUPPKEY` int(11) NOT NULL,
  `L_LINENUMBER` int(11) NOT NULL,
  `L_QUANTITY` decimal(10,0) DEFAULT NULL,
  `L_EXTENDEDPRICE` decimal(10,0) DEFAULT NULL,
  `L_DISCOUNT` decimal(10,0) DEFAULT NULL,
  `L_TAX` decimal(10,0) DEFAULT NULL,
  `L_RETURNFLAG` char(1) DEFAULT NULL,
  `L_LINESTATUS` char(1) DEFAULT NULL,
  `L_SHIPDATE` date DEFAULT NULL,
  `L_COMMITDATE` date DEFAULT NULL,
  `L_RECEIPTDATE` date DEFAULT NULL,
  `L_SHIPINSTRUCT` char(25) DEFAULT NULL,
  `L_SHIPMODE` char(10) DEFAULT NULL,
  `L_COMMENT` varchar(44) DEFAULT NULL,
  PRIMARY KEY (`id`)
) shardkey=id;

2、测试结论

2.1 测试的SQL语句如下,注意其中的ID与L_ORDERKEY、O_ORDERKEY值是一样的,只是为了区分测试是不是shardkey的区别;

select count(*) from lineitem_osk a inner join orders_osk b on a.L_ORDERKEY=b.O_ORDERKEY where L_ORDERKEY<=21000000;

select count(*) from lineitem_osk a inner join orders_osk b on a.id=b.id where a.id<=21000000;

2.2分布式关联时走分布键性能比单机用主键关联时快两倍;

分布式多表联合关联不走分布键时,性能不如单机,甚至查不出来。

2.3 分布式库不指定分布键性能类似单机

3、测试过程

3.1分布式shardkey关联与单机主键关联对比

观察如下图的查询时间及执行计划,分布式关联走到分布键时速度2秒多,比单机快接近两倍,执行计划也是直接走每个分片的SIMPLE,速度很快,这里还能提升点,因为我4个分片都在一台主机上。

3.2分布式不用shardkey关联与单机非主键关联对比

分布式库关联如果不走shardkey我这次的环境是半个小时都没查出来,所以取消了;单机非主键关联比主键慢多了,但是依然比分布式的非shardkey关联快多了。

3.3分布式单表直接根据分布键查询与单机对比

单表查询根据分布键或者非分布键,分布式的速度都比单机快

  • 0
    点赞
  • 4
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值