I use YCSB as a starting point, not a verdict. It is helpful when the workload resembles the decision in front of me, but I still recommend measuring the real application path before choosing a store.
A benchmark needs a workload story
When I talk about "A benchmark needs a workload story", I connect the shape to the operation I want to make cheap.
A read heavy catalog, a write heavy event store, and a mixed user profile service stress different parts of a database. YCSB lets teams run named workloads so they can compare latency and throughput under the same conditions.
Store comparison example
I use "Store comparison example" to keep YCSB grounded in a real system, because abstract patterns are too easy to agree with and too hard to operate.
A team compares two key value stores before moving session data. They run a read heavy workload, then a balanced read write workload, and compare p95 latency under the same record count.
Workload config example
I use "Workload config example" to keep YCSB grounded in a real system, because abstract patterns are too easy to agree with and too hard to operate.
Run the same workload against each store before comparing latency:
./bin/ycsb load jdbc -P workloads/workloadb -p recordcount=100000
./bin/ycsb run jdbc -P workloads/workloadb -p operationcount=50000The first command loads data and the second runs workload B against the same database. Separating load from run keeps the benchmark result easier to compare.
Sequence diagram: compare data stores with one workload
The benchmark is useful because both stores receive the same workload and the team knows what pattern it represents.
The measurement choice
- Choose workloads that match real access patterns.
- Compare tail latency, not only average latency.
- Validate benchmark findings with application level tracing.