目录
1测试环境以及测试用例设计
1.1测试环境
1.2测试用例设计
2 千万级数据量性能测试对比
2.1 MemSQL时间范围分页查询
2.1.1 性能测试数据
2.2任务信息查询
2.2.1 性能测试数据
2.3 执行批次范围查询
2.3.1 性能测试数据
2.4 批次任务查询
2.4.1 性能测试数据
2.5 聚合查询
2.5.1 性能测试数据
2.5 系统资源监控数据
2.6总结
2.7 图表性能分析
2.7.1查询时间对比
2.7.2吞吐量对比
3 稳定性测试
3.1 docker重启以后
3.2 Linux系统重启
3.3 数据加载的过程中资源使用情况
1测试环境以及测试用例设计
1.1测试环境
Mysql 和MemSQL都是 4C/8G，测试接口都是通过Spring boot 微服务rest接口测试,MySQL 数据中和MemSQL的表都创建了相同的索引,其中create_time 都使用了降序索引(MYSQL8.0是倒排索引)。
1.1.1 Mysql 索引
1.1.1 MemSql 索引
1.2测试用例设计
1.2.1时间范围分页查询参数
/result/{page}/{size}/{startTime}/{endTime}
1.2.2根据任务信息查询参数：
/conditionOne/{page}/{size}/{powerDeviceId}/{taskId}
1.2.3执行批次范围查询参数：
/conditionTwo/{page}/{size}/{batchIdList}
1.2.4执行任务与批次范围查询参数：
/conditionThree/{page}/{size}/{batchIdList}/{taskIdList}
1.2.5聚合查询，采集计划前10个批次数据聚合：
/aggregate/{planId}
会使用group by 和 order by 以及limit。
2 千万级数据量性能测试对比
memsql数据总量：
MemSQL是兼容Mysql的，这里完全使用Mysql8.0的测试用例。
2.1 MemSQL时间范围分页查询
/mysql/result/20/20/2019-09-01/2019-09-30
2.1.1 性能测试数据
50 并发
100并发
200并发
2.2任务信息查询
/mysql/conditionOne/20/20/611607718939246592/611680047597752372
2.2.1 性能测试数据
50并发：
100并发：
200并发：
2.3 执行批次范围查询
/mysql/conditionTwo/10/20/1001,1002,1003,1004,1005,1027
2.3.1 性能测试数据
50并发：
100并发：
200并发：
2.4 批次任务查询
/mysql/conditionThree/1/20/1001,1002,1003,1004,1005,1027/611680047593558016,611680047593558017,611680047593558020,611680047593558021,611680047593558024,611680047593558025,611680047593558030,611680047593558031,611680047593558032,611680047593558033,611680047593558035,611680047593558036,611680047593558037,611680047593558038,611680047593558039,6116800475935580402.4.1 性能测试数据
50并发：
100并发：
2.5 聚合查询
/mysql/aggregate/620656410385203201
2.5.1 性能测试数据
50并发：
100并发：
200并发：
2.5 系统资源监控数据
CPU
16时40分01秒 CPU %user %nice %system %iowait %steal %idle
16时50分01秒 all 39.33 0.00 5.01 3.34 0.00 52.32
17时00分01秒 all 25.67 0.00 4.05 2.48 0.00 67.80
17时10分01秒 all 1.86 0.00 3.08 1.29 0.00 93.77
17时20分02秒 all 2.26 0.00 3.13 1.24 0.00 93.37
17时30分04秒 all 1.84 0.00 2.96 2.21 0.00 92.99
17时40分01秒 all 2.27 0.00 2.82 1.99 0.00 92.91
17时50分01秒 all 3.16 0.00 3.21 2.18 0.00 91.45
18时00分01秒 all 3.97 0.00 3.42 1.70 0.00 90.90
18时10分01秒 all 6.45 0.00 3.79 1.01 0.00 88.75
18时20分01秒 all 6.86 0.00 3.59 1.18 0.00 88.36
平均时间: all 9.39 0.00 3.51 1.87 0.00 85.23
内存
16时40分01秒 kbmemfree kbmemused %memused kbbuffers kbcached kbcommit %commit kbactive kbinact kbdirty
16时50分01秒 2966432 8139692 73.29 2220 2383552 10562668 95.11 5623236 2194500 4380
17时00分01秒 130308 10975816 98.83 2116 2297124 13458496 121.18 8575500 2063500 16
17时10分01秒 156916 10949208 98.59 2116 2271268 13458028 121.18 8576780 2036728 20
17时20分02秒 186092 10920032 98.32 2116 2241232 13457620 121.17 8580188 2005396 12
17时30分04秒 180072 10926052 98.38 2116 2243972 13464844 121.24 8584348 2006720 24
17时40分01秒 162888 10943236 98.53 2116 2249536 13507180 121.62 8594588 2010620 20
17时50分01秒 178864 10927260 98.39 2116 2109184 14011032 126.16 8699564 1867336 20
18时00分01秒 162828 10943296 98.53 2116 2026732 14282360 128.60 8787316 1785472 20
18时10分01秒 196672 10909452 98.23 2116 1836412 14732260 132.65 8931256 1592412 4
18时20分01秒 183244 10922880 98.35 2116 1752204 14792552 133.19 9032440 1506536 20
平均时间: 450432 10655692 95.94 2126 2141122 13572704 122.21 8398522 1906922 454
磁盘读写
16时40分01秒 tps rtps wtps bread/s bwrtn/s
16时50分01秒 44.07 5.52 38.55 1092.66 5602.73
17时00分01秒 26.58 0.08 26.50 2.55 3506.34
17时10分01秒 7.19 0.17 7.03 10.61 35.38
17时20分02秒 6.69 0.03 6.66 0.76 37.23
17时30分04秒 6.80 0.12 6.67 8.37 34.57
17时40分01秒 8.71 0.28 8.43 12.84 47.90
17时50分01秒 8.32 0.06 8.26 5.52 44.09
18时00分01秒 6.42 0.00 6.42 0.00 32.32
18时10分01秒 6.65 0.00 6.65 0.00 33.06
18时20分01秒 6.66 0.14 6.52 16.72 32.13
平均时间: 12.81 0.64 12.17 115.01 940.68
在性能测试的过程中，系统的CPU 和磁盘I/O 占用率都比较低，基本不读磁盘，是从内存中查询数据，所以相对效率比较高。但是内存的占用率太高了，1千万的数据（加上索引）需要差不多8G的内存。之前我设置为6G,导入数据的时候一直报错，后来设置为8G才没有问题。
2.6总结
依据上面的测试数据给出对比图，这里使用性能测试结果中的平均值的极大值。
相对于TiDB 和CockroachDB ，MemSQL的性能要好的多，但是在并发量增加的时候，读的效率突然降低很多，说明MemSQL也是无法很好的处理高并发读的场景。但是MemSQL 总是在使用内存来处理I/O，所以它的写的效率很高。下面是我测试过程中同步数据的截图，这里都没有使用mysqldump，只是使用navicat，大概 需要11分钟可以同步1千万（3G）的数据量。相对于其他的NewSQL数据库，可以说就像兔子一样，跑的飞快。
2.7 与Mysql8.0的图表分析
2.7.1查询时间对比
以50%为分割线,占比少的说明效率高。MemSQL 使用多次测试结果中平均响应时间的极大值，Mysql使用极小值。参考 :Mysql.8.0 与 MongoDB.4.2大数据量查询性能对比. 中 mysql50并发的测试数据。
2.7.2吞吐量对比
以50%为分割线,占比多的说明吞吐量高。MemSQL 使用多次测试结果中平均响应时间的极大值，Mysql使用极小值。参考 :Mysql.8.0 与 MongoDB.4.2大数据量查询性能对比. 中 mysql50并发的测试数据.
无论是读写的效率，还是并发吞吐量， MemSQL 明显优于Mysql。
3 稳定性测试
这里侧重MemSQL系统恢复时间测试.
3.1 docker重启以后
docker重启以后：leaf 节点的数据仍然在内存中，不需要重新加载。这也是使用Dockers的好处
3.2 Linux系统重启
但是Linux系统重启以后 ，MemSQL会重新加载数据(1个leaf节点，1千万条数据)到内存，这个过程很快,大概2分钟左右，前提是SDD 硬盘。
3.3 数据加载的过程中资源使用情况
内存利用率变化
09时51分54秒 LINUX RESTART10时00分01秒 kbmemfree kbmemused %memused kbbuffers kbcached kbcommit %commit kbactive kbinact kbdirty
10时10分01秒 9989164 1116960 10.06 2220 557788 2559000 23.04 391564 489032 16
10时20分01秒 144980 10961144 98.69 2116 2034660 13460280 121.20 8701212 1821912 12
10时30分01秒 135964 10970160 98.78 2116 2037908 13469084 121.28 8707784 1825012 28
平均时间: 3423369 7682755 69.18 2151 1543452 9829455 88.50 5933520 1378652 19
CPU变化
10时00分01秒 CPU %user %nice %system %iowait %steal %idle
10时10分01秒 all 0.13 0.00 0.15 0.04 0.00 99.68
10时20分01秒 all 10.78 0.02 2.97 1.09 0.00 85.14
10时30分01秒 all 2.11 0.00 3.53 0.36 0.00 94.01
平均时间: all 4.31 0.01 2.19 0.49 0.00 93.00
磁盘I/O读写变化
10时00分01秒 tps rtps wtps bread/s bwrtn/s
10时10分01秒 0.77 0.50 0.27 269.23 3.95
10时20分01秒 32.89 24.52 8.37 9744.26 93.79
10时30分01秒 6.73 0.09 6.64 9.95 36.12
平均时间: 13.46 8.37 5.09 3341.06 44.62
9：51分系统重启，然后在10时10分 和 10时20分之间 重启了memsql,。这期间系统的内存、CPU 和磁盘read 都上升很快，但是write很少。
