一 YCSB 简介

YCSB（Yahoo! Cloud Serving Benchmark）是 Yahoo 研究院开源的键值/NoSQL 数据库性能基准测试框架，支持 Redis、MongoDB、HBase、Cassandra 等。

YCSB的工具原理主要包括工具模型、负载生成器和操作执行。

二 YCSB 测试

测试主要分为两个阶段：

load阶段：向数据库批量插入测试数据（纯insert）；

run阶段：按照指定workload混合执行读、写、更新和查询操作，然后统计运行时间、吞吐量和延迟等。

三 六种核心workload

Workload	文件	操作分布	典型场景
A​	workloada	50% Read / 50% Update	会话存储，读写均衡
B​	workloadb	95% Read / 5% Update	照片标签，读多写少
C​	workloadc	100% Read	只读缓存，测纯读性能
D​	workloadd	95% Read / 5% Insert（Latest分布）	时间线，读最新记录
E​	workloade	95% Scan / 5% Insert	短范围扫描（如按 Thread ID）
F​	workloadf	50% Read / 50% Read-Modify-Write	用户记录读取并修改回写

加上开始的load操作（纯insert插入操作），一共算是7种workload。

四 workload举例

1 workloada：--5读5写        

recordcount=1000
operationcount=1000
workload=site.ycsb.workloads.CoreWorkload

readproportion=0.5
updateproportion=0.5
scanproportion=0
insertproportion=0

requestdistribution=zipfian

 2 workloadc:  --100%读

recordcount=1000
operationcount=1000
workload=site.ycsb.workloads.CoreWorkload

readproportion=1
updateproportion=0
scanproportion=0
insertproportion=0

requestdistribution=zipfian

 3 workloade:  --95%scan5%insert

recordcount=1000
operationcount=1000
workload=site.ycsb.workloads.CoreWorkload

readproportion=0
updateproportion=0
scanproportion=0.95
insertproportion=0.05

requestdistribution=uniform

maxscanlength=100
scanlengthdistribution=uniform

五 YCSB 基本执行命令

本文是测试mongodb为例：

1. 加载数据（Load 阶段）

bin/ycsb.sh load mongodb \
  -P workloads/workloada \
  -p recordcount=100000 \
  -p mongodb.url=mongodb://localhost:27017/ycsb \
  -threads 8 \
  -s

2. 运行压测（Run 阶段）
bin/ycsb.sh run mongodb \
  -P workloads/workloada \
  -p operationcount=1000000 \
  -p mongodb.url=mongodb://localhost:27017/ycsb \
  -threads 32 \
  -target 10000 \
  -s

六 YCSB测试结果

 1 完整输出结果

[OVERALL], RunTime(ms), 12560
[OVERALL], Throughput(ops/sec), 7961.783439490446
[TOTAL_GCS_G1_Young], 12
[TOTAL_GC_TIME_G1_Young(ms)], 45
[TOTAL_GCS_G1_Old], 0
[TOTAL_GC_TIME_G1_Old(ms)], 0
[READ], Operations, 62800
[READ], AverageLatency(us), 112.35
[READ], MinLatency(us), 18
[READ], MaxLatency(us), 3654
[READ], 95thPercentileLatency(us), 215
[READ], 99thPercentileLatency(us), 489
[READ], Return=OK, 62800
[UPDATE], Operations, 62800
[UPDATE], AverageLatency(us), 136.72
[UPDATE], MinLatency(us), 22
[UPDATE], MaxLatency(us), 4120
[UPDATE], 95thPercentileLatency(us), 268
[UPDATE], 99thPercentileLatency(us), 572
[UPDATE], Return=OK, 62800

2 2个核心指标

RunTime(ms)    

总压测耗时，单位毫秒；    整个 run/load 跑完一共花了多少时间；
Throughput(ops/sec)    

整体吞吐量，每秒操作数；    性能第一指标，越高越好；

3 操作类型分段

[READ]/[UPDATE]/[SCAN]/[INSERT]
每个操作类型结构完全相同，以 READ 举例：
Operations
该操作总执行次数；
AverageLatency(us)
平均延迟，微秒；越小性能越好，代表单次数据库操作平均耗时
MinLatency(us)
最小单次延迟，最优情况
MaxLatency(us)
最大延迟，毛刺、慢查询峰值，这个值大代表存在长尾慢请求
95thPercentileLatency(us)
P95 延迟：95% 的请求延迟低于该数值，业务核心参考指标
99thPercentileLatency(us)
P99 延迟：99% 请求低于该值，衡量长尾延迟，数据库优化重点关注
Return=OK, xxx
成功操作总数；OK 数量≠Operations 代表有报错（超时、连接失败、数据库异常）

4 实际业务评判标准

吞吐量 Throughput
同等线程、同等数据量下数值越高，数据库并发能力越强；Mongo 集群分片可显著提升。
P95 / P99 延迟（最重要，比平均值靠谱）
平均值容易被大量快请求抹平，长尾慢请求只会体现在分位值；线上业务卡顿大多由 P99 延迟过高导致。
成功数 Return=OK
成功次数必须等于 Operations，不等说明压测报错：
Mongo 连接池耗尽
数据库超时、锁冲突
客户端参数配置过小
GC 耗时
GC 总时间占 RunTime 比例超过 5%，建议调大 JVM 堆 -Xms8g -Xmx8g