HBase 2.2.1随机读写性能测试

团队小伙伴前段时间对HBase 2.2.1的随机读写性能进行了初步的基准测试,这次测试主要目的是评估社区HBase 2.x版本的整体性能,量化当前HBase的性能指标,对常见KV场景下HBase性能表现进行评估,为业务应用提供参考。

测试环境

测试环境包括测试过程中HBase集群的拓扑结构、以及需要用到的硬件和软件资源,硬件资源包括:测试机器配置、网络状态等等,软件资源包括操作系统、HBase相关软件以及测试工具等。

集群拓扑结构

本次测试中,测试环境总共包含3台物理机作为Hadoop数据存储,其中2台物理机作为RegionServer部署宿主机,每个宿主机上起2RegionServer节点,整个集群一共4RegionServer节点。生成数据的YCSB程序与数据库并不运行在相同的物理集群。

单台机器主机硬件配置


软件版本信息

 

测试工具

 

YCSB全称Yahoo! Cloud Serving Benchmark,是Yahoo公司开发的专门用于NoSQL测试的基准测试工具。github地址:https://github.com/brianfrankcooper/YCSB

YCSB支持各种不同的数据分布方式:

  • Uniform:等概论随机选择记录
  • Zipfian:随机选择记录,存在热记录
  • Latest:近期写入的记录为热记录

测试场景

YCSBHBase提供了多种场景下的测试,本次测试中,我们导入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亿,分为300region,均匀分布在4region server上;插入操作执行20亿次,150客户端线程;

测试结果

吞吐量

 


读延迟

 

 

资源使用情况

 


结果分析

  • 吞吐量曲线说明:单个实例节点稳定在3.3W左右,整个集群2台物理机稳定在11.5W左右,单台物理机稳定在5.8W左右。
  • 资源使用情况说明:IO利用率达到80%左右,磁盘单盘TPS达到1.1W次,达到比较高的使用水平。CPU使用率只有40%左右,远远没有达到瓶颈。

读多写少场景

测试参数

总记录数为15亿,分为300region,均匀分布在4region 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亿,分为300region,均匀分布在4region server上;查询操作执行20亿次;查询请求分布遵从zipfian分布;读写比例 5:5

测试结果

吞吐量

 

读取延迟

 

资源使用情况

 

 

结果分析

  • 吞吐量曲线说明:单个实例节点稳定在2.5W左右,整个集群2台物理机稳定在10W左右,单台物理机基本稳定在5W左右。
  • 读取延迟说明:读P999延迟稳定在20ms左右,读P99延迟稳定在3ms左右。写P999延迟稳定在25ms左右。读平均延迟在1ms以内,写平均延迟在1ms以内。

写多读少场景

测试参数

总记录数为15亿,分为300region,均匀分布在4region 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,而且来说抖动大大减少。

范欣欣

就职于网易杭州研究院后台技术中心数据库技术组,从事HBase开发、运维,对HBase相关技术有浓厚的兴趣。邮箱:libisthanks@gmail.com

发表评论

电子邮件地址不会被公开。 必填项已用*标注