五场 P99 CONF 演讲揭示了数据库的哪些权衡
内容提要
P99 CONF 2026 的五场演讲探讨了数据库存储中的权衡：LSM 树在读写放大之间取舍，并适配对象存储；ScyllaDB 的 Logstor 以更大的内存索引换取单次磁盘读取；Valkey 用无锁队列提升 I/O 线程吞吐并改进分片迁移；turbopuffer 用分层聚类与量化压缩支撑千亿级向量检索；TigerBeetle 自建对象存储客户端以提升性能。核心结论是：优化一处瓶颈往往会带来新的成本。
延伸解读
RUM 权衡是理解五场演讲的主线
文章用读放大、写放大和空间放大（RUM 猜想）串起五场演讲：LSM 树在读写之间调参，Logstor 用更大内存索引换单次磁盘读，turbopuffer 用量化压缩把瓶颈从带宽转移到 CPU。读者可借此判断：每个方案都在特定负载下优化某一项，而非全面胜出。评估数据库时，应先明确自己的读写比例和延迟目标，再对照它牺牲了哪一项。
对象存储便宜，但冷读延迟差两个数量级
Gavra 的对比显示，本地 NVMe 缓存未命中约 150 微秒，而 S3 Standard 为 20–30 毫秒，相差约两个数量级；对象还只能替换不能编辑，每次 GET/PUT 都有费用。因此 SlateDB 这类对象存储原生 LSM 依赖缓存把冷读挡在热路径之外。对考虑把数据放到 S3、GCS 或 R2 的团队，这意味着存储成本和持久性优势需要靠缓存层和批量写入来兑现，不能直接套用本地盘的经验。
性能数字要对照测试条件，不能直接横向比较
Logstor 的 110 万读/秒测试使用 2 KB 值，而演讲中 LSM 示例用 1 KB 值，文章明确说这不是直接对比；Valkey 的约 120 万请求/秒也是特定无流水线 GET 负载的结果，并非通用吞吐保证；TigerBeetle 的 20 倍上传优势同样限定在 8 MB 请求、纯 HTTP、无校验和的测试环境。读者引用这些数字时，应同时说明负载、值大小和硬件条件，避免把工作负载特定结果当成产品基准。
自建关键组件能换来可控性，但前期成本更高
TigerBeetle 因 AWS C++ SDK 的阻塞 getaddrinfo 调用会卡住单核事务处理，选择自建多云端对象存储客户端，用 Zig 实现自定义 DNS、TLS、HTTP 和 io_uring，代码不足 4 万行且无工具链外依赖。Kreuzmayr 的结论是前期工作更多，但代码更易测试和调优。这提示团队：当官方 SDK 与核心设计目标冲突时，自建可作为选项，但需评估维护负担和测试能力，而非默认复制。
Q&A
数据库存储设计中常说的RUM猜想是什么？
RUM猜想指数据库存储设计需要在读放大、写放大和空间放大之间进行权衡。优化其中一项往往会增加另一项，具体取决于工作负载和配置。
LSM树在对象存储上使用有哪些优缺点？
LSM树的不可变文件适合对象存储，能利用其低成本、高持久性和可用性。但对象必须替换而非编辑，每次GET和PUT都有费用，且冷读较慢：本地NVMe缓存未命中约150微秒，而S3标准存储需20-30毫秒。
ScyllaDB的Logstor存储引擎适合什么场景？
Logstor是面向读密集型键值工作负载的可选存储引擎，适合键集合有界、频繁覆盖写和点查询且能接受额外内存开销的场景。它通过内存索引实现单次磁盘I/O读取，但写入时需写完整新值并产生死空间，后续压缩回收。
Valkey如何提升I/O线程的吞吐量？
Valkey使用无锁队列让网络I/O和命令解析在I/O线程上保持活跃，而命令执行仍留在主线程。在非流水线GET基准测试中，p50延迟飙升的阈值从约15万请求/秒提升到约120万请求/秒，约为原来的8倍。
turbopuffer如何支撑千亿级向量检索？
turbopuffer采用分层聚类将邻近向量分组，并用RaBitQ二值量化将影子索引压缩到每维1比特，先缩小候选范围再用全精度向量重排。数据持久化在对象存储，但高查询负载下固定在本地SSD缓存。早期结果在超1000 QPS下p99延迟200毫秒，召回率92%。
TigerBeetle为什么自建对象存储客户端？
TigerBeetle需要与单核事务处理兼容的对象存储客户端。AWS C++ SDK的阻塞getaddrinfo调用会卡住事务工作，SDK线程池、运行时分配和依赖也与设计目标冲突。因此自建多云端客户端，支持S3、Azure和GCP，代码少于4万行且无额外依赖。
