YCSB在测试的时候 有固定的表结构，所以以下插入、删除都是在同等条件下测试的。
Hbase结果
1）、使用load进行插入数据。
1线程插入条数 | 总吞吐量 | 总运行时间（ms） |
1000 | 356.252226576416 | 2807 |
10000 | 1000.70049034324 | 9993 |
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万条，插入的速度慢了不少
