Perplexity 将核心搜索服务从 DynamoDB 迁移至自研 CobbleDB

Perplexity 把核心搜索服务层从 Amazon DynamoDB 迁到了自研的 CobbleDB，一款用 Rust 编写的分布式键值存储。官方给出的迁移动因很具体：在高查询量下，向大语言模型提供数千字节的文档批次，产生了严重的延迟和成本瓶颈。

这个瓶颈的根源是读取模式与以往不同。发送到 Perplexity 的每个查询会生成 100 至 120 个目标页面键，检索服务把它们拆成多个包含 10 至 20 个键的批次并行处理。传统搜索引擎返回的是简短元数据片段，而面向语言模型的检索需要提取完整的分块段落和稠密向量嵌入，使平均记录载荷达到约 50 KB。

把这两组数字放在一起，就能看出压力来自哪里：键多、批次多、单条载荷大，而且这些读取都发生在用户等待答案的路径上。DynamoDB 的问题不是不能存，而是在每秒超过 20 万次请求的生产流量规模下，按使用量计费、对传输的每个字节计费的模式在经济上难以维持。

成本只是问题的一半。来源指出，DynamoDB 内部的分区位置、内存缓存策略和副本路由均不可见，工程师无法避免由未缓存读取、跨可用区网络跳转或副本延迟引起的尾延迟峰值。

另一类干扰来自写入。分块算法更新或采用新嵌入模型后触发的重新处理作业，会把大量写入直接推送到 DynamoDB，与实时用户请求形成嘈杂邻居争用。也就是说，一次模型或算法升级，可能同时抬高线上读取的延迟。

这两点合起来解释了为什么 Perplexity 选择自建而不是继续调优：当系统内部行为不可观测时，工程师能做的优化是有限的。这是从来源事实出发的推断，而非来源直接给出的结论。

Perplexity 的解法不是换一个数据库，而是把存储架构拆成三个专用系统：负责持久状态管理的 Pillar、负责批量聚合的 Lorry，以及负责低延迟服务的 CobbleDB。

Pillar 基于运行在大容量机械硬盘上的 YTsaurus，维护网页元数据、段落和向量表示的版本化表族，并由 YTsaurus 原子事务确保抓取更新、状态变更和导出队列一同提交。Lorry 充当无状态队列消费者，把 Pillar 的导出内容组合成与分区对齐的批量文件，把载荷存储到 Amazon S3，同时向 CobbleDB 发送元数据通知。CobbleDB 工作节点独立拉取并摄取这些 S3 批次，使热数据服务节点与写入密集型抓取管线完全隔离。

这个分工的关键在于：写入密集的重新处理不再直接冲击线上读取路径，而是经由 Pillar 到 Lorry 再到 S3 批次，最后才被 CobbleDB 摄取。持久层用机械硬盘换容量和成本，服务层用 NVMe 换延迟。

CobbleDB 是专门针对批量查找优化的分布式键值存储。每个分区维护三个副本，分布在相互独立的计算节点上；核心守护进程使用 RocksDB 作为嵌入式存储引擎，并结合内存映射缓存与本地 NVMe 固态硬盘。

读取路径上，无状态查询路由器把经过哈希处理的页面标识符映射到分区，优先把请求发送到同一可用区的节点副本以减少网络开销。如果目标副本响应时间升高，路由器会进行推测性对冲，同时向另一节点上的备用副本发起读取请求。

最值得注意的取舍是：CobbleDB 舍弃了标准的分布式事务协议和同步共识算法，各副本按自己的速度异步应用更新，因为搜索服务可以容忍轻微的复制延迟。这换来了更低的运维开销，但也意味着应用必须能够承受最终一致性。

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

需要明确这些数字的性质：它们来自 Perplexity 自身的生产测量与合成基准测试，来源中未见第三方独立验证。合成基准的 50 万 RPS 是测试条件，不等于生产环境的实际承载。

同样属于企业自述的还有开发规模。该公司首席执行官 Aravind Srinivas 表示，CobbleDB 由约 4 万行 Rust 代码组成，两名系统工程师与一个自主 AI 编码智能体集群配合，在两个月内完成构建，这些 AI 智能体负责集成测试、构建监控和运维手册。来源未提供可核验细节来说明这些智能体的实际参与程度与效果。

用自建系统替换全托管云数据库，意味着节点生命周期管理、备份验证和分区重新平衡将完全由内部站点可靠性工程师负责。这是迁移的另一面，也是来源明确列出的权衡。

同时，由于各副本摄取批量文件的时间间隔不同，应用程序必须能够承受最终一致性。搜索场景可以接受这一点，但这不是所有系统都能照搬的前提。

来源还提到，Perplexity 计划在即将发布的版本中开源 CobbleDB 代码库，但具体版本与时间尚未确定。迁移后系统在真实生产环境中的长期稳定性、以及最终一致性对用户体验的影响，来源均未给出数据。