AREX Feed Article
Perplexity 公布自研键值数据库 CobbleDB 构建研究，称两名工程师与数百个 AI 智能体两个月建成核心基础设施，并计划开源
北京时间 9 月 16 日凌晨，Perplexity 官方 X 账号（@perplexity_ai）发布，宣布公开自研键值数据库 CobbleDB 的构建研究。帖文称，这套为 Perplexity 搜索存取网页内容的系统，核心基础设施由两名工程师和数百个「主动、常驻」的 AI 智能体在两个月内建成。
Perplexity 工程团队在官方博客发布的中称，替换 DynamoDB 后，批量读取的中位延迟从 31.4 毫秒降至 5.60 毫秒，p99（最慢的 1% 请求）延迟从 123 毫秒降至 24.2 毫秒；内部成本模型估算至少比 DynamoDB 节省 20%。文章还称计划开源 CobbleDB，并把延迟对比标注为观察性的前后测量。上述数字与开源计划都来自 Perplexity 自己发布的材料。
一次搜索请求要读 100～120 个页面键
在文章的描述里，这次重建是 Perplexity 自建路线的延续：此前它已自建爬取、索引与排序基础设施、嵌入模型和推理引擎，现在轮到存储层。存储要同时处理两类负载：把抓取来的网页清洗、切分、算出向量后持续写入，以及在查询时快速读出候选页面的内容。
文章给出的负载数字是：一次 Search API 请求包含 100～120 个页面键，检索过程再把这些键拆成每批 10～20 个，平均每条记录约 50 KB。
文章把 DynamoDB 不够用的原因归纳为三条。第一，它按读写字节计费，索引规模和查询量增长会直接推高成本。第二，托管服务不提供 Perplexity 需要的调优自由度：公司想控制哪台机器持有某个分区、给缓存分配多少内存、由哪个副本响应请求，而未命中缓存的读、跨可用区的跳转或一个慢副本都可能拖慢整批请求。第三，旧的文档处理管线把每个备好的页面直接写进 DynamoDB，一次大规模重处理就变成一波波单条写入；公司称没法在 1～2 天里对全库跑 MapReduce，来试验新的切分方法、更换嵌入模型或新增字段。
Perplexity 的重建方式是把职责拆开：Pillar 负责持久的文档状态与发布，Lorry 负责把导出变成按分区打包的批次，CobbleDB 负责摄取这些批次、在查询时按页面键提供已备好的记录，充当面向线上读的热存储。文章强调，CobbleDB 的定位是专用系统，只服务「反复批量读取已备好的页面记录」这一种负载。
读路径：按分区并行读，慢副本可以绕开
CobbleDB 是一个分布式键值存储：键是页面标识（经过哈希的 URL），值是页面的处理结果，即预先切好的段落和逐段向量。数据被切成分区分布到多个数据节点上，每个分区有三个副本、落在三台不同节点；一份副本不可用时，其余副本继续服务读请求。
每个节点用 RocksDB 存数据，这是一个适合读密集型负载的开源嵌入式存储引擎，数据经批量摄取写入。命中缓存的数据从内存返回，未命中的读走本地 NVMe 固态盘，这让 Perplexity 可以直接调节内存与磁盘的比例。一个无状态查询路由把键哈希到分区，并行把请求发给节点；路由优先选同可用区的节点，节点用 RocksDB 的批量读接口 MultiGet 一次取多个键。如果某个节点响应慢，系统会转而查询另一个分区副本，改善尾延迟。
设计取舍明确：CobbleDB 不做事务，也不要求副本之间同步。文章称，文档写入后到可被读取之间存在短暂空窗可以接受，不同副本以不同速度摄取数据也没问题；省掉工作负载用不到的功能，能降低系统开销和成本。
写路径拆成三段：Pillar、Lorry 和各自摄取的副本
Pillar 是文档状态与发布层，底层是 YTsaurus。它把页面的各个组成部分（元数据、切块、向量）放在 YTsaurus 的不同表族中，并为切块和向量记录版本，让多种表示可以并存、互不覆盖。由于 Pillar 和 YTsaurus 用便宜的机械硬盘，Perplexity 能存的文档远多于此前放在 DynamoDB 里的量。Pillar 还跟踪按策略划分的页面组，比如新页面或高价值页面；因为 CobbleDB 用的 NVMe 更贵，只有真正需要进入搜索结果的文档才会被导出。页面内容更新、或者页面被加入或移出这些分组时，由 Pillar 排队对应的导出任务；一次原子性的 YTsaurus 事务会同时覆盖状态更新、导出意图与输入记账，事务失败时任何一层都不会留下改动。
Lorry 是一个无状态服务，只做一件事：读持久队列里按分区对齐的导出记录，把它们攒成按分区打包的批次文件，再交给 CobbleDB。投递协议把数据面和控制面分开：Lorry 把批次以唯一标识写进 S3 对象存储，再在 CobbleDB 侧注册这个批次；各分区副本独立向控制面查询下一个要摄取的 S3 批次，并按时间顺序异步应用。慢节点或正在恢复的节点因此可以按自己的节奏追赶，而不会拖慢其他节点。
文章称，这条新路径把处理事务和热存储摄取分开，也为增量更新与全量重建提供了一条可重放的路径；对持久文档状态的更新不会干扰读路径的延迟。
延迟与成本数字：测量方式与边界
迁移完成后，Perplexity 把生产环境的前后测量写进文章：中位（p50）批量读取延迟从 31.4 毫秒降至 5.60 毫秒，p90 从 56.7 毫秒降至 9.77 毫秒，p99 从 123 毫秒降至 24.2 毫秒，读取速度是原来的 5.08～5.80 倍。这些数字来自批量读取：每次请求约 10～15 个键，平均条目约 50 KB；测量时两套系统都在约每秒 20 万次请求的负载下运行，文章还称做过每秒 50 万次请求的压测，没有出现性能退化。
文章自己标注了这组对比的边界：这是观察性的前后测量，两个系统在不同时间服务线上流量，而不是在受控条件下跑同一批请求。Perplexity 还在合成基准上测了两套系统，用 10～15 个键的批次、100 B～100 KiB 的值来近似生产请求。
成本一侧的结论同样出自内部测算。文章称，节省比例基于对存储规模、写容量单元和读容量单元的估算；在所测算的各个承诺档位（commitment tier）上，CobbleDB 都比 DynamoDB 便宜至少 20%，而且由于没有计入压缩可能带来的备份开销节省，实际节省可能更高。
数百个常驻智能体做的事，和工程师保留的决定权
CobbleDB 的核心数据库约有 40,000 行 Rust 代码，迁移还涉及在生产规模上验证正确性与故障行为、把 CobbleDB 接进处理与查询两条路径、安全切换线上流量。给这些工作加速的，是 Perplexity 内部一套运行着大量编程智能体的系统：它跨会话保留项目目标、当前风险、仓库历史和既有决策。
智能体接到的第一个任务是把正在推进的工作摸清：审计项目频道和活跃讨论，把未完成事项关联到各自的 PR（代码合并请求）和负责人，产出一份系统健康与下一步行动的现状报告。此后它们承担的工作包括：
- 评审代码和基础设施变更；
- 找出容易被忽略的阻塞点，比如不安全的恢复假设、过期的构建引用、只在运行时才会失败的配置；
- 准备针对性的修复、测试、监控改动和运维文档；
- 跟踪 CI（持续集成）、评审与基础设施关卡，同时把生产操作明确留给人类；
- 监控上线发布、备份与恢复演练，并把观察到的系统状态与发布成功标准对照；
- 维护项目状态摘要，让工程师看到已经上线了什么、什么仍然卡住、哪些地方还需要人的判断。
工程师仍然设定架构、评审关键变更并授权生产操作，智能体承担的是这些决定之间持续的检查和跟进。文章称，核心 CobbleDB 基础设施由两名工程师和数百个 AI 智能体在两个月内建成，并由此得出结论：强大的 AI 智能体让「自建优于购买」的账更划算。
开源计划：目前只说了「很快」
推文说，计划开源 CobbleDB，供其他构建 AI 搜索的团队使用。文章的说法是计划「很快」开源，并称其他做 AI 原生搜索的团队也能用上这套让 Perplexity 自家搜索更快、更省的存储层。
对打算评估这套存储的团队来说，那组延迟与成本数字要等代码公开后，才能在自家环境里测试。
至于「很快」是多久、以什么许可证发布、代码放在哪里，帖文与文章都没有给出。