HBase 2.2.1随机读写性能测试

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

测试环境

测试环境包括测试过程中 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,而且来说抖动大大减少。

我来评几句
登录后评论

已发表评论数()

相关站点

热门文章