测试环境
测试环境包括测试过程中HBase集群的拓扑结构、以及需要用到的硬件和软件资源，硬件资源包括：测试机器配置、网络状态等等，软件资源包括操作系统、HBase相关软件以及测试工具等。
集群拓扑结构
本次测试中，测试环境总共包含3台物理机作为Hadoop数据存储，其中2台物理机作为RegionServer部署宿主机，每个宿主机上起2个RegionServer节点，整个集群一共4个RegionServer节点。生成数据的YCSB程序与数据库并不运行在相同的物理集群。
单台机器主机硬件配置
软件版本信息
测试工具
YCSB全称Yahoo! Cloud Serving Benchmark，是Yahoo公司开发的专门用于NoSQL测试的基准测试工具。github地址：https://github.com/brianfrankcooper/YCSB
YCSB支持各种不同的数据分布方式：
- Uniform：等概论随机选择记录
- Zipfian：随机选择记录，存在热记录
- Latest：近期写入的记录为热记录
测试场景
YCSB为HBase提供了多种场景下的测试，本次测试中，我们导入15亿条数据，并对如下场景进行测试：
因为是基准测试，写入和查询的数据具有以下特性：
测试核心配置参数
<!-- blockcache -->
<property>
<name>hfile.block.cache.size</name>
<value>0.05</value>
</property>
<property>
<name>hbase.bucketcache.ioengine</name>
<value>offheap</value>
</property>
<property>
<name>hbase.bucketcache.size</name>
<value>61440</value>
</property>
<!-- memstore -->
<property>
<name>hbase.regionserver.offheap.global.memstore.size</name>
<value>30720</value>
</property>
<property>
<name>hbase.hregion.compacting.memstore.type</name>
<value>BASIC</value>
</property>
<property>
<name>hbase.regionserver.global.memstore.lowerLimit</name>
<value>0.30</value>
</property>
<property>
<name>hbase.hregion.memstore.block.multiplier</name>
<value>5</value>
</property>
<property>
<name>hbase.hregion.memstore.flush.size</name>
<value>268435456</value>
</property>测试结果说明
单纯查询场景
测试参数
总记录数为15亿，分为300个region，均匀分布在4台region server上；插入操作执行20亿次，150客户端线程；
测试结果
吞吐量
读延迟
资源使用情况
结果分析
- 吞吐量曲线说明：单个实例节点稳定在3.3W左右，整个集群2台物理机稳定在11.5W左右，单台物理机稳定在5.8W左右。
- 资源使用情况说明：IO利用率达到80%左右，磁盘单盘TPS达到1.1W次，达到比较高的使用水平。CPU使用率只有40%左右，远远没有达到瓶颈。
读多写少场景
测试参数
总记录数为15亿，分为300个region，均匀分布在4台region server上；查询操作执行20亿次；查询请求分布遵从zipfian分布；读写比例8:2；
测试结果
吞吐量
读取延迟
资源使用情况
结果分析
- 吞吐量曲线说明：单个实例节点稳定在2.7W左右（其中读TPS稳定在1.9W左右，写TPS稳定在0.47W左右），整个集群2台物理机稳定在10W左右，单台物理机稳定在5W左右。
- 读取延迟说明：读P999延迟稳定在18ms左右。写P999延迟稳定在40ms左右。读写平均延迟都在1ms左右。
- 资源使用情况说明：IO利用率达到80%左右，磁盘单盘TPS达到0.8W次，达到较高的使用水平。CPU使用率达到50%。
异常情况分析
特别说明的是，测试过程中在2点28分~2点32分左右吞吐量有一个比较明显的突降，对应的P999读延迟有一个明显的飙升。直观上来看，根据资源使用情况，对应时间点测试节点的带宽有一个非常明显的突升，IOWait有一个明显的增大，对应的FsPReadTime_P999也有一个明显的增大，基本可以确定随机读P999读延迟飙升是因为IOWait突变引起的，那什么情况导致了这次网络带宽、IOWait飙升呢？可以看下面一张图：
很明显，在2点28分~2点32分之间减少了十几个HFile文件，很容易就猜测到RegionServer执行了compaction操作导致网络带宽和硬盘IO有一个明显的消耗，导致了随机读P999飙升。不过，HBase可以通过将hbase.regionserver.throughput.controller设置为org.apache.hadoop.hbase.regionserver.compactions.PressureAwareCompactionThroughputController开启compaction的限流功能，通过参数hbase.hstore.compaction.throughput.higher.bound限制compaction执行过程中的最大使用网络带宽。
读写均衡场景
测试参数
总记录数为15亿，分为300个region，均匀分布在4台region server上；查询操作执行20亿次；查询请求分布遵从zipfian分布；读写比例 5:5；
测试结果
吞吐量
读取延迟
资源使用情况
结果分析
- 吞吐量曲线说明：单个实例节点稳定在2.5W左右，整个集群2台物理机稳定在10W左右，单台物理机基本稳定在5W左右。
- 读取延迟说明：读P999延迟稳定在20ms左右，读P99延迟稳定在3ms左右。写P999延迟稳定在25ms左右。读平均延迟在1ms以内，写平均延迟在1ms以内。
写多读少场景
测试参数
总记录数为15亿，分为300个region，均匀分布在4台region server上；查询操作执行20亿次；查询请求分布遵从zipfian分布；读写比例2:8；
测试结果
吞吐量
读取延迟
资源使用情况
结果分析
- 吞吐量曲线说明：单个实例节点稳定在3.5W左右，整个集群2台物理机稳定在14W左右，单台物理机稳定在7W左右。
- 读取延迟说明：读P999延迟稳定在30ms左右，读P99延迟稳定在10ms左右。写P999延迟稳定在27ms左右。读平均延迟在1ms左右，写平均延迟在1ms以内。
测试结果分析
这次测试主要针对HBase 2.2.1这个版本进行了基准性能测试，测试结果显示无论是吞吐量还是随机读写延迟都达到了较高的水准，可以满足线上的应用场景。在我们另一个针对于真实线上数据场景（非基准数据，所以测试结果中的绝对值没有实际意义）的性能测试中对HBase 2.2.1和HBase 1.4.1这两个版本进行了对比测试，详细的测试结果就不在这里展开介绍，在读写均衡场景下，HBase 2.2.1相比HBase 1.4.1在吞吐量方面有60%的性能提升，同时随机读P999延迟从50ms降低到30ms，随机读P99从20ms降低到7ms，而且来说抖动大大减少。
