Mycat基准测试报告 原
好久没上OSC，上面安排测下Mycat，于是申请服务器，花了两个周做出这个东西，供以借鉴。
一、测试目标
MyCAT 是一个彻底开源的，面向企业应用开发的“大数据库集群” 支持事务、ACID、可以替代Mysql的加强版数据库 。一个可以视为“Mysql”集群的企业级数据库，用来替代昂贵的Oracle集群 。 一个融合内存缓存技术、Nosql技术、HDFS大数据的新型SQL Server ? 结合传统数据库和新型分布式数据仓库的新一代企业级数据库产品 。 一个新颖的数据库中间件产品。
目标
低成本的将现有的单机数据库和应用平滑迁移到“云”端，解决数据存储和业务规模迅速增长情况下的数据瓶颈问题。
关键特性
支持 SQL 92标准 支持Mysql集群，可以作为Proxy使用 支持JDBC连接ORACLE、DB2、SQL Server，将其模拟为MySQL Server使用 支持galera for mysql集群，percona-cluster或者mariadb cluster，提供高可用性数据分片集群，自动故障切换，高可用性 ，支持读写分离，支持Mysql双主多从，以及一主多从的模式 ，支持全局表，数据自动分片到多个节点，用于高效表关联查询 ，支持独有的基于E-R 关系的分片策略，实现了高效的表关联查询多平台支持，部署和实施简单。
优势
基于阿里开源的Cobar产品而研发，Cobar的稳定性、可靠性、优秀的架构和性能，以及众多成熟的使用案例使得MyCAT一开始就拥有一个很好的起点，站在巨人的肩膀上，我们能看到更远。广泛吸取业界优秀的开源项目和创新思路，将其融入到MyCAT的基因中，使得MyCAT在很多方面都领先于目前其他一些同类的开源项目，甚至超越某些商业产品。MyCAT背后有一只强大的技术团队，其参与者都是5年以上资深软件工程师、架构师、DBA等，优秀的技术团队保证了MyCAT的产品质量。 MyCAT并不依托于任何一个商业公司，因此不像某些开源项目，将一些重要的特性封闭在其商业产品中，使得开源项目成了一个摆设。
测试目标
为验证Mycat实际生产中是否能够如官方介绍所述能够处理亿级数据，解决公司现有项目数据存储操作性能问题，特进行Mycat基准测试，由于mycat单库与mysql单库在各项指标基本一致，本测试主要测试mycat分片情况下与mysql单库的性能差异。本次测试主要目标如下：
1、测试分片后性能是否有提升
2、测试在1亿数据量下的常规操作，是否快速有效。
3、测试Mycat性能是否随Mysql实例数呈线性增长
预测结果
1、相对于单台，分布式mycat数据库集群响应时间应该大于单台单库的响应能力，但随着数据增长，数据库集群响应时间基本不变，而后者则会发生极大的变化，应该成凸型增长。
2、单台单库情况下，查询性能应该随数据量呈负增长。
3、Mycat管理下的mysql实例越多，性能提升越大。
二、测试指标
2.1 并发数
指同时访问服务器站点的链接数。
2.2 响应时间
一次请求到请求完成消耗的时间，本文指的一般是平均响应时间。
2.3 QPS（TPS）
一个系统吞吐量通常由QPS（TPS）、并发数两个因素决定，每套系统这两个值都有一个相对极限值，在应用场景访问压力下，只要某一项达到系统最高值，系统的吞吐量就上不去了，如果压力继续增大，系统的吞吐量反而会下降，原因是系统超负荷工作，上下文切换、内存等等其它消耗导致系统性能下降。
三、测试工具
3.1 testtool
Testtool是Mycat官方提供的一套测试工具。
四、测试环境
5.1 机器
4台物理机每台物理机运行两个虚拟机，为方便描述，mysql机器取名为test_mysql_xx，mycat机器取名为test_mycat_xx，xx为ip最后一段，以下是详细配置：
test_mysql_204
用途：mysql实例
CPU:服务器专用 Intel Xeon E5-2660（4核）
内存：8G
硬盘：100G
系统版本：CentOs6.6
IP：172.16.40.204
test_mysql_205
用途：mysql实例
CPU:服务器专用 Intel Xeon E5-2660（4核）
内存：8G
硬盘：100G
系统版本：CentOs6.6
IP：172.16.40.205
test_mysql_206
用途：mysql实例
CPU:服务器专用 Intel Xeon E5-2660（4核）
内存：8G
硬盘：100G
系统版本：CentOs6.6
IP：172.16.40.206
test_mysql_207
用途：mysql实例
CPU:服务器专用 Intel Xeon E5-2660（4核）
内存：8G
硬盘：100G
系统版本：CentOs6.6
IP：172.16.40.207
test_mysql_208
用途：mysql实例
CPU:服务器专用 Intel Xeon E5-2660（4核）
内存：8G
硬盘：100G
系统版本：CentOs6.6
IP：172.16.40.208
test_mysql_209
用途：mysql实例
CPU:服务器专用 Intel Xeon E5-2660（4核）
内存：8G
硬盘：100G
系统版本：CentOs6.6
IP：172.16.40.209
test_mycat_210
用途：mycat实例
CPU:服务器专用 Intel Xeon E5-2660（4核）
内存：8G
硬盘：100G
系统版本：CentOs6.6
IP：172.16.40.210
test_mycatweb_211
用途：mycat-web实例、性能测试
CPU:服务器专用 Intel Xeon E5-2660（4核）
内存：8G
硬盘：100G
系统版本：CentOs6.6
IP：172.16.40.211
5.2 软件版本
JDK：1.7
Mycat：1.5.1
Mysql：5.7.11
5.3 测试表结构
为了扩大报告适用范围，设定表为多字段大表，且不做任何优化，即不加索引、不建立主键等手段优化表结构，用以测试最低限数据。
CREATE TABLE `T_TEST_SINGLE_TABLE` ( `FACTID` int(10) NOT NULL COMMENT '终端厂商ID，主键，自动更新', `CNNAME` varchar(128) DEFAULT NULL COMMENT 'OEM厂商中文名称', `ENNAME` varchar(128) DEFAULT NULL COMMENT 'OEM厂商英文名称', `ABBRNAME` varchar(64) DEFAULT NULL COMMENT 'OEM名称缩写', `ACCOUNT` varchar(128) DEFAULT NULL COMMENT 'OEM管理账号', `FACTDESC` varchar(255) DEFAULT NULL COMMENT 'OEM厂商介绍', `CONTACT` varchar(60) DEFAULT NULL COMMENT '联系人', `ADDRESS` varchar(160) DEFAULT NULL, `TELEPHONE` varchar(80) DEFAULT NULL, `EMAIL` varchar(160) DEFAULT NULL COMMENT '联系邮件', `SALENUM` int(10) unsigned DEFAULT NULL COMMENT '激活的数量', `TOTALVISIT` int(10) unsigned DEFAULT NULL COMMENT '累计访问数量', `MALIVERATIO` int(10) unsigned DEFAULT NULL COMMENT '平均???活跃率', `DALIVERATIO` int(11) unsigned DEFAULT NULL COMMENT '平均日活跃率', `ALIVENUM` int(11) unsigned DEFAULT NULL COMMENT '最近1个月活跃量' ) ENGINE=InnoDB DEFAULT CHARSET=utf8; |
|---|
五、测试方案
每个数据库实例，建立5个片（库）。因为经多次实验，单库单表情况下插入数据性能随并发数呈凸型，最佳范围在300到400之间，故而方案一及其他方案对比并发设为100、300。另外，1亿数据并不会一次性插入，而是分5次，每次2000万，以便记录不同数据量下的数据插入性能。
4.1 方案一
本方案为标准对比方案，是其他所有方案测试指标的对比参照方案，但需要注意的是其他方案并不是完全基于本方案的测试，本方案测试的所有结果只当作参照数据。
单独数据库实例上的单独库，并且单表。所有读写压力直接施加到表上，但为了追求极限数据准确性，读写互斥，同一时刻只能是读或者是写。
本方案单表数据高达1亿，无法进行如建立索引等手段，进而无法获得优化后的参考数据。
并发数：100、300
数据量：100000000
数据库：TESTDB
数据表：t_test_single_table
引用机器：test_mysql_204
拓扑图：
测试命令：
插入： ./test_stand_insert_perf.sh jdbc:mysql://172.16.40.210:8066/TESTDB test test 100 file=mydata-create.sql ./test_stand_insert_perf.sh jdbc:mysql://172.16.40.210:8066/TESTDB test test 300 file=mydata-create.sql 查询： ./test_stand_select_perf.sh jdbc:mysql://172.16.40.210:8066/TESTDB test test 10 100 file=mysql-select.sql |
|---|
4.2 方案二
本方案中，为了节约资源，将方案一用到的机器作废，重新规划定位。test_mysql_204为主库，test_mysql_205为从库，做数据同步。同时主从库都会包含7个database，用作mycat的分片。
本方案单表数据高达2000万，无法进行如建立索引等手段，进而无法获得优化后的参考数据。
并发数：100、300
数据量：100000000
数据库：TESTDB
数据表：t_test_single_table
引用机器：test_mysql_204、test_mysql_205、test_mycat_210
拓扑图：
测试命令：
插入： ./test_stand_insert_perf.sh jdbc:mysql://172.16.40.210:8066/TESTDB test test 100 file=mydata-create.sql ./test_stand_insert_perf.sh jdbc:mysql://172.16.40.210:8066/TESTDB test test 300 file=mydata-create.sql 查询： ./test_stand_select_perf.sh jdbc:mysql://172.16.40.210:8066/TESTDB test test 10 100000 file=mysql-select.sql |
|---|
4.3 方案三
本方案中，test_mysql_204、test_mysql_206、test_mysql_208为主库，test_mysql_205、test_mysql_207、test_mysql_209为从库，做数据同步。同时主从库都会包含7个database，用作mycat的分片,共计21个分片。
并发数：100、300
数据量：100000000
数据库：TESTDB
数据表：t_test_single_table
引用机器：test_mysql_204、test_mysql_205、test_mysql_206、test_mysql_207、test_mysql_208、test_mysql_209、test_mycat_210
拓扑图：
测试命令：
插入： ./test_stand_insert_perf.sh jdbc:mysql://172.16.40.210:8066/TESTDB test test 100 file=mydata-create.sql ./test_stand_insert_perf.sh jdbc:mysql://172.16.40.210:8066/TESTDB test test 300 file=mydata-create.sql 查询： ./test_stand_select_perf.sh jdbc:mysql://172.16.40.210:8066/TESTDB test test 10 100000 file=mysql-select.sql |
|---|
六、测试结果
6.1 方案一结果
插入数据：
并发数 | 记录数 | QPS(TPS) |
|---|---|---|
100 | 20000000 | 20343.8103956871 |
40000000 | 20531.7729185915 | |
60000000 | 19415.5907193476 | |
80000000 | 19529.3428376135 | |
100000000 | 17951.709900368 | |
平均QPS（TPS） | 19554.44535 | |
300 | 20000000 | 20343.8103956871 |
40000000 | 20831.163420477 | |
60000000 | 19819.6412644931 | |
80000000 | 19529.3428376135 | |
100000000 | 19510.2916788606 | |
平均QPS（TPS） | 20006.84992 |
查询数据:
记录数 | 查询次数 | 平均查询时间（ms） | QPS(TPS) |
|---|---|---|---|
100000000 | 1000 | >1h | ≈0 |
图表对比：
1、插入数据：本方案不同并发数对比图
小结：
数据从0到2000万区间，QPS(TPS)均呈线性增长，2000万后，均开始下降，但300连接相对100连接下降趋势较缓，并且在8000万数据时，QPS(TPS)重叠，但继续增加数据100连接开始急剧下降，而300连接则基本保持不变。由此可见不同连接数QPS(TPS)并不是完全相同的，相对来说最佳连接数区间能够获得相对稳定的QPS(TPS)值。
6.2 方案二结果
插入数据：
并发数 | 记录数 | QPS(TPS) |
|---|---|---|
100 | 20000000 | 7862.800303 |
40000000 | 7701.560761 | |
60000000 | 7448.411937 | |
80000000 | 7388.409909 | |
100000000 | 7097.183579 | |
平均QPS（TPS） | 7499.673298 | |
300 | 20000000 | 8565.892935 |
40000000 | 8230.113987 | |
60000000 | 7936.193008 | |
80000000 | 7504.40884 | |
100000000 | 7288.364127 | |
平均QPS（TPS） | 7904.994579 |
查询数据:
记录数 | 查询次数 | 平均查询时间（ms） | QPS(TPS) |
|---|---|---|---|
100000000 | 1000 | >1h | ≈0 |
图表对比：
1、插入数据：本方案不同并发数对比图
2、插入数据：对比方案一100并发数对比图
3、插入数据：对比方案一300并发数对比图
4、插入数据：对比方案一不同并发数对比图
5、查询数据：对比方案一对比图
小结：
由于将单库单表独占整个数据库的资源平分5份，再加上mycat路由，在数据插入性能上对比方案一，本方案中无论100并发还是300并发所获得的性能都相对较低。但从整体趋势上（数据量从0到1亿）对比，无论方案一还是方案二都相对平缓，不过从mycat原理上可以推测方案二的趋势稳定性要强于方案一，同时在本方案中不同并发数相比也没有太大差别。最后在查询性能上，由于表并没有设置索引，获得的查询性能同方案一并无差别，QPS（TPS）都约为0。
由此可见，Mycat只配置1台写库一台读库的情况下，因为资源被平分，并不能发挥出Mycat的能力，这种架构只能用于开发和测试。
6.3 方案三结果
插入数据：
并发数 | 记录数 | QPS(TPS) |
|---|---|---|
100 | 20000000 | 12375.47181 |
40000000 | 12483.61525 | |
60000000 | 12398.48738 | |
80000000 | 12514.8614 | |
100000000 | 12421.58872 | |
平均QPS（TPS） | 12438.80491 | |
300 | 20000000 | 13260.73179 |
40000000 | 13357.20955 | |
60000000 | 13188.81686 | |
80000000 | 13234.60962 | |
100000000 | 13210.78072 | |
平均QPS（TPS） | 13250.42971 |
查询数据:
记录数 | 查询次数 | 平均查询时间（ms） | QPS(TPS) | 是否添加索引 |
|---|---|---|---|---|
100000000 | 1000 | 6840.26 | 1.46 | 否 |
100000000 | 1000 | 3.27 | 3027.02 | 是 |
图表对比：
1、本方案不同并发数对比图
2、对比方案一100并发数对比图
3、对比方案一300并发数对比图
4、对比方案二100并发数对比图
5、对比方案二300并发数对比图
6、对比方案一、二不同并发数对比图
7、查询数据：对比方案二对比图
8、查询数据：对比方案一、二对比图
小结：
对比方案一，插入性能依然因为资源平分问题不如方案一，但差距不是很大。而在查询性能则表现突出，未优化前的数据大表查询平均响应在6秒，而加了索引之后，平均响应为3.27毫秒，QPS(TPS)高达3027.02，查询性能远远超过方案一。
对比方案二，插入性能大大提升，也证明了测试目标3，即Mycat性能随Mysql实例数呈线性增长。而在查询上，同方案一一样，本方案查询性能远远超过方案二。
6.4 综合结论
在报告中。
方案一用来测试出参照数据，为其他方案提供一个数据参考。
方案二用来测试最小化mycat集群下的性能，即对比方案一，又对比其他方案，起到一个承上启下的作用，同时也能在方案二中可以看到mycat性能的一角。
方案三是最核心的测试，测试生产环境下最小mycat集群的性能，通过对比方案一方案二，来验证方案三所属架构是否能够承受足够量的压力和持续运行的稳定力。
通过本报告可以总结出如下观点：
1、分片后性能有提升；
2、方案三架构下，1亿数据量下的常规操作，快速有效。
3、Mycat性能随Mysql实例数呈线性增长
4、单mysql实例上的插入性能会被平分（分片情况下），分片越多，每个片获得的资源越少，减少片数增加mysql实例数可以快速提升性能。
5、mycat性能随并发数呈凸型增长，合理控制并发数、mycat负载均衡等能够使mycat发挥出最大性能。
6、分片情况下，单表数据越少插入和查询性能越大，推荐单表数据量不加索引500万左右，加索引1000万左右，单mysql实例5个片（库），然后根据预算总数据量计算需要mysql实例数。
7、合理使用mycat配置，缩短查询范围（如E-R表），能够提升mycat性能（本报告暂未验证，但从原理上推测是正确的）。