Hbase数据库压测（针对KV型 hbase，ES，MongoDB）

孤独的巢

已于 2023-05-16 16:55:57 修改

阅读量790

点赞数 1

文章标签：数据库 hbase elasticsearch

于 2022-11-08 17:20:45 首次发布

本文链接：https://blog.csdn.net/weixin_47099283/article/details/127754783

版权

Yahoo（Ycsb）

1.工具介绍

yahoo! Cloud Serving Benchmark (YCSB) 是一个Java语言实现的主要用于云端或者服务器端的数据库性能测试工具，其内部涵盖了常见的NoSQL数据库产品，如Cassandra、MongoDB、HBase、Redis等等，

这个框架具有很好的可扩展性，可以通过配置文件来指定需要进行什么样的workload的测试，比如读写比例多少，每条记录多大，每个字段多大，并发数多大，进行随机选择使用的分布(比如读一条数据的时候)等。

2.Git地址

GitHub - brianfrankcooper/YCSB: Yahoo! Cloud Serving Benchmark

3.工具下载

Home · brianfrankcooper/YCSB Wiki · GitHub

4 工具使用

工具结构

压测场景

上述结构中包括了一个workloads文件夹，其中包括了6中压测场景分别如下

workloada: 读写均衡型，【Read/update】（50/50）

workloadb: 读多写少型，【Read/update】（95/5）

workloadc: 只读型，【Read/update】（100/0）

workloadd: 读最近写入记录型，【Read/update/insert 】（95/0/5）

workloade: 扫描小区间型，【Scan/insert】（95/5）

workloadf: 读写入记录均衡型，【Read/read-modify-write】（50/50）

注意事项

关于压测的一些执行参数，可以参考workloads目录下面给出的一个模板文件具体如下所示（workload_template：运行压测的一个模板【具体内容可以参考工具内部使用说明】）

集群压测

1. 压测准备

1.1 环境准备

针对HBASE集群压测前根据当前集群的HBASE版本拷贝集群的hbase-site文件到ycsb的hbase目录下面，具体如下所示:

1.2 创建HBASE压测表

n_splits = 10
create 'table_name', 'cf', {SPLITS => (1..n_splits).map {|i| "user#{1000+i*(9999-1000)/n_splits}"}}
disable 'table_name'
alter 'table_name', NAME => 'cf', COMPRESSION => 'GZ'
enable 'table_name'

2. Mock数据

2.1 执行命令

nohup ../ycsb-0.15.0/bin/ycsb load hbase20 -P ../ycsb-0.15.0/workloads/workloadb -p table=table_name -p columnfamily=cf -p recordcount=20000 -p insertcount=10000 -p insertstart=0-threads 10 -s >> /logs/load/load_10.txt 2>&1 &

2.2 参数详解

table：当前带压测的数据表名

columnfamily：具体操作的列簇名称

recordcount：本次mock的总记录数

insertcount：开始从那条记录开始插入

threads：执行数据mock的线程数

2.3 特殊说明

上述执行命令中有2条造数据的命令，可以分布在不同服务器上执行（总体上造10000条数据，其中启动两个进程同时造模拟数据，每个进程造5000条，每个进程里面有50个线程来执行）。

3. 执行压测

3.1 执行命令

nohup ../ycsb-0.15.0/bin/ycsb run hbase20 -P ../ycsb-0.15.0/workloads/workloadb -p table=table_name -p columnfamily=cf -p operationcount=100000 -threads 10 -s >> /logs/run/run_b_10.txt 2>&1 &

3.2 参数详解

table：当前带压测的数据表名

columnfamily：具体操作的列簇名称

operationcount：本次压测需要执行的记录数

threads：执行压测启动的线程数

3.3 特殊说明

在每一个workload场景的模板中都有一个参数（requestdistribution ）有如下的选项

uniform：随机选择一个记录
sequential：按顺序选择记录
zipfian：根据 Zipfian 分布来选择记录。大致意思就是互联网常说的80/20原则，也就是20%的key，会占有80%的访问量
latest：和 Zipfian 类似，但是倾向于访问新数据明显多于老数据
hotspot：热点分布访问
exponential：指数分布访问

报告解读

主要关注：执行时间RunTime、吞吐量Throughput，

以及读和写的平均延迟等95thPercentileLatency、99thPercentileLatency

1. 压测报告

[OVERALL], RunTime(ms), 10252
[OVERALL], Throughput(ops/sec), 9754.194303550526
[TOTAL_GCS_PS_Scavenge], Count, 24
[TOTAL_GC_TIME_PS_Scavenge], Time(ms), 66
[TOTAL_GC_TIME_%_PS_Scavenge], Time(%), 0.6437768240343348
[TOTAL_GCS_PS_MarkSweep], Count, 1
[TOTAL_GC_TIME_PS_MarkSweep], Time(ms), 23
[TOTAL_GC_TIME_%_PS_MarkSweep], Time(%), 0.2243464689816621
[TOTAL_GCs], Count, 25
[TOTAL_GC_TIME], Time(ms), 89
[TOTAL_GC_TIME_%], Time(%), 0.8681232930159969
[READ], Operations, 94990
[READ], AverageLatency(us), 909.1641435940626
[READ], MinLatency(us), 201
[READ], MaxLatency(us), 76031
[READ], 95thPercentileLatency(us), 1936
[READ], 99thPercentileLatency(us), 5663
[READ], Return=OK, 94990
[CLEANUP], Operations, 20
[CLEANUP], AverageLatency(us), 156.35
[CLEANUP], MinLatency(us), 0
[CLEANUP], MaxLatency(us), 2847
[CLEANUP], 95thPercentileLatency(us), 217
[CLEANUP], 99thPercentileLatency(us), 2847
[UPDATE], Operations, 5010
[UPDATE], AverageLatency(us), 1872.3073852295408
[UPDATE], MinLatency(us), 616
[UPDATE], MaxLatency(us), 33791
[UPDATE], 95thPercentileLatency(us), 4371
[UPDATE], 99thPercentileLatency(us), 9743
[UPDATE], Return=OK, 5010