mycat cobar amoebar报告.docx

上传人:b****6 文档编号:4688032 上传时间:2022-12-07 格式:DOCX 页数:30 大小:93.35KB
下载 相关 举报
mycat cobar amoebar报告.docx_第1页
第1页 / 共30页
mycat cobar amoebar报告.docx_第2页
第2页 / 共30页
mycat cobar amoebar报告.docx_第3页
第3页 / 共30页
mycat cobar amoebar报告.docx_第4页
第4页 / 共30页
mycat cobar amoebar报告.docx_第5页
第5页 / 共30页
点击查看更多>>
下载资源
资源描述

mycat cobar amoebar报告.docx

《mycat cobar amoebar报告.docx》由会员分享,可在线阅读,更多相关《mycat cobar amoebar报告.docx(30页珍藏版)》请在冰豆网上搜索。

mycat cobar amoebar报告.docx

mycatcobaramoebar报告

目录

第1章引言1

1.1编写目的1

1.2项目背景1

第2章测试概要1

2.1cobar1.2.71

2.1.1测试目的1

2.1.2测试环境1

2.1.3测试数据2

2.1.4测试用例和运行方式2

2.2mycat3

2.2.1测试目的3

2.2.2测试环境3

2.2.3测试数据4

2.2.4测试用例5

2.3大表7

2.3.1概念描述7

2.3.2测试目的7

2.3.3测试环境8

2.3.4测试用例9

第3章测试结果15

3.1cobar1.2.715

3.1.1cobar性能测试15

3.1.2cobar稳定性测试16

3.1.3cobar测试局限性16

3.2mycat17

3.2.1mycat性能测试17

3.2.3mycat测试局限性18

3.2.2mycat之mysql函数关键字测试18

3.3大表19

3.3.1大表查询与原查询之间的执行时间比较19

3.3.2不同数据量之间的执行时间比较20

3.3.3优化前后大表查询性能的比较21

第4章测试结论与建议23

4.1测试结论23

4.2建议23

第1章引言

1.1编写目的

本测试报告为MySQL代理项目的测试报告,目的在于总结测试阶段的测试以及分析测试结果。

预期参考人员包括测试人员,项目管理者和其他需要阅读本报告的相关人员。

1.2项目背景

随着传统的数据库技术日趋成熟,计算机网络技术的飞速发展和应用范围的扩充,数据库应用已经普遍建立于计算机网络之上,这时集中式数据库系统表现出它的不足:

●集中式处理,势必造成性能瓶颈

●应用程序集中在一台计算机上运行,一旦该计算机发生故障,则整个系统受到影响,可靠性不高。

●集中式处理引起系统的规模和配置都不够灵活,系统的可扩充性差。

在这种形势下,集中式数据库将向分布式数据库发展成为一种必然的趋势,而cobar,mycat均致力于mysql的分布式数据库前端代理层,对cobar及mycat进行相关的测试是将其应用于实际的首要前提。

 

第2章测试概要

本项目主要针对mysql的代理中间件进行了性能,稳定性,功能测试,分别对cobar及Mycat进行了相关的测试,下面就cobar及mycat的测试情况分别展开。

2.1cobar1.2.7

2.1.1测试目的

对cobar1.2.7进行性能测试及稳定性测试,其中性能测试是通过其与MYSQL的对比,及对其自身的性能评估来进行的。

2.1.2测试环境

本实验采用分布式架构,使用了四台服务器,其中两台服务器作为mysql服务器,一台作为cobar服务器,一台用作Jmeter监听服务器,如图2.1所示:

服务器A

Cobar

服务器C

Mysql

服务器A

Jmeter

服务器B

Cobar

图2.1cobar测试环境架构图

1)硬件环境

主机/ip

硬件配置

操作系统及内核版本

服务器A

218.193.154.216

CPU

8×Intel(R)Xeon(R)CPU   E5420 @2.40GHz

CentOSrelease6.4(Final)

Linuxversion2.6.32-358.el6.x86_64

内存

32G

网络

1000M

服务器B

218.193.154.217

CPU

8×Intel(R)Xeon(R)CPU   E5420 @2.40GHz

CentOSrelease6.4(Final)

Linuxversion2.6.32-358.el6.x86_64

内存

32G

网络

1000M

服务器C

218.193.154.218

CPU

8×Intel(R)Xeon(R)CPU     E5420 @2.40GHz

CentOSrelease6.4(Final)

Linuxversion2.6.32-358.el6.x86_64

内存

32G

网络

1000M

2)软件环境

软件名称

版本

备注

1

JDK

1.6.0_25

服务器A、B、C

2

mysql

5.1.40

服务器C

3

JdbcDriver

5.1.16

服务器A

4

Cobar

1.2.7

服务器B,C

2.1.3测试数据

1)单字段拆分,拆分字段为int类型

2)16个分库

3)所有select场景,拆分库16个分库一共90w条数据,平均分布于每个分库,每次查询的数据平均落在各查询分库。

2.1.4测试用例和运行方式

●cobar性能测试用例

1.cobar1.2.7与mysql对比

选取单条语句插入或查询与Mysql进行对比,每条sql语句插入或者查询的数据量分别为128B,2K和64K

2.cobar自身评估

1)所有cobar1.2.7相关的场景(除拆分库无拆分字段和非拆分库)都比较了sql中带schema和不带schema的差别

2)除1.中的对比场景中运行的场景之外,加入单条记录64K的查询语句以及多种插入语句场景。

多值插入场景,每条记录大小128B,2K,64K,记录随机分布1-16个库中,只有当记录大小为64K时,每条插入语句的记录条数为128,其余仍为1000。

3)cobar1.2.7不同分库情况下性能对比。

分别4个分库和16个分库进行比较,只比较查询效率,查询时结果平均分布在4个库或16个库中。

●cobar稳定性测试用例

采用多个场景混合运行的方式测试cobar的稳定性,包括不同并发,不同分库下的插入和查询,单条记录数据量分别为128B,2K,64K,多库情况下,每条sql访问的记录数为2-1000,分别落入1-16个分库

●cobar性能运行方式

每个用例选取不同并发,每个并发运行3分钟

●cobar稳定性测试运行方式

多用例混合运行:

每个用例一个并发,同时运行所有用例。

注:

每条sql访问1-1000个记录不等。

2.2mycat

2.2.1测试目的

在分布式的环境中对mycat进行性能,功能及mysql中的函数,关键字在mycat中可用性测试,找出mycat的性能瓶颈,测试出mysql中哪些函数或关键字在进行跨库的数据操作时会出现错误。

2.2.2测试环境

实验在分布式环境下进行,一共使用4台服务器,其中3台作为mysql服务器,一台作为mycat服务器,其架构图如图2.2所示:

Mycat服务器

Mysql服务器2

Mysql服务器1

Mysql服务器3

图2.2mycat测试环境架构图

1)硬件环境

主机/ip

硬件配置

操作系统及内核版本

服务器1

218.193.154.216

CPU

8×Intel(R)Xeon(R)CPU   E5420 @2.40GHz

CentOSrelease6.4(Final)

Linuxversion2.6.32-358.el6.x86_64

内存

32G

网络

1000M

服务器2

218.193.154.217

CPU

8×Intel(R)Xeon(R)CPU   E5420 @2.40GHz

CentOSrelease6.4(Final)

Linuxversion2.6.32-358.el6.x86_64

内存

32G

网络

1000M

服务器3

218.193.154.218

CPU

8×Intel(R)Xeon(R)CPU     E5420 @2.40GHz

CentOSrelease6.4(Final)

Linuxversion2.6.32-358.el6.x86_64

内存

32G

网络

1000M

2)软件环境

软件名称

版本

备注

1

JDK

1.6.0_25

服务器A、B、C

2

mysql

5.1.40

服务器C

3

JdbcDriver

5.1.16

服务器A

4

Cobar

1.2.7

服务器B,C

2.2.3测试数据

测试数据由两部分数据组成:

TPC-H数据和自定义数据。

TPC-H数据由TPC-H数据生成器生成,生成因子分别别SF=0.2;SF=2。

TPC-H的表结构如下图所示,在SF=2时生成的数据大小包括(lineitem表12000000行,orders表3000000行,partsupp表1600000行,part表400000行,customer表300000行,supplier表20000行,nation固定为25行,region固定为5行),其中lineitem表大约为500M的数据:

自定义数据由JAVA程序生成,由简单的单表构成,生成数据量为100万tuples、500万tuples和1000万tuples,表结构包括id和name两列,id为int类型,name为100个字符的char类型,用于数据插入及并发测试。

2.2.4测试用例

TPC-H测试用例包括TPC-H的语句Q1、Q6和Q13,涵盖了分组,聚集,连接,子查询等多种操作。

具体的查询语句如下:

Q1:

select

l_returnflag,

l_linestatus,

sum(l_quantity)assum_qty,

sum(l_extendedprice)assum_base_price,

sum(l_extendedprice*(1-l_discount))assum_disc_price,

sum(l_extendedprice*(1-l_discount)*(1+l_tax))assum_charge,

avg(l_quantity)asavg_qty,

avg(l_extendedprice)asavg_price,

avg(l_discount)asavg_disc,

count(*)ascount_order

from

lineitem

where

l_shipdate<=date'1998-12-01'-interval'[DELTA]'day(3)

groupby

l_returnflag,

l_linestatus

orderby

l_returnflag,

l_linestatus;

Q6:

select

sum(l_extendedprice*l_discount)asrevenue

from

lineitem

where

l_shipdate>=date'[DATE]'

andl_shipdate

andl_discountbetween[DISCOUNT]-0.01and[DISCOUNT]+0.01

andl_quantity<[QUANTITY];

Q13:

select

c_count,count(*)ascustdist

from

(select

c_custkey,

count(o_orderkey)

from

customerleftouterjoinorderson

c_custkey=o_custkey

ando_commentnotlike‘%[WORD1]%[WORD2]%’

groupby

c_custkey

)asc_orders(c_custkey,c_count)

groupby

c_count

orderby

custdistdesc,

c_countdesc;

自定义测试数据集的测试用例主要包括:

1.并发查询测试语句:

Select*FromtestWhereid=${Random(0,10000000)}

2.模拟插入语句insertintotest(id,name)values(?

?

)通过java连接到数据库中间件,进行插入并发插入操作,并发线程数为4到500。

2.3大表

2.3.1概念描述

将现有数据表中的每个属性值都存放在一张表的同一列中,同时存入该属性值所在表的名称、所在列的名称以及原表中所属行号信息,具体表结构如表2.1所示:

表2.1大表newtable的表结构

字段名

类型

是否为空

备注

RowID

int(11)

notnull

主键,自增,大表唯一ID

TableName

varchar(50)

null

原表中数据所在表的名称

TupleNum

int(11)

null

原表中数据所属行号

PropertyName

varchar(50)

null

原表中数据所在列名

ElementValue

varchar(150)

null

数据值

2.3.2测试目的

由于我们对数据存储的表结构进行了修改,所以针对原有表的SQL语句无法直接应用在大表上,需要对其进行修改,并通过多个查询语句模拟实现原来的SQL,从而达到原SQL语句的效果。

此外,由于大表结构的特殊性导致整张表的容量一定大于原有表的总和,而且其存储的元组数也远大于先前。

由于存在着上述两个因素,针对大表的查询效率一定会有所下降,所以基于大表的查询效率就成了重点关注的方面。

我们需要针对不同数据量大小的大表进行查询,并且分别在单结点和MyCat分布式结点上进行测试与比较。

通过测试,我们能够发现查询的瓶颈,并针对瓶颈提出优化方案,例如进行数据压缩、建立不同类型的索引、修改查询语句等优化操作,通过测试结果分析是否有提高效率的可能,最终找到最佳优化方案。

2.3.3测试环境

我们将测试分为两大块:

单机测试以及以mycat为代理的分布式环境测试。

●单机环境

目前实验室中的服务器安装的是64位CentOS6.4版本的Linux操作系统,网络带宽可以达到1000M,详细配置见表2.2。

表2.2单节点服务器配置

名称

说明

服务器

硬件配置:

操作系统:

CPU:

8×Intel(R)Xeon(R)CPU E5420@2.40GHz

CentOSrelease6.4(Final)

内存:

32G

网络带宽:

1000M

Mysql

版本:

5.1.66

●服务器集群环境

实验室环境中有3台服务可供测试使用,所以集群中可以设置3个结点,3个结点的配置信息以及IP地址在表2.3中列出。

表2.3服务器集群配置

主机/ip

硬件配置

操作系统及内核版本

服务器A

218.193.154.216

CPU

8×Intel(R)Xeon(R)CPUE5420@2.40GHz

CentOSrelease6.4(Final)

Linuxversion2.6.32-358.el6.x86_64

内存

32G

网络

1000M

服务器B

218.193.154.217

CPU

8×Intel(R)Xeon(R)CPU E5420@2.40GHz

CentOSrelease6.4(Final)

Linuxversion2.6.32-358.el6.x86_64

内存

32G

网络

1000M

服务器C

218.193.154.218

CPU

8×Intel(R)Xeon(R)CPU E5420@2.40GHz

CentOSrelease6.4(Final)

Linuxversion2.6.32-358.el6.x86_64

内存

32G

网络

1000M

此外,服务器集群中的mysql版本以及部署的mycat代理版本信息见表2.4。

表2.4集群环境的软件配置

Mysql

版本:

5.1.66

Mycat

版本:

1.3

2.3.4测试用例

采用TPC-H生成的数据进行测试,其中包括8张数据表,分别是customer,lineitem,nation,orders,part,partsupp,supplier和region表。

各个数据表中的列及其关系如图4.1所示。

TPC-H的标准SQL查询语句有22条,在测试过程中,我们选择了一些基本查询操作以及这22条查询中的部分SQL语句,对其进行了重写以便能够在新的大表结构中完成同样的查询操作。

●重写后的第4条查询语句:

SELECT

table2.ElementValueASO_ORDERPRIORITY,

COUNT(*)ASorder_count

FROM

newtabletable1,

newtabletable2

WHERE

table1.TableName="orders"

ANDtable1.PropertyName="O_ORDERDATE"

ANDSTR_TO_DATE(

table1.ElementValue,

"%Y-%m-%d"

)>='1993-07-01'

ANDSTR_TO_DATE(

table1.ElementValue,

"%Y-%m-%d"

)<'1993-07-01'+INTERVAL'3'MONTH

ANDtable2.TableName=table1.TableName

ANDtable2.TupleNum=table1.TupleNum

ANDtable2.PropertyName="O_ORDERPRIORITY"

ANDEXISTS(

SELECT

*

FROM

newtabletable5,

newtabletable6

WHERE

table5.TableName="lineitem"

ANDtable5.PropertyName="L_COMMITDATE"

ANDtable6.TableName="lineitem"

ANDtable6.PropertyName="L_RECEIPTDATE"

ANDSTR_TO_DATE(

table5.ElementValue,

"%Y-%m-%d%k:

%i:

%s"

table6.ElementValue,

"%Y-%m-%d%k:

%i:

%s"

GROUPBY

O_ORDERPRIORITY

ORDERBY

O_ORDERPRIORITY;

●重写后的第6条查询语句

SELECT

sum(

(val_extendedprice.ElementValue+0.0)

*(val_discount.ElementValue+0.0)

)ASrevenue

FROM

SELECTDISTINCT

t_result.TupleNum

FROM

SELECT

t_shipdate.TupleNum

FROM

newtablet_shipdate

WHERE

t_shipdate.TableName="lineitem"

ANDt_shipdate.PropertyName="l_shipdate"

ANDSTR_TO_DATE(t_shipdate.ElementValue,

"%Y-%m-%d")>='1994-01-01'

ANDSTR_TO_DATE(t_shipdate.ElementValue,

"%Y-%m-%d")<'1994-01-01'+INTERVAL'1'YEAR

UNIONALL

SELECT

t_quantity.TupleNum

FROM

newtablet_quantity

WHERE

t_quantity.TableName="lineitem"

ANDt_quantity.PropertyName="l_quantity"

AND(t_quantity.ElementValue+0)<24

UNIONALL

SELECT

t_discount.TupleNum

FROM

newtablet_discount

WHERE

t_discount.TableName="lineitem"

ANDt_discount.PropertyName="l_discount"

AND(t_discount.ElementValue+0)BETWEEN

0.06-0.01AND0.06+0.01

)ASt_result

GROUPBY

t_result.TupleNum

HAVING

COUNT(*)>2

)ASt_tuple,

newtableval_extendedprice,

newtableval_discount

WHERE

val_discount.TableName="lineitem"

ANDval_discount.PropertyName="l_discount"

ANDval_discount.TupleNum=t_tuple.TupleNum

ANDval_extendedprice.TableName="lineitem"

ANDval_extendedprice.PropertyName="l_extendedprice"

ANDval_extendedprice.TupleNum=t_tuple.TupleNum;

●重写后的第12条查询语句

SELECT

t_l_shipmode.ElementValueASL_SHIPMODE,

sum(

CASE

WHENt_o_orderpriority.ElementValue='1-URGENT'

ORt_o_orderpriority.ElementValue='2-HIGH'THEN

1

ELSE

0

END

)AShigh_line_count,

sum(

CASE

WHENt_o_orderpriority.ElementValu

展开阅读全文
相关资源
猜你喜欢
相关搜索

当前位置:首页 > 高中教育 > 理化生

copyright@ 2008-2022 冰豆网网站版权所有

经营许可证编号:鄂ICP备2022015515号-1