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 &
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=10000 -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
