Perplexity 重写 AI 搜索存储层，用自研系统 CobbleDB 替代 DynamoDB

CobbleDB 深度解读：Perplexity 为什么重写 AI 搜索的存储层 @perplexity_ai 用「一个热存储（CobbleDB）+ 一个持久状态层（Pillar）+ 一个批量投递层...

CobbleDB 深度解读：Perplexity 为什么重写 AI 搜索的存储层 @perplexity_ai 用「一个热存储（CobbleDB）+ 一个持久状态层（Pillar）+ 一个批量投递层（Lorry）」的三件套替换了 DynamoDB，把批量读延迟降低约 5 倍、成本降低至少 20%，而这套约 4 万行 Rust 的系统由 2 名工程师 + 数百个 AI Coding Agents 在两个月内建成；这两组数字共同构成了 Perplexity 的核心表达：在 AI agent 时代，“自建” vs “买托管服务”的天平已经变了。 perplexity.ai/hub/blog/cobbl… # 问题：AI 原生搜索对存储提出了什么不同要求？ 传统搜索栈是为「人类读者」设计的：返回一页排序好的链接即可。而 AI 搜索是为「语言模型」服务的：系统必须在离线阶段把每个网页清洗、切成语义连贯的段落、计算每段的向量嵌入，并把段落和向量一起存好；查询时再按相关性批量取出喂给模型。 这带来两种截然不同的负载： · 写侧（离线处理）：网页持续抓取和更新，且只要切换分块方法或嵌入模型，就可能要重处理语料库的大头。写入天然是大批量、可重放、不赶时间的。 · 读侧（在线服务）：一次 Search API 请求要取 100–120 个页面 key，拆成 10–20 个 key 一批、平均单条 50KB 的批量读，而且就在通向最终答案的关键路径上，必须快。 这两种负载的正确设计方向几乎相反：处理侧要 durable 队列、可重试、可大规模回填；服务侧要预计算好的记录、热缓存、极简的查询时开销。把它们塞进同一个数据库，就会让回填和恢复工作干扰延迟敏感的在线读——这正是 Perplexity 原架构的病根。 # DynamoDB 的三个具体短板 1. 按字节计费的经济性：读写每一个字节都要钱。持续的抓取更新消耗写容量，每次查询取回准备好的页面批次消耗读容量，成本随语料库和流量线性膨胀，且和记录大小、更新频率挂钩，而不仅是调用次数。 2. 无法调优的托管黑盒：Perplexity 需要的操作其实极窄，给一批页面 ID，快速返回准备好的内容。但影响这个操作的所有因素（哪个机器持有哪个分区、多少内存给缓存、哪个副本服务请求）都锁在 DynamoDB 内部。一次缓存未命中、一次跨可用区跳转、一个慢副本，都会拖慢整个批次，而他们无法干预。 3. 处理管道与热存储直连：旧管道把每个处理完的页面直接写入 DynamoDB，于是大规模重处理任务变成对在线库的写入洪峰。他们无法在一两天内对全库跑一遍 MapReduce 来试验新的分块方法或换嵌入模型，这对需要快速迭代模型技术的 AI 搜索公司是致命的速度瓶颈。 # 新架构：职责分离的三件套 CobbleDB ～ 可调优的读路径（热存储） 分布式 KV 存储：key 是页面 ID（哈希后的 URL），value 是预切好的段落和逐段嵌入。要点在于控制权： · 数据分区，每分区 3 副本分布在不同节点；节点用 RocksDB 做本地存储引擎（适合批量喂入、重读取的负载）。 · 热数据走内存，冷数据走本地 NVMe，内存/磁盘配比完全自己调。 · 无状态查询路由器把 key 哈希到分区并行发出请求，优先同可用区副本以避免跨区延迟；某副本响应慢就对冲（hedge）到其他副本，直接改善尾延迟。 · 刻意砍掉不需要的功能：不要事务、不要副本强同步。写入到可读之间有几秒间隙可接受，副本之间摄入进度不一致也可接受。少即是省。 Pillar ～ 持久文档状态与发布决策（基于 YTsaurus） 存储爬取和处理过的一切，把元数据、段落、嵌入分存在不同的 YTsaurus 表族里，并对段落和嵌入做版本化，多套表示共存不互相覆盖，嵌入模型可以随时换。因为 Pillar 走便宜的 HDD，容量远超从前。它还维护「子集」策略，比如新鲜页面、高价值页面，只有子集内的文档才导出到昂贵的 NVMe 热存储。正确性由 YTsaurus 原子事务保证：状态更新、输入确认、导出排队，要么全成要么全不动。 Lorry ～ 批量投递的无状态服务 唯一职责是把 Pillar 的导出记录按分区攒成批次文件。关键设计是数据面与控制面分离：批次写到 S3，只在 CobbleDB 控制面注册；各分区副本各自拉取属于自己的 S3 批次、按序异步应用。慢节点或恢复中的节点按自己的节奏追赶，不会拖累整个系统。 这条链路（Pillar → Lorry → CobbleDB）实现了核心解耦：处理事务与热存储摄入分离，且为增量更新和全量重建提供了可重放的路径。 # 验证结果 指标 ｜ DynamoDB ｜ CobbleDB ｜ 提升 P50 ｜ 31.4 ms ｜ 5.60 ms ｜ ≈5.6× P90 ｜ 56.7 ms ｜ 9.77 ms ｜ ≈5.8× P99 ｜ 123 ms ｜ 24.2 ms ｜ ≈5.1× 生产环境约 200k rps（压测到 500k rps 无退化），每批 10–15 个 key、单条 50KB。值得肯定的是方法论上的诚实：团队明确指出这是观察性的前后对比（两套系统在不同时间服务真实流量，而非同一请求的受控对照），因此又补做了合成基准（10–15 key 批量、100B–100KiB 取值范围）来佐证。 成本上，基于内部的存储量与读写容量估算，每一档承诺折扣下 CobbleDB 都至少便宜 20%，且未计入压缩带来的备份节省，实际可能更高。 # 同样值得注意的：AI agent 集群怎么参与建造 约 4 万行 Rust 的核心库加上周边迁移工作，由 2 名人类工程师 + 数百个持续在线的编码 agent 在两个月内完成。 Agent 集群的特点是跨会话持久（保留项目目标、风险、仓库历史、既往决策），承担了：审计在途工作、代码与基础设施审查、暴露易漏的阻塞项（不安全的恢复假设、过期的构建引用、运行时会失败的配置）、准备修复/测试/监控/文档、跟踪 CI 和评审门禁、监控发布并对照成功准则。 人类仍然掌管架构决策、重要变更评审和生产操作授权，Agent 负责决策之间的持续性检查和跟进。 Perplexity @perplexity_ai We’re publishing research on how we built CobbleDB, our key-value database that serves web content for Perplexity search. Two engineers and a team of hundreds of proactive, always-on AI agents built the core infrastructure in two months. 🔗 View Quoted Tweet 💬 0 🔄 0 ❤️ 0 👀 333 ⚡