升级 Query Insights 到 Metal
引言
随着 PlanetScale Metal 现已全面上线，我想分享一篇文章，描述我们将驱动 Query Insights 功能的 PlanetScale 数据库迁移到 Metal 的过程以及其中的经验。
Query Insights 数据采集过程
首先，让我们了解一下 Query Insights 是如何收集数据的。基本步骤如下：
- 从你的 PlanetScale 数据库的 Vitess 层收集查询模式的遥测数据；
- 将数据发布到 Kafka；
- 从 Kafka 消费数据并将其写入几个 MySQL 表中，以时间为单位进行聚合。
扩展性挑战
Query Insights 流水线的主要扩展性问题是确保我们能够快速处理和写入数据库以响应不断涌入的数据量。为了实现这一目标，我们：
- 以批量形式读取 Kafka 消息；
- 在内存中合并数据以避免不必要的写入；
- 将写入操作移交给每个 Kafka 消费者的线程池。
Pre-Metal 阶段：高写入+预配置 IOPS
这导致了 Query Insights 数据库是非常 写入密集型 的。截至本文撰写时，我们每秒执行约 10k 次 UPDATE/INSERT 语句。这些写入操作来自 32 个消费者进程，每个进程有 25 个写入线程，总最大并发数达到 800 个线程。
Query Insights 的 PlanetScale 数据库有 8 个分片。在升级到 Metal 之前，为了能够应对庞大的遥测数据量，我们不得不为支持 MySQL 的 EBS 卷 **预配置更多的 IOPS**。由于这种工作负载对 I/O 延迟非常敏感，我们认为它是升级到 Metal 的绝佳候选。
迁移到 Metal 后的性能提升
为了实施迁移，我们首先选择了 8 个 MySQL 分片中最繁忙的一个进行初步升级。
以下图表显示了不同分位数的查询延迟情况。图中的线条表示 Insights 数据库的 8 个主库的延迟，其中紫色线条对应我们的最繁忙分片，大约在 19:35 完成 Metal 升级。
Insights Metal 升级分片延迟（P50）
Insights Metal 升级分片延迟（P90）
Insights Metal 升级分片延迟（P95）
Insights Metal 升级分片延迟（P99）
从测试结果可以看出，将一个分片升级到 Metal 会在所有测量分位数上显著降低延迟。升级后，我们最繁忙分片的查询执行速度显著快于其他分片。
所有分片的全面升级与结果
在让第一个分片进行几天观察后，我们将其余分片升级到 Metal，并观察到几乎相同的性能提升。
值得注意的是： 我们无需对应用程序、架构或分片配置进行任何修改，只通过将数据库迁移到 PlanetScale Metal，就获得了显著的性能提升。
这使得我们 Kafka 消费者的平均积压队列量明显降低，并为我们未来处理增加的消息量提供了额外的容量。
通过这次升级，PlanetScale Metal 再次证明了其强大的性能能力，为高写入密集型数据库工作负载提供了可靠的解决方案，同时简化了架构的调整过程。
关注公众号：程序新视界，一个让你软实力、硬技术同步提升的平台
除非注明，否则均为程序新视界原创文章，转载必须以链接形式标明本文链接
