Neki 上每秒 1.18 亿次查询

Neki 上每秒 1.18 亿次查询

💡 原文英文,约400词,阅读约需2分钟。
📝

内容提要

Neki平台预览版发布后,团队通过简单单分片主键查询测试扩展性。从5分片扩展到512分片,实现每秒1.185亿次查询,处理1.22 PiB数据,吞吐量随分片数线性增长。每分片约23万QPS,路由器p99延迟6.06毫秒,错误率约180万分之一。该测试为只读、无副本、无故障切换。

🔎

延伸解读

线性扩展的实测表现

从5分片到512分片,吞吐量几乎线性增长:分片数增加10倍,QPS也增加10倍。在50分片时,每分片速率与目标200k QPS偏差仅0.8%;到512分片时,每分片实际达到231k QPS,说明分片仍有性能余量。这种扩展性得益于工作负载的隔离性——每个分片独立处理单分片主键查询,没有跨分片查询。

测试条件的边界与限制

该基准测试是只读的,没有写入、连接或跨分片查询,且每个分片只有主节点、没有副本,测试期间也未发生故障切换。因此,118M QPS的结果反映的是理想条件下的读扩展能力,并不代表生产环境中混合读写、高可用切换或复杂查询下的表现。读者需注意这些限制,避免过度外推。

延迟与错误率的关键指标

在118M QPS下,路由器p99延迟为6.06毫秒,客户端p99延迟为13.95毫秒,错误率约为每180万次查询出现1次错误。这些数据表明系统在高吞吐下仍能保持较低延迟和可接受的错误水平。同时,整个集群消耗了15.8M读IOPS和超过2Tb/s的网络带宽,反映了底层资源的巨大投入。

Q&A

Neki 平台在扩展性测试中达到了多高的查询吞吐量?

Neki 在 512 个分片上实现了每秒 1.185 亿次查询(118,538,803 QPS),处理了 1.22 PiB 数据。

Neki 的吞吐量如何随分片数量扩展?

吞吐量随分片数线性增长:从 5 分片扩展到 50 分片再到 512 分片,每分片 QPS 保持稳定,整体吞吐量成比例增加。

Neki 测试中每个分片的查询处理能力是多少?

在 512 分片测试中,每个分片处理约 231,521 QPS,超过了原定 200k QPS 的目标。

Neki 测试的延迟和错误率表现如何?

路由器 p99 延迟为 6.06 毫秒,客户端 p99 延迟为 13.95 毫秒;错误率约为每秒 67 个错误,即约每 180 万次查询出现 1 个错误。

Neki 测试使用了什么样的硬件和架构配置?

使用了 512 个分片,每个分片有一个 Postgres 主节点运行在 r8g.16xlarge 实例上;480 个 Neki 路由器,每个运行在 8xlarge 实例上。

Neki 测试的工作负载有哪些限制条件?

测试为只读工作负载,无写入、连接或跨分片查询;分片仅为主节点无副本,且测试期间未进行故障切换。

🏷️

标签

➡️

继续阅读