Perplexity 自建 Rust 键值库 CobbleDB，批量读延迟降 5 倍、成本省 20%

一句话结论

Perplexity 用 4 万行 Rust 代码自建 CobbleDB 替代 DynamoDB，使批量读取延迟降低五倍并削减至少 20% 存储成本。

关键要点

• 检索服务将 100 至 120 个页面键拆分为 10 至 20 键的批次并行读取，单条记录平均载荷约 50 KB。
• 生产流量超过 20 万次请求/秒，DynamoDB 按字节计费导致成本失控，且尾延迟不可控。
• CobbleDB 将批量读取延迟中位数从 31.4 毫秒降至 5.60 毫秒，p99 尾延迟从 123 毫秒降至 24.2 毫秒。
• 系统采用三副本异步复制、无状态路由器和 RocksDB 嵌入式引擎，放弃分布式事务与同步共识。
• 架构拆分为 Pillar、Lorry、CobbleDB 三层，将写入密集型抓取管线与热数据服务节点物理隔离。

背景与事实

Perplexity 作为面向大语言模型的 AI 答案引擎，其读取模式与传统文档搜索存在本质差异。每个用户查询会生成 100 至 120 个目标页面键，检索服务将这些键拆分为多个包含 10 至 20 个键的批次并行处理。由于需要提取完整的分块段落和稠密向量嵌入以供模型使用，平均记录载荷达到约 50 KB，远高于传统搜索引擎返回的简短元数据片段。

在每秒超过 20 万次请求的生产流量规模下，Amazon DynamoDB 按使用量计费的模式在经济上变得难以维持，因为 AWS 会对传输的每个字节计费。此外，DynamoDB 如同一个黑盒，内部的分区位置、内存缓存策略和副本路由均不可见。工程师无法避免由未缓存读取、跨可用区网络跳转或副本延迟引起的尾延迟峰值。分块算法更新或采用新嵌入模型后触发的重新处理作业，也会将大量写入直接推送到 DynamoDB，与实时用户请求形成争用。

为解决这些限制，Perplexity 将存储架构拆分为三个专用系统：负责持久状态管理的 Pillar、负责批量聚合的 Lorry，以及负责低延迟服务的 CobbleDB。Pillar 基于运行在大容量机械硬盘上的 YTsaurus，维护网页元数据、段落和向量表示的版本化表族。Lorry 充当无状态队列消费者，将 Pillar 的导出内容组合成与分区对齐的批量文件，把载荷存储到 Amazon S3，同时向 CobbleDB 发送元数据通知。CobbleDB 工作节点独立拉取并摄取这些 S3 批次，使热数据服务节点与写入密集型抓取管线完全隔离。

CobbleDB 是一个专门针对批量查找进行优化的分布式键值存储。每个分区维护三个副本，分布在相互独立的计算节点上。核心守护进程使用 RocksDB 作为嵌入式存储引擎，并结合内存映射缓存与本地 NVMe 固态硬盘。无状态查询路由器将经过哈希处理的页面标识符映射到分区，并协调读取执行。为了尽量减少网络开销，路由器会将请求发送到位于同一可用区的节点副本。如果目标副本的响应时间升高，路由器会进行推测性对冲，同时向另一个节点上的备用副本发起读取请求。在每个节点内部，CobbleDB 通过 RocksDB 的批量 MultiGet 接口同时检索多个键，从而消除往返开销。该数据库舍弃了标准的分布式事务协议和同步共识算法，由于搜索服务可以容忍轻微的复制延迟，各个副本会按照自己的速度异步应用更新，从而大幅降低运维开销。

在实际生产测量中，CobbleDB 将批量读取延迟中位数从 31.4 毫秒降至 5.60 毫秒，p90 延迟从 56.7 毫秒降至 9.77 毫秒，p99 尾延迟从 123 毫秒降至 24.2 毫秒。处理最大 100 KB 载荷的合成基准测试表明，在每秒最多 50 万次请求的规模下，其吞吐量仍能保持稳定。

影响分析

对中文开发者与从业者而言，CobbleDB 的架构设计提供了处理“宽行、高并发、批处理”场景的参考范式。当业务形态从“查询-返回少量元数据”转变为“查询-返回大量向量或长文本块”时，通用云数据库按量计费模型可能失效。Perplexity 将持久化存储、数据聚合层与热服务层彻底解耦的三层架构，以及基于 RocksDB 与 NVMe 构建的无共识分布式键值库，表明在可接受最终一致性的读多写少场景中，自建轻量级存储比依赖全托管黑盒更具成本与延迟优势。

从工程实践角度看，该案例验证了使用本地 NVMe 与内存映射缓存替代分布式共识协议在低延迟批量读取场景的可行性。对于面临类似“大载荷、高频批量查询”瓶颈的团队，这种架构权衡——即用运维复杂度换取确定性低延迟与成本可控——值得深入评估。同时，Perplexity 计划开源 CobbleDB 代码库，将为社区提供直接可用的分布式键值存储参考实现，降低相关技术的研发门槛。

适用边界

CobbleDB 的架构设计明确舍弃了分布式事务协议与同步共识算法，其适用前提是业务场景能够容忍轻微的复制延迟与最终一致性。如果应用需要强一致性保证、复杂的多键事务操作，或对数据零丢失有严格要求，则该方案不适用。此外，系统引入了节点生命周期管理、备份验证和分区重新平衡等运维负担，要求团队具备充足的站点可靠性工程能力。对于资源有限或追求免运维托管服务的场景，自建该套系统的成本将远超收益。

孤本观察

Perplexity 使用两名工程师与自主 AI 编码智能体集群在两个月内完成 4 万行 Rust 代码的构建，这一事实表明在特定领域内，AI 编码智能体已具备参与核心基础架构组件开发的实际生产力，而不仅限于代码补全。

来源：InfoQ 中文 AI