Perplexity 自研数据库 CobbleDB：两名工程师加 AI 智能体，两个月写出 4 万行 Rust

当云数据库的账单越来越贵、尾延迟越来越难控，一家 AI 搜索公司选择了最“硬核”的解法：自己造。10 月 8 日，有技术媒体报道，Perplexity 已将核心搜索服务层从亚马逊 DynamoDB 迁移到自研的分布式键值存储 CobbleDB，后者用 Rust 编写，由两名系统工程师配合 AI 编码智能体集群，在两个月内完成约 4 万行代码。

一分钟速览

• Perplexity 将核心搜索服务从 DynamoDB 迁至自研 CobbleDB；
• 批量读取延迟降为原来的五分之一，存储费用至少下降 20%；
• 架构拆分为 Pillar、Lorry、CobbleDB 三套系统，解耦持久化与热数据；
• Perplexity 计划在后续版本中开源 CobbleDB 代码库。

为什么 DynamoDB 不够用了

AI 答案引擎的读取模式，与传统文档搜索完全不同。每个查询会生成 100 到 120 个目标页面键，检索服务把它们拆成每批 10 到 20 个键并行处理。传统搜索引擎返回的是简短元数据，而面向语言模型的检索需要提取完整的分块段落与稠密向量嵌入，平均记录载荷约 50KB。在每秒超过 20 万次请求的生产规模下，DynamoDB 按字节计费的模式在经济上难以维持；更麻烦的是它像个黑盒，分区位置、缓存策略、副本路由都不可见，工程师无法避免尾延迟的尖峰。

CobbleDB 怎么做的

Perplexity 把存储架构拆成三个专用系统：负责持久状态的 Pillar、负责批量聚合的 Lorry，以及负责低延迟服务的 CobbleDB。Pillar 基于机械硬盘上的 YTsaurus 保存版本化数据，Lorry 把导出内容整理成与分区对齐的批量文件并存入 S3，CobbleDB 工作节点再独立拉取摄取，从而把热数据服务与写入密集的抓取管线彻底隔离。

CobbleDB 每个分区维护三个副本，核心守护进程以 RocksDB 作为嵌入式引擎，并结合内存映射缓存与本地 NVMe 固态硬盘。路由器把请求发送到同一可用区的副本；如果响应变慢，就进行推测性对冲，同时向另一节点的备用副本发起读取。实测中，批量读取延迟中位数从 31.4 毫秒降到 5.60 毫秒，p99 尾延迟从 123 毫秒降到 24.2 毫秒。

自建的代价

用自研系统替换全托管云数据库，意味着节点生命周期、备份验证、分区再平衡都要由内部站点可靠性工程师承担，应用还必须承受最终一致性。这笔账是否划算，取决于规模——当流量足够大，自建的边际收益会迅速超过运维成本。

趋势洞察：AI 公司正在“重造基础设施”

Perplexity 的故事有两层含义。第一层是成本：AI 应用对存储与带宽的消耗远超传统 Web，云服务的按量计费在规模面前会变得难以承受。第二层是组织形态：4 万行 Rust 由两名工程师加 AI 智能体集群完成，AI 负责集成测试、构建监控与运维手册。当 AI 开始参与基础设施本身的构建，软件工程的分工方式也在被改写。