一 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