之前测试过HBASE的参数对性能影响，今天的测试主要针对写吞吐量，通过对比不同客户端的数量，以及插入量，来看看HBASE写的情况下，大概有多少每秒插入。
测试硬件：8vcore, 32G内存 ， 8台机器， 5个nodemanager/region server ，大家可能知道每个map,reduce 默认1个 vcores，1G内存 很显然，我一共40个vcores， 所以最多也只有39个map, reduce。
测试命令：
time hbase org.apache.hadoop.hbase.PerformanceEvaluation --rows=1000000 sequentialWrite 50
| 客户端 | 数据量 | 执行时间 | 写吞吐量 |
| 1 | 1000000 | 54s | 18000条/s |
| 1 | 10000000 | 2m56s | 58800条/s |
| 1 | 100000000 | 3m20s | 78000条/s |
| | | |
| 10 | 100000/client | 1m24.625s | 11904条/s |
| 10 | 1000000/client | 4m2.163s | 41000条/s |
| 10 | 10000000/client | 14m33.584s | 113000条/s |
| | | |
| | | |
| 50 | 10000/client | 3m29.969s | 3292条/s |
| 50 | 100000/client | 3m9.325s | 26315条/s |
| 50 | 1000000/client | 13m50.013s | 60240条/s |
先说明一下，上面测试数据其实是不准确的，主要硬件限制，PerformanceEvaluation 默认每个客户端为10个MAP，50个并发的话就是500个MAP，每次只能跑39个MAP，很显然很多MAP处于pending状态，如果有足够好的硬件，结果会好很多。另外，PerformanceEvaluation 是先随机生成数据，再通过reduce来插入，所以整个时间还包含map的时候，并不单纯是插入时间。
所以从上述结果来看，看不出来太多问题，但是也有惊喜，10个客户端的情况下达到11W条/秒， 如果有足够好的CPU，我相信即使并发增加，HBASE的写性能还是非常不错的。
来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/17036462/viewspace-2141484/，如需转载，请注明出处，否则将追究法律责任。
来自 “ ITPUB博客 ” ，链接：https://blog.itpub.net/31537575/viewspace-3123945/
，如需转载，请注明出处，否则将追究法律责任。
