Mycat基准测试报告
很久没上OSC，上面安排测下Mycat，因而申请服务器，花了两个周作出这个东西，供以借鉴。mysql
1、测试目标
MyCAT 是一个完全开源的，面向企业应用开发的“大数据库集群” 支持事务、ACID、能够替代Mysql的增强版数据库 。一个能够视为“Mysql”集群的企业级数据库，用来替代昂贵的Oracle集群 。 一个融合内存缓存技术、Nosql技术、HDFS大数据的新型SQL Server ? 结合传统数据库和新型分布式数据仓库的新一代企业级数据库产品 。 一个新颖的数据库中间件产品。web
目标sql
低成本的将现有的单机数据库和应用平滑迁移到“云”端，解决数据存储和业务规模迅速增加状况下的数据瓶颈问题。数据库
关键特性缓存
支持 SQL 92标准 支持Mysql集群，能够做为Proxy使用 支持JDBC链接ORACLE、DB二、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亿数据量下的常规操做，是否快速有效。
三、测试Mycat性能是否随Mysql实例数呈线性增加
预测结果
一、相对于单台，分布式mycat数据库集群响应时间应该大于单台单库的响应能力，但随着数据增加，数据库集群响应时间基本不变，然后者则会发生极大的变化，应该成凸型增加。
二、单台单库状况下，查询性能应该随数据量呈负增加。
三、Mycat管理下的mysql实例越多，性能提高越大。
2、测试指标
2.1 并发数
指同时访问服务器站点的连接数。
2.2 响应时间
一次请求到请求完成消耗的时间，本文指的通常是平均响应时间。
2.3 QPS（TPS）
一个系统吞吐量一般由QPS（TPS）、并发数两个因素决定，每套系统这两个值都有一个相对极限值，在应用场景访问压力下，只要某一项达到系统最高值，系统的吞吐量就上不去了，若是压力继续增大，系统的吞吐量反而会降低，缘由是系统超负荷工做，上下文切换、内存等等其它消耗致使系统性能降低。
3、测试工具
3.1 testtool
Testtool是Mycat官方提供的一套测试工具。
4、测试环境
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、测试方案
每一个数据库实例，创建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_20四、test_mysql_20五、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_20四、test_mysql_20六、test_mysql_208为主库，test_mysql_20五、test_mysql_20七、test_mysql_209为从库，作数据同步。同时主从库都会包含7个database，用做mycat的分片,共计21个分片。
并发数：100、300
数据量：100000000
数据库：TESTDB
数据表：t_test_single_table
引用机器：test_mysql_20四、test_mysql_20五、test_mysql_20六、test_mysql_20七、test_mysql_20八、test_mysql_20九、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、测试结果
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 |
图表对比：
一、插入数据：本方案不一样并发数对比图
小结：
数据从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 |
图表对比：
一、插入数据：本方案不一样并发数对比图
二、插入数据：对比方案一100并发数对比图
三、插入数据：对比方案一300并发数对比图
四、插入数据：对比方案一不一样并发数对比图
五、查询数据：对比方案一对比图
小结：
因为将单库单表独占整个数据库的资源平分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 |
是 |
图表对比：
一、本方案不一样并发数对比图
二、对比方案一100并发数对比图
三、对比方案一300并发数对比图
四、对比方案二100并发数对比图
五、对比方案二300并发数对比图
六、对比方案1、二不一样并发数对比图
七、查询数据：对比方案二对比图
八、查询数据：对比方案1、二对比图
小结：
对比方案一，插入性能依然由于资源平分问题不如方案一，但差距不是很大。而在查询性能则表现突出，未优化前的数据大表查询平均响应在6秒，而加了索引以后，平均响应为3.27毫秒，QPS(TPS)高达3027.02，查询性能远远超过方案一。
对比方案二，插入性能大大提高，也证实了测试目标3，即Mycat性能随Mysql实例数呈线性增加。而在查询上，同方案一同样，本方案查询性能远远超过方案二。
6.4 综合结论
在报告中。
方案一用来测试出参照数据，为其余方案提供一个数据参考。
方案二用来测试最小化mycat集群下的性能，即对比方案一，又对比其余方案，起到一个承上启下的做用，同时也能在方案二中能够看到mycat性能的一角。
方案三是最核心的测试，测试生产环境下最小mycat集群的性能，经过对比方案一方案二，来验证方案三所属架构是否可以承受足够量的压力和持续运行的稳定力。
经过本报告能够总结出以下观点：
一、分片后性能有提高；
二、方案三架构下，1亿数据量下的常规操做，快速有效。
三、Mycat性能随Mysql实例数呈线性增加
四、单mysql实例上的插入性能会被平分（分片状况下），分片越多，每一个片得到的资源越少，减小片数增长mysql实例数能够快速提高性能。
五、mycat性能随并发数呈凸型增加，合理控制并发数、mycat负载均衡等可以使mycat发挥出最大性能。
六、分片状况下，单表数据越少插入和查询性能越大，推荐单表数据量不加索引500万左右，加索引1000万左右，单mysql实例5个片（库），而后根据预算总数据量计算须要mysql实例数。
七、合理使用mycat配置，缩短查询范围（如E-R表），可以提高mycat性能（本报告暂未验证，但从原理上推测是正确的）。
- 1. 测试报告
- 2. 跨平台开源项目Ngui【基准性能测试报告】
- 3. flowable6.3功能以及性能基准测试报告
- 4. 测试的报告
- 5. 【Gamma】测试报告
- 6. 【Beta】测试报告
- 7. 802.1X 测试报告
- 8. impala测试报告
- 9. BLUEZ测试报告
- 10. MemcachedClient4J测试报告
- 更多相关文章...
- • Maven 构建 & 项目测试 - Maven教程
- • Lua 调试(Debug) - Lua 教程
- • Kotlin学习（二）基本类型
- • ☆基于Java Instrument的Agent实现
-
每一个你不满意的现在，都有一个你没有努力的曾经。
- 1. 测试报告
- 2. 跨平台开源项目Ngui【基准性能测试报告】
- 3. flowable6.3功能以及性能基准测试报告
- 4. 测试的报告
- 5. 【Gamma】测试报告
- 6. 【Beta】测试报告
- 7. 802.1X 测试报告
- 8. impala测试报告
- 9. BLUEZ测试报告
- 10. MemcachedClient4J测试报告