Neki 实测：每秒 1.18 亿次查询
118M Queries per Second on Neki
我们昨天发布了 Neki 的平台预览版，为了庆祝这一时刻，我们决定挑战每秒 100 万次查询的目标。结果在 5 个分片上就轻松达成，于是我们继续加压，最终在 512 个分片上跑出了每秒 1.18 亿次查询的惊人数据，同时处理了 1.22 PiB 的数据。这次基准测试非常纯粹：仅单分片主键点查，无写入、无连接、无跨分片查询。随着分片数量从 5 个增加到 50 个再到 512 个，吞吐量实现了完美的线性增长。在 512 个分片、480 个 Neki 路由器的配置下，我们持续 16 分钟维持了这一峰值，p99 延迟控制在毫秒级。这证明了 Neki 在大规模扩展时的卓越性能。
十倍的分片数量，带来十倍的吞吐量；再增加十倍，性能依然线性增长。
HN 评论区
44- farazbabar
2015 年，我曾在仅几个节点上实现了每秒 100 万次读写查询，并用多种数据库进行了测试。当时这需要不错的网络调优和 AWS 内部的节点布局，如果我没记错的话，每次运行成本大约在 10 到 15 美元。当然，这里还有性能扩展的问题，所以我认可为此付出的工程努力，但这笔开销实在太高了。这让我想起我所在的一个团队曾用 Hadoop 处理仅几 TB 的离线数据，结果能在几小时内处理完整个数据集。当时在演示时，我实在没忍心也没勇气告诉他们这是大材小用，但我确实写了一段非常简单（且短小）的代码，通过精心的网络规划和存储优化，仅用几秒就能从离线文件中提取所有信号。我还邀请他们下周参加演示、午餐会和学习分享。
- weekendcode
看到这样的规模和进步固然很好，但闭源是个巨大的致命伤。
Clickhouse 也在正确的轨道上，致力于构建一些与 postgres 的出色开源集成，他们最近的博客显示其托管 postgres 服务看起来更胜一筹*[1]。希望他们能推出一些开源的分片 postgres 解决方案。
[1] - https://clickhouse.com/blog/benchmarking-nvme-managed-postgr...
- stephenlf
我看过 Casey Muratori 对 Tyler Cloutier（SpacetimeDB 创始人兼发言人）[1] 的一次采访。Tyler 的一个观点是，鉴于现代 CPU 架构和缓存行（cache lines）的特性，分布式数据库需要扩展到至少 50-100 个节点，才能在吞吐量上击败经过缓存优化的单节点数据库。
很高兴能看到这一论点的另一面。Planet scale 正在回答这样一个问题：“当你确实将工作负载扩展到超过 100 个节点时，情况会是怎样的？”
这两种技术各有其用武之地。非常酷的东西。
- jamesblonde
2015 年，MySQL Cluster（NDB Cluster 引擎）在普通硬件上测得每秒 2 亿次事务 [ref]。那是读已提交（read-committed）事务，而非快照隔离（snapshot isolation），但依然令人印象深刻。NDB 现已更名为 RonDB，但仍基于非阻塞的两阶段提交协议，且采用 GPL-v2 许可。
RonDB 现在支持 InfiniBand，理应能突破每秒 10 亿次操作。作为参考，这相当于每秒 1 GHz 的事务处理速度。
[ref] https://www.slideshare.net/frazerClement/200-million-qps-on-...
- danbruc
87.3% 的请求由缓存提供。这是否意味着返回了缓存中已存在的结果，因为该查询之前执行过？如果你每秒要处理数百万次查询，看到大量重复查询似乎并不奇怪，因此结果可能仍然相关。但到了这一步，你测量的更多是缓存性能，而非查询性能。不过，除非运行标准化的查询基准测试，否则单一的每秒查询数（QPS）指标本身信息量并不大，因为查询复杂度及其执行时间可能相差好几个数量级。通过 ID 查找名称，与跨十七张关联表对十亿行数据进行聚合，两者都只是一个查询。