ycsb mysql_go-ycsb：一个 Go 的 YCSB 移植

YCSB 是一个非常出名的性能测试框架，我们可以非常方便的用它来对系统进行多维度的性能测试，本来我也准备使用它来对我们系统进行性能测试的，但在调研了一番之后，我决定直接用 Go 来完全移植一个。过年的时候就一直在干这件事情，于是就有了 go-ycsb。

为什么需要 YCSB？

先来说说为什么我们需要 YCSB，对于一个系统来说，用户在试用之前，通常都会问『你的性能怎样？』，但其实这句话是非常不好回答的。所以通常业界都会用一些基准的性能测试工具来衡量。另一方面，一个系统，性能并不是只有一个维度，譬如 sharding 的系统可能随机 read 一个 key 非常快，但如果是顺序 scan 一批 key 性能就可能嗝屁了。再就是性能其实也跟数据的分布有关系，譬如有些数据就是热点，需要频繁操作，而大部分数据其实是冷数据。刚好 YCSB 都能很好的支持这些特性。

再来说说为什么需要 Go 的 YCSB，其实无非就是两个原因：

我不会 Java。虽然我个人对语言没啥偏爱，譬如我就一直搞不懂为啥很多写 C++ 的人不喜欢 Rust，但我个人对 Java 却实在提不起兴趣，所以到了现在，看到 Java 代码我就头大，自然不会想着自己去写 Java 相关的代码。

现在 TiKV 只有 Go 的 API，虽然我们 TiSpark 带了一个 Java TiKV client，但不支持写。为了能让 YCSB 直接测试 TiKV，我现在必须使用 Go，但我又不知道如何 Java 调用 Go 的代码，所以还不如用 Go 重写 YCSB 来的简单，反正不复杂。

Benchmark Tiers

YCSB 主要测试两层 - 性能和可扩展性。

对于性能来说，主要关注的是 Latency，当然，Latency 和 Throughput 是需要取舍的，在固定的硬件条件下，当我们逐渐增加请求的时候，因为 disk，CPU，network 等竞争，请求的 latency 是在增加的。所以我们需要知道的是需要多少机器才能满足用户 lantency 和 throughput 的需求。当然，需要机器越少，证明我们系统优化的越好。这里，YCSB 采用的是非常常见的 Wisconsin Sizeup 方法，固定硬件，增加测试并发压力，直到系统出现瓶颈过载。

而对于可扩展性来说，一个是按比例增加，将硬件，数据量和负载等比增加，正常情况下面 latency 是保持恒定的。