目录

使用YCSB测试MySQLHbase性能并比较

目录

使用YCSB测试MySQL、Hbase性能并比较

YCSB在测试的时候 有固定的表结构,所以以下插入、删除都是在同等条件下测试的。

Hbase结果

1)、使用load进行插入数据。

1线程插入条数总吞吐量总运行时间(ms)
1000356.2522265764162807
100001000.700490343249993
1000001123.2042771618889031
5000001728.08272677629289338
10线程插入条数总吞吐量总运行时间
1000762.1951219512191312
100004887.585532746822046
10000012517.21116535237989
50000015201.264745226832892

表1-1

2)、使用run进行操作

单线程插入条数总吞吐量总运行时间Read延时(us)Update延时Clear up延时
1000329.5978930342085.73131930.17115412291.5
10000939.8496210640819.665131025.08438118243.5
500001158.829143147789.16653866.450251219078.5
1000001250.328279979781.42424772.214618421538.5
5000001264.5806395388810.28747749.601476726078
10线程插入条数总吞吐量总运行时间Read延时Update延时Clear up延时
1000848.896411782964.2042757.5661260.1
100005221.9321915901.50610091515.55
5000011970.314177710.2837571.31061966.1
10000014019.357133702.7973531.84492299.1
50000016725.7629894668.9032478.01582569.95

3)、在有一定的基础数据插入1000条随机数据所用的时间。

基础数据/ 时间插入时间(ms )
011307
100010785
500000010225
1000000010877
15000000—–
15300000—–
2000000010440

MySQL结果

(1)、使用load进行插入数据 2-1

单线程插入条数总吞吐量总运行时间
1000410.846343467543142434
10000566.47595309579117653
100000274.2656537121856364610
500000257.39190955454211942563
10线程插入条数总吞吐量总运行时间
1000735.83517292126571359
100001839.587932303165436
1000001177.5650310288384921
500000902.255096387912554167

(2)、使用run进行操作2-2

单线程插入条数总吞吐量总运行时间Read延时Update延时Clear up延时
10002651.2865493.82712025330.16911051
100002077.8056843.739411852180.35421192
500002317.8701803.548462224144.52411138
1000002251.9195832.8544120069136.11301188
5000001944.3911954.7742523684140.75861172
10线程插入条数总吞吐量总运行时间Read延时Update延时Clear up延时
10005707.80611011.1229892948.0443701.3
100006214.51992043.31848941462.4621058.4
500005582.94673001.38016659715.7262402.8
1000005322.65453367.45629696470.1969397.5
5000005085.93023618.494138179397.6028725.9

(3)在有一定的基础数据插入一千条随机数据所用的时间。

通过使用jdbc方法添加数得出结果。

基础数据/ 时间插入时间(ms )
02303
10002309
50000002100
100000003592
1500000015467
1530000021051
20000000—–

l 总结

将上面的数据进行比较,表结构如下。上面的数据测试事务用的是workloada,这意味着,事务 混合了50% 的读和50%的写。

(1)单线程在数据库中没有数据的情况下,向hbase与mysql加载数据所用时间的比较。

https://i-blog.csdnimg.cn/blog_migrate/0f40e011efbd33f1e4c35e5cf9172ff1.png

结论:

单线程,在插入较少数据的时候mysql所用时间比hbase所用时间少,但是当插入数据较多时mysql所用时间比hbase所用时间长很多。

(2)单线程在数据库中没有数据的情况下,向hbase与mysql加载数据,总吞吐量的比较。

https://i-blog.csdnimg.cn/blog_migrate/e8ffaeb84a7dd85f503dd5ffeb685698.png

结论:

单线程的时候,插入较少数据的时候mysql的总吞吐量要大于hbase的总吞吐量,但当插入较多数据的时候mysql的总吞吐量要小于hbase的总吞吐量。

(3)10线程在数据库中没有数据的情况下,向hbase与mysql加载数据所用时间的比较。

https://i-blog.csdnimg.cn/blog_migrate/bb0e0f1baec52b9c84244b80f5f0fb4a.png

结论:

10个线程,在插入较少数据的时候mysql所用时间比hbase所用时间少,但是当插入较多粒度时mysql所用时间比hbase所用时间长很多。

(4)10线程在数据库中没有数据的情况下,向hbase与mysql加载数据,总吞吐量的比较

https://i-blog.csdnimg.cn/blog_migrate/04d9cd023c8e6c228c5648cb19b14a8b.png

结论:

10个线程的时候,插入较少数据的时候mysql的总吞吐量要大于hbase的总吞吐量,但当插入较多数据的时候mysql的总吞吐量要小于hbase的总吞吐量。

(5)单线程hbase与mysql使用run操作时,所用的总时间比较

https://i-blog.csdnimg.cn/blog_migrate/866ee43c4f623891f7644a83f3e958df.png

结论:

单线程时,进行事务操作较少数据的时候,mysql所用的总时间要小于hbase所用的总时间。但当操作较多数据的时候mysql所用的总时间就要大于hbase所用的总时间,并且差距不断地在增大。

(6) 单线程hbase与mysql使用run操作时,总吞吐比较

https://i-blog.csdnimg.cn/blog_migrate/0fecd546af2dfee33f5b5064d92700da.png

结论:

单线程时,执行事务,操作较少数据的时候,mysql的总吞吐量要大于hbase的总吞吐量,但当操作较多数据的时候,mysql的总吞吐量就小于hbase的总吞吐量。

(7)单线程hbase与mysql使用run操作,read延迟比较

https://i-blog.csdnimg.cn/blog_migrate/fe7893794b7c5b8bef90db25b1012508.png

结论:

单线程时,执行事务,hbase的read延迟始终大于mysql的read延迟。

随着数据的不断增大hbase、mysql在read延迟区域一个稳定幅度。

(8)单线程hbase与mysql使用run进行操作update延迟比较

https://i-blog.csdnimg.cn/blog_migrate/fe0037a3eced4a6861ef11f6bc5eaf16.png

结论:

单线程,执行事务,mysql的update延迟始终大于hbase的update的延迟。

(9)单线程hbase与mysql使用run操作,clearup延迟比较

https://i-blog.csdnimg.cn/blog_migrate/c5aebeadcfe4e83c956b24b1cd19d5ac.png

结论:

单线程时,执行事务hbase的clear up延迟始终大于mysql的clear up延迟。

(10)10线程hbase与mysql使用run操作,所用总时间比较

https://i-blog.csdnimg.cn/blog_migrate/316ad94492b8868b62c9be35eb5f65d2.png

结论:

10线程时,使用run进行操作较少粒度的时候,mysql所用的总时间要小于hbase所用的总时间。但当操作较多粒度的时候mysql所用的总时间就要大于hbase所用的总时间。

(11)10线程hbase与mysql使用run操作,总吞吐量比较

https://i-blog.csdnimg.cn/blog_migrate/f439ed59652ce0fb1373d84e51f2b10f.png

结论:

单线程时,执行事务,操作较少数据的时候,mysql的总吞吐量要大于hbase的总吞吐量,但当随着操作的数据不断增多的时候,mysql的总吞吐量就小于hbase的总吞吐量。

(12)10线程hbase与mysql使用run操作,read延迟比较

https://i-blog.csdnimg.cn/blog_migrate/d811054d680ed580534b6f28f2408fd0.png

结论:

10线程时,执行事务,当操作的数据比较少得时候mysql的read延迟要大于hbase的read延迟,但随着数据增多的时候,mysql的read延迟要小于hbase的read延迟。

(13)10线程hbase与mysql使用run操作,update延迟比较

https://i-blog.csdnimg.cn/blog_migrate/880dbab2fa6eebdb814c99bb1fdc1adf.png

结论:

10线程的时候,在进行run操作的时候,mysql的update延迟要大于hbase延迟。

(14)10线程hbase与mysql使用run操作,clear up延迟比较

https://i-blog.csdnimg.cn/blog_migrate/40c84eab676498ef1bc251b774e54361.png

结论:

10现成的时候,进行run操作的时候,当插入较少数据的时候mysql的clear up延迟要大于hbase的clear up延迟,当随着插入较多数据的时候mysql的clear up延迟要小于hbase延迟。

(15)Hbase与mysql在具有一定基础数据的情况下插入1000条数据所用时间比较

https://i-blog.csdnimg.cn/blog_migrate/9961f7fd8051aa3cb0626fc0f7c1761a.png

结论:

很明显,随着数据库数据的增多,hbase插入1000条数据所用的时间比较稳定,但是MySQL当时数据不断增多时,所用的时间大幅度提升,还有在数据库数据较小(一千三百万以下),MySQL所用时间明显小于hbase时间。由于我插了多半天的数据再插到1530万条,插入的速度慢了不少