使用 MySQL 实现每秒百万级查询

了解你的数据库能够扩展到巨大规模会带来极大的安心。我们构建 PlanetScale 是基于 Vitess，旨在利用其卓越的扩展能力。我们可扩展能力的核心优势之一是 **水平分片（Horizontal Sharding）**。为了展示水平分片的强大功能，我们决定运行一些基准测试。
我们设置了一个 PlanetScale 数据库，并开始用常见的 tpc-c sysbench 工作负载运行一些测试。我们并不是要进行严谨的学术基准测试，而是选择了一个成熟且真实的工作负载。接下来的测试文章中，我们会推出更多基准测试内容，并与一个学术机构合作发布他们的研究成果。
在本文中，我们设定了两个目标：

展示 PlanetScale 如何处理大规模查询负载。为此，我们的目标是实现 **每秒一百万查询（1M QPS）**。对于 Vitess，虽然这不是一个特别大的集群，但我们认为它是一个很好的基准。
展示通过水平扩展实现的可预测扩展性，即增加吞吐能力只是添加更多机器的事。

通过添加分片进行扩展

我们从一个未分片的数据库开始，创建了一个 vschema 并开始分片。为了方便，我们从两个分片开始，并在随后运行中逐步将分片数量加倍。对于每一级分片，我们多次运行 sysbench，逐步增加线程数量。在每次迭代中，我们发现线程数量增加到一定程度后，额外的线程不再带来额外的吞吐量，反而使查询延迟增加，因为我们达到了吞吐量的极限。
以下图表针对一个具有 16 个分片 的数据库，显示出随着 sysbench 线程的增加，连接数量（**Connections**）和查询每秒（**QPS**）的增长趋势：

Connections over time -- chart progressively going up as time increases

QPS over time -- chart progressively going up as time increases

达到瓶颈

然而，当我们饱和了每个分片的资源时，开始出现效益递减的情况。以上图所示，在 1024 个线程 和 2048 个线程 之间，QPS 增加幅度更大，而在 2048 个线程 和 4096 个线程 之间，QPS 增加幅度明显减少。
同样，在以下 vtgate 的指标中，当我们吞吐量达到极限时，延迟（**Latency**）开始增加，尤其是在 p99 延迟 中表现明显：

此时，我们知道需要增加更多的分片以获得更高的吞吐量。

添加更多分片

以下图表展示了随着分片数量加倍，QPS 也大致加倍的趋势。例如，使用 16 个分片 达到了大约 **420k QPS**，而使用 32 个分片 达到了 **840k QPS**。虽然我们可以无限制地继续加倍分片数量，但我们设定了每秒一百万查询的目标，因此选择了合理的方法。

分片数量与 QPS 的关系图表

实现每秒一百万查询

值得注意的是，虽然我们喜欢以 2 的倍数增加分片数，但这并不是限制，我们可以使用其他分片数量。当我们使用 32 个分片 达到约 800k QPS 后，计算发现 40 个分片 可以满足 1M QPS 的需求。当我们启动此数据库并通过并行 sysbench 客户端运行测试时，结果显示：在 5 分钟运行时间内，**持续超过一百万 QPS**。