mycat cobar amoebar报告

1、目录第1章 引言11.1 编写目的11.2 项目背景1第2章 测试概要12.1 cobar 1.2.712.1.1 测试目的12.1.2 测试环境12.1.3 测试数据22.1.4 测试用例和运行方式22.2 mycat32.2.1 测试目的32.2.2 测试环境32.2.3 测试数据42.2.4 测试用例52.3 大表72.3.1 概念描述72.3.2测试目的72.3.3 测试环境82.3.4 测试用例9第3章 测试结果153.1 cobar 1.2.7153.1.1 cobar 性能测试153.1.2 cobar稳定性测试163.1.3 cobar测试局限性163.2 mycat173.2

2、.1 mycat性能测试173.2.3 mycat测试局限性183.2.2 mycat之mysql函数关键字测试183.3 大表193.3.1 大表查询与原查询之间的执行时间比较193.3.2 不同数据量之间的执行时间比较203.3.3 优化前后大表查询性能的比较21第4章 测试结论与建议234.1 测试结论234.2建议23第1章 引言第1章 引言1.1 编写目的本测试报告为MySQL代理项目的测试报告，目的在于总结测试阶段的测试以及分析测试结果。预期参考人员包括测试人员，项目管理者和其他需要阅读本报告的相关人员。1.2 项目背景随着传统的数据库技术日趋成熟，计算机网络技术的飞速发展和应用范

3、围的扩充，数据库应用已经普遍建立于计算机网络之上，这时集中式数据库系统表现出它的不足：集中式处理，势必造成性能瓶颈应用程序集中在一台计算机上运行，一旦该计算机发生故障，则整个系统受到影响，可靠性不高。集中式处理引起系统的规模和配置都不够灵活，系统的可扩充性差。在这种形势下，集中式数据库将向分布式数据库发展成为一种必然的趋势，而cobar，mycat均致力于mysql的分布式数据库前端代理层，对cobar及mycat进行相关的测试是将其应用于实际的首要前提。24第2章 测试概要第2章 测试概要本项目主要针对mysql的代理中间件进行了性能，稳定性，功能测试，分别对cobar及Mycat进行了相关

4、的测试，下面就cobar及mycat的测试情况分别展开。2.1 cobar .1 测试目的对cobar1.2.7进行性能测试及稳定性测试，其中性能测试是通过其与MYSQL的对比，及对其自身的性能评估来进行的。2.1.2 测试环境本实验采用分布式架构，使用了四台服务器，其中两台服务器作为mysql服务器，一台作为cobar服务器，一台用作Jmeter监听服务器，如图2.1所示：服务器ACobar服务器CMysql服务器 AJmeter服务器BCobar 图 2.1 cobar测试环境架构图1） 硬件环境主机/ip硬件配置操作系统及内核版本服务器A16CP

5、U8 Intel(R) Xeon(R) CPU E5420 2.40GHzCentOS release 6.4 (Final)Linux version 2.6.32-358.el6.x86_64内存32G网络1000M服务器B17CPU8 Intel(R) Xeon(R) CPUE5420 2.40GHzCentOS release 6.4 (Final)Linux version 2.6.32-358.el6.x86_64内存32G网络1000M服务器C18CPU8 Intel(R) Xeon(R) CPUE5420 2.40GHzCen

6、tOS release 6.4 (Final)Linux version 2.6.32-358.el6.x86_64内存32G网络1000M2） 软件环境软件名称版本备注1JDK1.6.0_25服务器A、B、C2mysql5.1.40服务器C3Jdbc Driver5.1.16服务器A4Cobar1.2.7服务器B，C2.1.3 测试数据1) 单字段拆分，拆分字段为int类型2) 16个分库3) 所有select场景，拆分库16个分库一共90w条数据，平均分布于每个分库，每次查询的数据平均落在各查询分库。2.1.4 测试用例和运行方式cobar性能测试用例1.cobar1.2.7 与 mysq

7、l 对比选取单条语句插入或查询与Mysql进行对比，每条sql语句插入或者查询的数据量分别为128B，2K和64K2.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个分库进行比较，只比较查

8、询效率，查询时结果平均分布在4个库或16个库中。cobar稳定性测试用例采用多个场景混合运行的方式测试cobar的稳定性，包括不同并发，不同分库下的插入和查询，单条记录数据量分别为128B，2K，64K，多库情况下，每条sql访问的记录数为2-1000，分别落入1-16个分库cobar性能运行方式每个用例选取不同并发，每个并发运行3分钟cobar 稳定性测试运行方式多用例混合运行：每个用例一个并发，同时运行所有用例。注：每条sql访问1-1000个记录不等。2.2 mycat2.2.1 测试目的在分布式的环境中对mycat进行性能，功能及mysql中的函数，关键字在mycat中可用性测试，找出

9、mycat的性能瓶颈，测试出mysql中哪些函数或关键字在进行跨库的数据操作时会出现错误。2.2.2 测试环境实验在分布式环境下进行，一共使用4台服务器，其中3台作为mysql服务器，一台作为mycat服务器，其架构图如图2.2所示：Mycat服务器Mysql服务器2Mysql服务器1Mysql服务器3图2.2 mycat测试环境架构图1）硬件环境主机/ip硬件配置操作系统及内核版本服务器116CPU8 Intel(R) Xeon(R) CPU E5420 2.40GHzCentOS release 6.4 (Final)Linux version 2.6.32-35

10、8.el6.x86_64内存32G网络1000M服务器217CPU8 Intel(R) Xeon(R) CPUE5420 2.40GHzCentOS release 6.4 (Final)Linux version 2.6.32-358.el6.x86_64内存32G网络1000M服务器318CPU8 Intel(R) Xeon(R) CPUE5420 2.40GHzCentOS release 6.4 (Final)Linux version 2.6.32-358.el6.x86_64内存32G网络1000M2）软件环境软件名称版本备注1J

11、DK1.6.0_25服务器A、B、C2mysql5.1.40服务器C3Jdbc Driver5.1.16服务器A4Cobar1.2.7服务器B，C2.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行，regio

12、n固定为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：selectl_returnflag,l_linestatus,sum(l_quantity) as sum_qty,sum(l_extendedprice

13、) as sum_base_price,sum(l_extendedprice*(1-l_discount) as sum_disc_price,sum(l_extendedprice*(1-l_discount)*(1+l_tax) as sum_charge,avg(l_quantity) as avg_qty,avg(l_extendedprice) as avg_price, avg(l_discount) as avg_disc,count(*) as count_orderfromlineitemwherel_shipdate = date DATEand l_shipdate d

14、ate DATE + interval 1 yearand l_discount between DISCOUNT - 0.01 and DISCOUNT + 0.01and l_quantity = 1993-07-01AND STR_TO_DATE(table1.ElementValue,%Y-%m-%d) 1993-07-01 + INTERVAL 3 MONTHAND table2.TableName = table1.TableNameAND table2.TupleNum = table1.TupleNumAND table2.PropertyName = O_ORDERPRIOR

15、ITYAND EXISTS (SELECT*FROMnewtable table5,newtable table6WHEREtable5.TableName = lineitemAND table5.PropertyName = L_COMMITDATEAND table6.TableName = lineitemAND table6.PropertyName = L_RECEIPTDATEAND STR_TO_DATE(table5.ElementValue,%Y-%m-%d %k:%i:%s) = 1994-01-01AND STR_TO_DATE( t_shipdate.ElementV

16、alue, %Y-%m-%d ) 1994-01-01 + INTERVAL 1 YEAR)UNION ALL(SELECTt_quantity.TupleNumFROMnewtable t_quantityWHEREt_quantity.TableName = lineitemAND t_quantity.PropertyName = l_quantityAND (t_quantity.ElementValue + 0) 2) AS t_tuple,newtable val_extendedprice,newtable val_discountWHEREval_discount.TableN

17、ame = lineitemAND val_discount.PropertyName = l_discountAND val_discount.TupleNum = t_tuple.TupleNumAND val_extendedprice.TableName = lineitemAND val_extendedprice.PropertyName = l_extendedpriceAND val_extendedprice.TupleNum = t_tuple.TupleNum;重写后的第12条查询语句SELECTt_l_shipmode.ElementValue AS L_SHIPMOD

18、E,sum(CASEWHEN t_o_orderpriority.ElementValue = 1-URGENTOR t_o_orderpriority.ElementValue = 2-HIGH THEN1ELSE0END) AS high_line_count,sum(CASEWHEN t_o_orderpriority.ElementValue 1-URGENTAND t_o_orderpriority.ElementValue 2-HIGH THEN1ELSE0END) AS low_line_countFROM(SELECTt_result.TupleNumFROM(SELECTt_

19、receiptdate.TupleNumFROMnewtable t_receiptdate,newtable t_commitdateWHEREt_receiptdate.TableName = lineitemAND t_receiptdate.PropertyName = l_receiptdateAND STR_TO_DATE(t_receiptdate.ElementValue,%Y-%m-%d) = date 1994-01-01AND STR_TO_DATE(t_receiptdate.ElementValue,%Y-%m-%d) date 1994-01-01 + INTERV

20、AL 1 YEARAND t_commitdate.TableName = lineitemAND t_commitdate.PropertyName = l_commitdateAND t_commitdate.TupleNum = t_receiptdate.TupleNumAND STR_TO_DATE(t_commitdate.ElementValue,%Y-%m-%d %k:%i:%s) STR_TO_DATE(t_receiptdate.ElementValue,%Y-%m-%d %k:%i:%s)UNION ALLSELECTt_shipdate.TupleNumFROMnewt

21、able t_shipdate,newtable t_commitdateWHEREt_shipdate.TableName = lineitemAND t_shipdate.PropertyName = l_shipdateAND t_commitdate.TableName = lineitemAND t_commitdate.PropertyName = l_commitdateAND t_commitdate.TupleNum = t_shipdate.TupleNumAND STR_TO_DATE(t_shipdate.ElementValue,%Y-%m-%d %k:%i:%s)

22、2) AS t_tuple,newtable t_l_shipmode,newtable t_o_orderpriority,newtable t_o_orderkey,newtable t_l_orderkeyWHEREt_l_shipmode.TableName = lineitemAND t_l_shipmode.PropertyName = l_shipmodeAND t_l_shipmode.TupleNum = t_tuple.TupleNumAND t_l_orderkey.TableName = lineitemAND t_l_orderkey.PropertyName = l

23、_orderkeyAND t_l_orderkey.TupleNum = t_tuple.TupleNumAND t_o_orderkey.TableName = ordersAND t_o_orderkey.PropertyName = o_orderkeyAND t_o_orderkey.ElementValue = t_l_orderkey.ElementValueAND t_o_orderpriority.TableName = ordersAND t_o_orderpriority.PropertyName = o_orderpriorityAND t_o_orderpriority

24、.TupleNum = t_o_orderkey.TupleNumGROUP BYL_SHIPMODEORDER BYL_SHIPMODE;第3章 测试结果第3章 测试结果3.1 cobar .1 cobar 性能测试1.cobar1.2.7 与 mysql对比1） insert 语句： 5个并发以内，mysql 的处理能力大约是cobar的2倍，单条insert语句包含的数据量越大，性能差异会越小。大于5个并发后，cobar与mysql处理能力趋于一致。cobar在8个并发左右达到处理瓶颈，mysql在5个并发左右达到处理瓶颈2） select语句 ：20个并发以内，mysq

25、l 的处理能力大约是cobar的2倍，单条select语句包含的数据量越大，性能差异越小。大于20个并发后，cobar与mysql的处理能力趋于一致。cobar 在30-40个并发左右达到处理瓶颈，mysql在10-20个并发后达到处理瓶颈3） cobar1.2.7与mysql性能测试数据对比如表3.1所示表3.1 性能测试数据对比图语句单条数据量并发cobar1.2.7MysqlTPSRT（ms）TPSRT（ms）insert128B48017.19 0.50 14541.64 0.28 1213397.00 0.90 15394.49 0.78 2K44547.64 0.88 7746.7

26、1 0.52 126310.11 1.90 6688.23 1.79 64K4435.16 9.19 486.56 8.22 12370.33 32.40 459.34 26.12 select128B1017786.97 0.56 32011.03 0.31 5047672.21 1.26 46781.77 1.06 2K1012066.67 0.83 26873.43 0.37 5038876.89 1.54 42348.76 1.42 64K101139.89 8.77 1745.59 5.73 501468.81 40.85 1784.26 33.63 2.cobar1.2.7 自身评

27、估1） 并发数较小的时候，并发数的多少对Cobar的性能影响较大2） 限于网络带宽的限制，并发量和单条数据的大小密切相关3） Sql查询中带schema 与不带schema性能差距较小4） 各测试情况下性能数据如表3.2所示：表3.2 性能测试结果单条数据量数据量数据分布128BSelectInsert并发TPS并发TPS128B100016个分库10117.27 637.81 4个分库20123.87 -2016个分库103397.70 81459.84 4个分库205556.59 -2K100016个分库2038.21 88.21 4个分库2043.44 -2016个分库201561.56

28、 12344.70 4个分库201762.79 -64K1000（插入128）16个分库200.10 43.04 4个分库41.46 -2016个分库2075.20 1222.56 4个分库2082.29 -3.1.2 cobar稳定性测试多场景混合运行：运行4小时，未发生任何异常。3.1.3 cobar测试局限性1) 由于测试机器有限， mysql很多场景下，尤其是多库的场景，load非常高，而cobar并未到达其自身处理能力最大值2) 压力工具选用的jmeter，由于jmeter对于响应时间不足1ms情况不能精确显示，因此响应时间是通过TPS数据计算而得3) 由于场景过多，性能测试每个小场

29、景只运行3分钟，每隔30s取一次TPS数据进行计算，因此，场景初始化时的一些不稳定的TPS容易对测试总体结果造成一些小影响。3.2 mycat3.2.1 mycat性能测试1.分片表的插入性能测试；取较大并发线程，100；插入的数据，分别为100万、500万、1000万；测试结果如表3.3所示：表3.3 mycat插入性能测试结果1000000500000010000000平均TPSMyCAT1.2.3166391586815218MySQL156011492114243总时间（s）MyCAT1.2.360315657MySQL64335702就插入性能来讲，MyCAT1.2.3的插入性能大概

30、是MySQL的88%-94%左右；查询性能测试以1000万的数据为准；分片表的查询性能测试；取较大并发线程：100；取的查询次数分别为：1000000、5000000、10000000，其测试结果如表3.4 所示：表3.4 mycat查询性能测试结果100000020000005000000平均TPSMyCAT1.2.311978171118836MySQL164542053610542总时间（s）MyCAT1.2.384117崩溃MySQL6197崩溃从结果来看，当执行1000000次查询时，MyCAT1.2.3的性能是MySQL的70%，当执行2000000条查询时，性能约为83%；3.更

31、新性能测试；分片表的更新性能测试；取较大并发线程：100；取的更新语句分别为：10000、50000、100000，其测试结果如表3.5所示：表3.5 mycat更新性能测试结果10000500001000002000005000001000000平均TPSMyCAT1.2.332261219514085141841312312642MySQL2439980410989116961039510091总时间（s）MyCAT1.2.3347143879MySQL459174899更新性能测试来讲，更新100000条数据时，性能比是75%，当数据量为50000时，性能比是80%，数据量为100000

32、时，性能比约为82%，50万时性能比约为79%，100万条时性能比约为80%。3.2.2 mycat稳定性测试在插入测试中，利用500并发线程插入1000万条数据，会发生部分数据丢失的情况，丢失的比率约为万分之一，插入时平均CPU占用率约为50-60%。在1000万行的数据上做查询操作，100线程并发，进行1000000次查询耗时84s，CPU占用率65%左右，进行2000000次查询耗时117s，CPU占用率80% 左右，5000000次查询等待2000s以上无响应。3.2.3 mycat测试局限性1) 由于测试机器有限， mysql很多场景下，尤其是多库的场景，load非常高，而mycat

33、并未到达其自身处理能力最大值2) 压力工具选用的jmeter，由于jmeter对于响应时间不足1ms情况不能精确显示，因此响应时间是通过TPS数据计算而得3) MyCAT不支持批量插入，以上的测试都是在非批量插入的情况下进行的测试，但MySQL是支持批量插入的，但这种场景下，我们没有办法比较两者之间批量插入的性能差异；同时，由于测量工具有限，不能对所有方面进行全面的比较，这也是我们测试的一个重大局限方面。3.2.2 mycat之mysql函数关键字测试经测试跨库操作会导致出错的函数如表3.6所示：表3.6 出错函数表函数类型函数测试用例错误描述聚合函数Avgselect avg（c_custk

34、ey）from customer where c_custkey49950 and c_custkey50050;数据分布在多个节点时，返回结果错误group_concatselect group_concat(c_nationkey) from customer group by c_nationkey;Mycat不支持该函数关键字Group byselect * from customer where c_custkey between 49910 and 50020 group by c_nationkey;数据分布在多个节点上，返回的结果没有归并的操作Distinctselect di

35、stinct(c_nationkey) from customer where c_custkey between 49910 and 50080 order by c_nationkey;数据分布在多个节点上，返回的结果没有归并的操作ANALYZEANALYZE table customer;Mycat不支持该函数Cross.joinselect * from orders cross JOIN customer on orders.o_custkey=customer.c_custkey where c_custkey=49910;Mycat不支持该函数数字类型转换函数Convertsel

36、ect convert(12,signed)Mycat不支持该函数字符串函数INSERTselect INSERT(Quadratic, 3, 1, What);Mycat不支持该函数Charselect CHAR(77,121,83,81,76)3.3 大表3.3.1 大表查询与原查询之间的执行时间比较这里我们将在两种数据量规模下进行测试：(1).第一个测试是在TPC-H生成的原数据量为10MB情况下测试的，此时通过我们的多线程导入程序将8个分表转换成大表的结构存储在服务器端的Mysql中，转换后大表的数据量为33.95MB，是原数据量的3.4倍。表3.7描述了不同查询的执行时间：表3.7大

37、表数据量为34MB的查询耗时对比分析表(单位：秒)测试1实验环境：单机；大表数据769108条，数据长度33.95 MB原查询(10MB)大表查询(33.95MB)耗时对比说明第4条查询0.0190.263大表查询的耗时是原查询的13.8倍第6条查询0.0380.463大表查询的耗时是原查询的12.2倍第12条查询0.0322.187大表查询的耗时是原查询的68.3倍(2).测试2中的原数据量为20MB，转换后大表的数据量为99.63MB，是原数据量的5倍。测试结果如表5-2所示，当数据规模增大时，大表查询的耗时会相应增长，但增长的幅度会根据查询语句的不同而有所差异，例如第4条查询与第12条查

38、询的时间增长幅度较小，而第6条查询语句的幅度增长较大。与原查询相比，大表查询的耗时平均比原查询多16.8倍。图3.8也可以直观看出大表查询与原查询之间的耗时对比。表3.8 大表数据量为100MB的查询耗时对比分析表(单位：秒)测试2实验环境：单机；大表数据2339755条，数据长度99.63 MB原查询大表查询耗时对比说明第4条查询0.0620.406大表查询的耗时是原查询的6.5倍第6条查询0.1753.962大表查询的耗时是原查询的22.6倍第12条查询0.2655.609大表查询的耗时是原查询的21.2倍3.3.2 不同数据量之间的执行时间比较在对比过原查询与大表查询效率之后，我们还做了纵向比较测试，将不同数据量下的原查询与大表查询进行了对比。如表3.9所示，对于原TPC-H数据表而言，数据量从10MB扩大到20MB，数据量增长了2倍，而进行测试的这3条SQL查询所用的时间，平均增加了5.4倍。对于大表查询来说，数据量增加了3倍，而重写后的查询语句耗时增加了4.2倍。可见当数据量增加时，转换为大表查询后，查询耗时并没有过快增长。表3.9 两种数据规模下耗时对比分析表(单位：秒)不同数据量对比实验环境：单机；大表数据769108条数据长度33.95 MB大表数据2339755条数据长度99.63 MB表中数据量从34MB增大到1