Perplexity 两名工程师自建 CobbleDB，将延迟降至原来的五分之一，取代亚马逊系统

Perplexity 工程团队于 9 月 14 日发表技术文章，介绍了如何用约 4 万行 Rust 代码构建的自研键值存储系统 CobbleDB 取代 Amazon DynamoDB；迁移后，批量读取延迟中位数从 31.4 毫秒降至 5.60 毫秒，p99 延迟从 123 毫秒降至 24.2 毫秒。

CobbleDB 的性能数据：延迟降低五至六倍、成本节省 20% 的测量条件

根据 Perplexity 技术文章公布的数据，迁移前后的性能对比如下：延迟中位数从 31.4 毫秒降至 5.60 毫秒（降低 5.6 倍），p90 从 56.7 毫秒降至 9.77 毫秒（降低 5.8 倍），p99 从 123 毫秒降至 24.2 毫秒（降低 5.1 倍），整体改善幅度介于 5.08 倍至 5.80 倍之间。测量条件为每次查询约包含 10 至 15 个键，平均项目大小为 50 KB，吞吐量约为每秒 20 万次请求；此外，他们还进行了每秒 50 万次请求的负载测试，未发现性能劣化。

Perplexity 在文章中明确说明，这是一项观察性的前后对照：两套系统在不同时间段服务实际生产流量，而不是在受控条件下处理相同请求。他们还通过合成基准测试对两者进行了测量。成本方面的 20% 改善同样基于内部对存储大小、写入容量单位和读取容量单位的估算。

离开 DynamoDB 的三大原因：计费模式、调优空间与管线耦合

Perplexity 在技术文章中列出了推动迁移的三个核心限制：

计费方式：DynamoDB 按读写的每个字节计费；Perplexity 的单次搜索 API 请求包含 100 至 120 个页面键，读取时会拆分为包含 10 至 20 个键的小批次，平均每个项目约为 50 KB，反复读取会消耗大量容量；持续爬取数据以及更换切块方式或嵌入模型，又会产生大量额外写入。

调优空间：Perplexity 所需的操作范围很窄——接收一批页面标识符，并快速返回准备好的内容——但他们仍需要控制哪台机器持有分区、为缓存分配多少内存，以及由哪个副本处理请求；而这些都无法通过 DynamoDB 的托管服务 API 进行调整。

管线耦合：旧管线会将每个处理完的页面直接写入 DynamoDB，一次大规模重新处理就会变成一连串单独的热存储更新，导致无法在一两天内对整个数据库运行 MapReduce，以尝试新的切块方式或更换嵌入模型。

新架构的三层设计：Pillar、Lorry 与 CobbleDB 的责任分工

新架构将职责分为三个组件。Pillar 维护持久化的文档状态，并决定发布哪些内容；底层使用 YTsaurus 搭配廉价硬盘存储，因此能够存储比 DynamoDB 时代更多的文档。它会跟踪切块和嵌入版本，让多种表示形式能够并存而不会相互覆盖。Lorry 是无状态服务，负责将 Pillar 的导出数据转换为按分区对齐的批次文件。

CobbleDB 专门负责查询时的读取操作，是一种分布式键值存储：键为经过哈希处理的网址，值为预先切分的段落及每个段落的向量嵌入。数据被分区并分布在各个数据节点上，每个分区拥有三个副本；节点使用 RocksDB 存储数据，热数据通过内存缓存提供服务，未命中缓存的数据则从本地 NVMe 读取。无状态的查询路由器会并行发出请求，并优先选择同一可用区内的节点；如果某个节点响应缓慢，则改为查询另一个副本。

Perplexity 特别说明，他们刻意不支持热存储事务和同步副本，去掉不需要的功能，以降低系统负担和成本。

两名工程师加数百个 AI 代理：两个月完成核心基础设施的开发模式

Perplexity 的技术文章描述了一个高度持久化的内部代理系统，其设计目标是跨越不同工作阶段保留项目目标、当前风险、代码库历史和此前的决策。代理接到的第一项任务，是建立对现有进行中工作的准确模型：审查项目频道和活跃讨论串，将待办事项关联到相应的拉取请求和负责人，并生成反映系统健康状况及后续行动的现状报告。

之后，代理会参与工程循环的多个环节，包括审查代码和基础设施变更，指出容易被忽略的阻碍（不安全的还原假设、过时的构建引用，以及只有在运行阶段才会失败的配置），准备修复方案并执行测试，跟踪持续集成网关，以及监控发布和备份还原演练。

分工边界十分明确：架构由工程师决定，具有重大后果的变更由工程师审查，生产环境操作则必须获得人类明确授权；代理负责的是这些决策之间的持续检查和后续跟进。链新闻此前曾报道，OpenAI 三天前也通过两名工程师加 Codex 完成了一次系统迁移，这是三天内第二起相同形式的案例。

常见问题 Perplexity CobbleDB 与 Amazon DynamoDB 相比，延迟改善幅度是多少？

根据 Perplexity 于 2026 年 9 月 14 日发布的技术文章，CobbleDB 的批量读取延迟中位数从 31.4 毫秒降至 5.60 毫秒（降低 5.6 倍），p90 从 56.7 毫秒降至 9.77 毫秒（降低 5.8 倍），p99 从 123 毫秒降至 24.2 毫秒（降低 5.1 倍）；测量条件为每次查询约包含 10 至 15 个键，平均项目大小为 50 KB，每秒 20 万次请求；此外还进行了每秒 50 万次请求的负载测试。

CobbleDB 的核心技术由多少人用多长时间完成？

根据 Perplexity 的技术文章，CobbleDB 的核心基础设施由两名人类工程师和数百个 AI 代理在两个月内建成，代码量约为 4 万行 Rust；Perplexity 计划不久后将 CobbleDB 开源。

Perplexity 为什么选择离开 DynamoDB？

根据技术文章，主要有三大原因：按字节计费的模式在 Perplexity 的高频读写场景下成本较高；DynamoDB 无法调整分区所在的机器、内存缓存分配和副本选择；旧管线的耦合问题使大规模 MapReduce 作业以及新嵌入模型的试用难以执行。

免责声明：以上内容(如有图片或视频亦包括在内)均为平台用户上传并发布，本平台仅提供信息存储服务，对本页面内容所引致的错误、不确或遗漏，概不负任何法律责任，相关信息仅供参考。

本站尊重他人的知识产权、名誉权等法律法规所规定的合法权益!如网页中刊载的文章或图片涉及侵权，请提供相关的权利证明和身份证明发送邮件到909075378@qq.com，本站相关工作人员将会进行核查处理回复