CDH版HBase的压测测试 YCSB

最新推荐文章于 2025-11-26 01:01:30 发布

原创最新推荐文章于 2025-11-26 01:01:30 发布 · 629 阅读

2 ·

CC 4.0 BY-SA版权

文章标签：

#hbase #压力测试 #时序数据库

本文详细介绍了使用YCSB对CDH6.3.2上的HBase 2.1.0进行压力测试的步骤，包括前置介绍、建表、数据加载、运行工作负载和自定义压测策略。在测试过程中，考虑了集群配置、内存大小、读写比例和内部传输速率等因素，旨在评估HBase的性能表现。

前置介绍

YCSB 是一个基准测试系统的框架

https://github.com/brianfrankcooper/YCSB github地址

做压测的时候下载自己需要的单个压缩包就好了

Release YCSB 0.17.0 · brianfrankcooper/YCSB · GitHub 下载地址

压测步骤如下:

设置数据库系统进行测试
选择合适的数据库接口层
选择合适的工作量
选择适当的运行时参数（客户端线程数、目标吞吐量等）
加载数据
执行工作量

总结就是找到合适的组件或者直接使用JDBC连接然后设置配置文件调整想要测试的数据类型和大小和读写比例

具体使用文档在YCSB的解压的插件包中都有

当前YCSB支持的数据库

YCSB自带六种测试策略在workloads中分别是不同的读写比例

Workloada 是50%读和50%写入

CDH版HBase的压测测试

集群配置

cnenos7.5

CDH6.3.2

HBase2.1.0

三台机器.一个master ,三个regionserver 主节点64G 从节点32G

千兆交换机

1 建表

创建好Hbase的表格官方默认表名为usertable列族为family

hbase(main):001:0> n_splits = 100 #指定region数量 对应分区数 提高效率 建议为 10*reionservers 
hbase(main):002:0> create 'usertable', 'family', {SPLITS => (1..n_splits).map {|i| "user#{1000+i*(9999-1000)/n_splits}"}}

2 load the Workload

bin/ycsb load hbase20 -cp /etc/hbase/conf -P workloads/workload_datasize10k_write100_read0 -s -threads 72 -s > logs/load.log
-cp 指定Hbase配置文件地址 
-P  指定压测策略
-p 用来设置一些参数，比如数据库的 ip和port。
-s -threads 线程数
-s > 将结果写入文件 需要事先创建好 会覆盖写 追加需要>>
还有更多参数 可以查看官方文档

3 Run the Workload

bin/ycsb run hbase20 -cp /etc/hbase/conf -P workloads/workload_datasize10k_write100_read0 -s -threads 72 -s > logs/run.log
同上.注意run参数

4 自定义压测策略

#拷贝模板并修改
cp workload_template workload_datasize10k_write100_read0
vim workload_datasize10k_write100_read0
#数据量 operationcount=100000
#字段数量 fieldcount=10 
#单个字段大小(字节) fieldlength=512 
#读取操作占比 readproportion=0 
#更新操作占比 updateproportion=0 
#插入操作占比 insertproportion=1 
#表名称 table=usertable 
#列族名称 columnfamily=family

影响因素

集群内存大小 开的线程数  硬盘的写入性能 Hbase的写缓存 可以调大 或者直接关闭提高性能(可能丢失数据)

调整主要可以从HBase和HDFS这两个方面来调整,主要就是提高内存大小 ,调整读写比例,提高内部的传输速率(提高线程数),将不同的DataNode节点在不同的硬盘上的,也可以设置多个DataNode目录到不同磁盘上

[OVERALL], RunTime(ms), 47093  数据加载所用时间： 
[OVERALL], Throughput(ops/sec), 21234.578387446116 加载操作的吞吐量，平均并发量每秒 
[TOTAL_GCS_PS_Scavenge], Count, 26
[TOTAL_GC_TIME_PS_Scavenge], Time(ms), 106
[TOTAL_GC_TIME_%_PS_Scavenge], Time(%), 0.22508653090692882
[TOTAL_GCS_PS_MarkSweep], Count, 1
[TOTAL_GC_TIME_PS_MarkSweep], Time(ms), 25
[TOTAL_GC_TIME_%_PS_MarkSweep], Time(%), 0.05308644596861529
[TOTAL_GCs], Count, 27
[TOTAL_GC_TIME], Time(ms), 131
[TOTAL_GC_TIME_%], Time(%), 0.27817297687554415
[CLEANUP], Operations, 64                                   执行 cleanup 的操作总数，
[CLEANUP], AverageLatency(us), 329.0                        平均响应时间
[CLEANUP], LatencyVariance(us), 4658500.3125    
[CLEANUP], MinLatency(us), 0                                最小响应时间
[CLEANUP], MaxLatency(us), 17160                            最大响应时间 
[CLEANUP], 95thPercentileLatency(us), 0      95% 的 cleanup 操作延时0ms在以内
[CLEANUP], 99thPercentileLatency(us), 17000  99% 的 cleanup 操作延时在17ms以内
[INSERT], Operations, 1000000                执行 insert 操作的总数
[INSERT], AverageLatency(us), 1460.949743    每次 insert 操作的平均时延，
[INSERT], LatencyVariance(us), 8535727.324487234
[INSERT], MinLatency(us), 643
[INSERT], MaxLatency(us), 165676
[INSERT], 95thPercentileLatency(us), 1000    95% 的 insert 操作延时在1ms以内
[INSERT], 99thPercentileLatency(us), 4000    99% 的 insert 操作延时在4ms 以内
[INSERT], Return=OK, 1000000                 成功返回数，