Hbase结果
1）、使用load进行插入数据。
1线程插入条数 |
总吞吐量 |
总运行时间（ms） |
1000 |
356.252226576416 |
2807 |
10000 |
1000.70049034324 |
9993
扫描二维码关注公众号，回复：
3396888 查看本文章
|
100000 |
1123.20427716188 |
89031 |
500000 |
1728.08272677629 |
289338 |
10线程插入条数 |
总吞吐量 |
总运行时间 |
1000 |
762.195121951219 |
1312 |
10000 |
4887.58553274682 |
2046 |
100000 |
12517.2111653523 |
7989 |
500000 |
15201.2647452268 |
32892 |
表1-1
2）、使用run进行操作
单线程插入条数 |
总吞吐量 |
总运行时间 |
Read延时(us) |
Update延时 |
Clear up延时 |
1000 |
329.59789 |
3034 |
2085.7313 |
1930.171154 |
12291.5 |
10000 |
939.84962 |
10640 |
819.66513 |
1025.084381 |
18243.5 |
50000 |
1158.8291 |
43147 |
789.16653 |
866.4502512 |
19078.5 |
100000 |
1250.3282 |
79979 |
781.42424 |
772.2146184 |
21538.5 |
500000 |
1264.5806 |
395388 |
810.28747 |
749.6014767 |
26078 |
10线程插入条数 |
总吞吐量 |
总运行时间 |
Read延时 |
Update延时 |
Clear up延时 |
1000 |
848.8964 |
1178 |
2964.204 |
2757.566 |
1260.1 |
10000 |
5221.932 |
1915 |
901.506 |
1009 |
1515.55 |
50000 |
11970.31 |
4177 |
710.2837 |
571.3106 |
1966.1 |
100000 |
14019.35 |
7133 |
702.7973 |
531.8449 |
2299.1 |
500000 |
16725.76 |
29894 |
668.9032 |
478.0158 |
2569.95 |
3)、在有一定的基础数据插入1000条随机数据所用的时间。
基础数据/时间 |
插入时间（ms） |
0 |
11307 |
1000 |
10785 |
5000000 |
10225 |
10000000 |
10877 |
15000000 |
----- |
15300000 |
----- |
20000000 |
10440 |
MySQL结果
（1）、使用load进行插入数据 2-1
单线程插入条数 |
总吞吐量 |
总运行时间 |
1000 |
410.84634346754314 |
2434 |
10000 |
566.475953095791 |
17653 |
100000 |
274.2656537121856 |
364610 |
500000 |
257.3919095545421 |
1942563 |
10线程插入条数 |
总吞吐量 |
总运行时间 |
1000 |
735.8351729212657 |
1359 |
10000 |
1839.58793230316 |
5436 |
100000 |
1177.56503102883 |
84921 |
500000 |
902.255096387912 |
554167 |
（2）、使用run进行操作2-2
单线程插入条数 |
总吞吐量 |
总运行时间 |
Read延时 |
Update延时 |
Clear up延时 |
1000 |
2651.2865 |
493.8271 |
2025 |
330.1691 |
1051 |
10000 |
2077.8056 |
843.7394 |
11852 |
180.3542 |
1192 |
50000 |
2317.8701 |
803.5484 |
62224 |
144.5241 |
1138 |
100000 |
2251.9195 |
832.8544 |
120069 |
136.1130 |
1188 |
500000 |
1944.3911 |
954.7742 |
523684 |
140.7586 |
1172 |
10线程插入条数 |
总吞吐量 |
总运行时间 |
Read延时 |
Update延时 |
Clear up延时 |
1000 |
5707.8061 |
1011.122 |
989 |
2948.044 |
3701.3 |
10000 |
6214.5199 |
2043.318 |
4894 |
1462.462 |
1058.4 |
50000 |
5582.9467 |
3001.380 |
16659 |
715.7262 |
402.8 |
100000 |
5322.6545 |
3367.456 |
29696 |
470.1969 |
397.5 |
500000 |
5085.9302 |
3618.494 |
138179 |
397.6028 |
725.9 |
(3)在有一定的基础数据插入一千条随机数据所用的时间。
通过使用jdbc方法添加数得出结果。
基础数据/时间 |
插入时间（ms） |
0 |
2303 |
1000 |
2309 |
5000000 |
2100 |
10000000 |
3592 |
15000000 |
15467 |
15300000 |
21051 |
20000000 |
----- |
l 总结
将上面的数据进行比较，表结构如下。上面的数据测试事务用的是workloada，这意味着，事务混合了50%的读和50%的写。
（1）单线程在数据库中没有数据的情况下，向hbase与mysql加载数据所用时间的比较。
结论：
单线程，在插入较少数据的时候mysql所用时间比hbase所用时间少，但是当插入数据较多时mysql所用时间比hbase所用时间长很多。
（2）单线程在数据库中没有数据的情况下，向hbase与mysql加载数据，总吞吐量的比较。
结论：
单线程的时候，插入较少数据的时候mysql的总吞吐量要大于hbase的总吞吐量，但当插入较多数据的时候mysql的总吞吐量要小于hbase的总吞吐量。
（3）10线程在数据库中没有数据的情况下，向hbase与mysql加载数据所用时间的比较。
结论：
10个线程，在插入较少数据的时候mysql所用时间比hbase所用时间少，但是当插入较多粒度时mysql所用时间比hbase所用时间长很多。
（4）10线程在数据库中没有数据的情况下，向hbase与mysql加载数据，总吞吐量的比较
结论：
10个线程的时候，插入较少数据的时候mysql的总吞吐量要大于hbase的总吞吐量，但当插入较多数据的时候mysql的总吞吐量要小于hbase的总吞吐量。
（5）单线程hbase与mysql使用run操作时，所用的总时间比较
结论：
单线程时，进行事务操作较少数据的时候，mysql所用的总时间要小于hbase所用的总时间。但当操作较多数据的时候mysql所用的总时间就要大于hbase所用的总时间，并且差距不断地在增大。
（6） 单线程hbase与mysql使用run操作时，总吞吐比较
结论：
单线程时，执行事务，操作较少数据的时候，mysql的总吞吐量要大于hbase的总吞吐量，但当操作较多数据的时候，mysql的总吞吐量就小于hbase的总吞吐量。
（7）单线程hbase与mysql使用run操作，read延迟比较
结论：
单线程时，执行事务，hbase的read延迟始终大于mysql的read延迟。
随着数据的不断增大hbase、mysql在read延迟区域一个稳定幅度。
（8）单线程hbase与mysql使用run进行操作update延迟比较
结论：
单线程，执行事务，mysql的update延迟始终大于hbase的update的延迟。
（9）单线程hbase与mysql使用run操作，clearup延迟比较
结论：
单线程时，执行事务hbase的clear up延迟始终大于mysql的clear up延迟。
（10）10线程hbase与mysql使用run操作，所用总时间比较
结论：
10线程时，使用run进行操作较少粒度的时候，mysql所用的总时间要小于hbase所用的总时间。但当操作较多粒度的时候mysql所用的总时间就要大于hbase所用的总时间。
（11）10线程hbase与mysql使用run操作，总吞吐量比较
结论：
单线程时，执行事务，操作较少数据的时候，mysql的总吞吐量要大于hbase的总吞吐量，但当随着操作的数据不断增多的时候，mysql的总吞吐量就小于hbase的总吞吐量。
（12）10线程hbase与mysql使用run操作，read延迟比较
结论：
10线程时，执行事务，当操作的数据比较少得时候mysql的read延迟要大于hbase的read延迟，但随着数据增多的时候，mysql的read延迟要小于hbase的read延迟。
（13）10线程hbase与mysql使用run操作，update延迟比较
结论：
10线程的时候，在进行run操作的时候，mysql的update延迟要大于hbase延迟。
（14）10线程hbase与mysql使用run操作，clear up延迟比较
结论：
10现成的时候，进行run操作的时候，当插入较少数据的时候mysql的clear up延迟要大于hbase的clear up延迟，当随着插入较多数据的时候mysql的clear up延迟要小于hbase延迟。
（15）Hbase与mysql在具有一定基础数据的情况下插入1000条数据所用时间比较
结论：
很明显，随着数据库数据的增多，hbase插入1000条数据所用的时间比较稳定，但是MySQL当时数据不断增多时，所用的时间大幅度提升，还有在数据库数据较小（一千三百万以下），MySQL所用时间明显小于hbase时间。由于我插了多半天的数据再插到1530万条，插入的速度慢了不少