Perplexity的AI代理协助构建了一个数据库，却不被允许运行它。
内容提要
Perplexity因DynamoDB成本高、读取控制差，自建Rust键值库CobbleDB，两名工程师借助数百编码代理两个月完成。中位批读延迟从31.4毫秒降至5.6毫秒，p99从123毫秒降至24.2毫秒，成本预计低至少20%，未来将开源。代理未接触生产环境，架构仍由工程师掌控。
延伸解读
性能提升的对比局限
文章显示，CobbleDB的中位批读延迟从31.4毫秒降至5.6毫秒，p99从123毫秒降至24.2毫秒。但需注意，这些数据并非来自与DynamoDB的并行对照测试：DynamoDB数据是迁移前记录的，CobbleDB数据是迁移后记录的。因此，性能提升可能受流量模式、数据规模等变化影响，读者不宜将其视为严格的基准对比结果。
成本节省的未计入项
Perplexity预计CobbleDB成本至少比DynamoDB低20%，但该估算未包含维护数据库所需的工程成本。自建数据库意味着需要持续投入人力进行运维、故障排查和功能迭代。文章指出，维护自定义数据存储可能比初期构建更具挑战性。因此，实际总拥有成本可能高于预期，读者应关注长期运维负担。
AI代理的边界与风险
数百个编码代理协助构建了CobbleDB，但它们未接触生产环境，架构仍由两名工程师掌控。CMU教授Andy Pavlo曾警告，数据库是AI代理最难且最重要的挑战，因为涉及生产数据的错误可能难以逆转。Perplexity的做法体现了在利用代理提升效率的同时，将关键决策和运行权限保留给人类，以降低风险。
Q&A
Perplexity 为什么要自研 CobbleDB 数据库？
Perplexity 认为 DynamoDB 成本过高，且无法获得所需的读取性能控制权，因此决定自建数据库。
CobbleDB 在延迟和成本上相比 DynamoDB 有哪些提升？
中位批读延迟从 31.4 毫秒降至 5.6 毫秒，p99 从 123 毫秒降至 24.2 毫秒；成本预计至少低 20%。
CobbleDB 的存储架构是如何设计的？
存储栈分为三部分：Pillar 在 YTsaurus 上持久化文档状态，Lorry 通过 S3 将更新批量移至 CobbleDB，每个分区有三个副本，使用哈希 URL 作为键，RocksDB 缓存热点数据，其余存于本地 NVMe。
AI 代理在 CobbleDB 开发中扮演了什么角色？
数百个持久编码代理协助开发，跨会话携带上下文，帮助发现恢复假设和运行时配置问题，但未接触生产环境，架构和生产系统仍由两名工程师掌控。
CobbleDB 的性能测试结果有哪些注意事项？
DynamoDB 和 CobbleDB 并非在相同流量下并排测试，DynamoDB 数据来自切换前，CobbleDB 来自切换后；成本估算未包含维护数据库的工程成本。
CobbleDB 未来有什么计划？
Perplexity 计划在某个时候开源 CobbleDB。
