北京
作者 | Olimpiu Pop
译者 | 田橙
Perplexity 已将其核心搜索服务层从 Amazon DynamoDB 迁移到 CobbleDB，这是一款 使用 Rust 编写的内部自研分布式键值存储。此次迁移旨在解决高查询量下向大语言模型提供数千字节文档批次所产生的严重延迟和成本瓶颈。通过将持久化文档存储与热数据层检索解耦，工程团队将批量读取延迟降低了五倍，同时使整体存储费用至少下降了 20%。
人工智能答案引擎的读取模式与传统文档搜索不同。发送到 Perplexity 的每个查询会生成 100 至 120 个目标页面键，检索服务会将其拆分成多个包含 10 至 20 个键的批次并行处理。传统搜索引擎返回的是简短的元数据片段，而面向语言模型的检索则需要提取完整的分块段落和稠密向量嵌入，使平均记录载荷达到约 50 KB。
在每秒超过 20 万次请求的生产流量规模下，DynamoDB 按使用量计费的模式在经济上变得难以维持，因为 AWS 会对传输的每个字节计费。此外，DynamoDB 如同一个黑盒，内部的分区位置、内存缓存策略和副本路由均不可见。工程师无法避免由未缓存读取、跨可用区网络跳转或副本延迟引起的尾延迟峰值。分块算法更新或采用新嵌入模型后触发的重新处理作业，也会将大量写入直接推送到 DynamoDB，与实时用户请求形成嘈杂邻居争用。
为解决这些限制，Perplexity 将存储架构拆分为三个专用系统：负责持久状态管理的 Pillar、负责批量聚合的 Lorry，以及负责低延迟服务的 CobbleDB。
Pillar 基于运行在大容量机械硬盘上的 YTsaurus，维护网页元数据、段落和向量表示的版本化表族。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 万次请求的规模下，其吞吐量仍能保持稳定。
该架构也带来了不可忽视的权衡。用自建系统替换全托管云数据库，意味着节点生命周期管理、备份验证和分区重新平衡都将完全由内部站点可靠性工程师负责。由于各个副本摄取批量文件的时间间隔不同，应用程序还必须能够承受最终一致性。
该公司首席执行官 Aravind Srinivas 表示，CobbleDB 由约 4 万行 Rust 代码组成，两名系统工程师与一个自主 AI 编码智能体集群配合，在两个月内完成了构建。这些 AI 智能体负责集成测试、构建监控和运维手册。Perplexity 表示，计划在即将发布的版本中开源 CobbleDB 代码库。
https://www.infoq.com/news/2026/09/cobbledb-perplexity/
声明：本文为 InfoQ 翻译，未经许可禁止转载。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
