pgrust: 使用 LLM 的 Postgres Rust 重写版
pgrust: 使用 LLM 的 Postgres Rust 重写版
pgrust 概述
pgrust 是一个实验性项目,旨在用 Rust 重写 PostgreSQL,并利用大语言模型 (LLMs) 来加速开发过程。该项目旨在实现数据库架构的现代化,同时保持与原始 PostgreSQL 规范的兼容性,目前已通过 100% 的 Postgres 回归测试。
关键架构变更与性能
作者 @malisper 已经对数据库架构实施了几项根本性的变更,以提高相对于原始 C 语言实现的性能:
- 线程模型: pgrust 将 PostgreSQL 使用的传统“每个连接一个进程”模型替换为“每个连接一个线程”模型。
- 事务工作负载: 项目报告称,在事务密集型工作负载下,性能比 PostgreSQL 提高了 50%。
- 分析工作负载: pgrust 声称在分析工作负载上比 PostgreSQL 快约 300 倍,尽管在 Clickbench 基准测试中仍比 Clickhouse 慢约 2 倍。
技术批判与安全担忧
尽管有性能方面的声明,但该项目在生成代码的安全性和质量方面受到了技术社区的显著审查。
使用 Unsafe Rust
审查人员提出的一个主要担忧是 unsafe 代码块的大量使用。对代码库的分析显示,存在 2,664 处 unsafe { 和 1,835 处 unsafe fn,这导致一些批评者认为该项目是一个“大量使用原始指针的 AI 生成转译版”,而不是一个利用 Rust 内存安全保证的重新设计。
可靠性 vs. 测试覆盖率
社区成员强调了通过测试套件与达到生产就绪状态之间的区别。批评者认为,PostgreSQL 的可靠性源于数十年的“现实世界生产环境中的伤痕”,而不仅仅是回归测试。此外,有人指出,标准的 Postgres 回归测试并未专门验证新的线程架构,而这正是潜在故障的关键点。
LLM 在软件重写中的作用
pgrust 的开发引发了关于使用 LLM 进行大规模系统重写的可行性的更广泛辩论。
“AI 重写”范式
观察者注意到,当 LLM 参与其中时,软件开发方式发生了转变:
- 可审查性: 传统的代码审查变得不再切实际。一位审查人员指出,在不到一个月的时间里审查 7,101 个提交 (commits) 对人类来说是不可行的。
- 过度拟合测试: 存在一种风险,即 LLM 可能会使解决方案“过度拟合”测试套件,将测试视为字面上的规范,并通过“猴子补丁 (monkey-patching)”代码来通过特定的数据点,而不是实现预期的通用行为。
- 维护性: 有人认为,由 AI 生成的项目更难维护,因为作者可能还没有获得有机项目增长所具备的严谨性,而未来的贡献者可能被迫使用 AI token 来理解或修改代码。
现代化的潜力
相反,也有人认为,LLM 使将遗留基础设施迁移到现代语言和框架变得更加容易,而这些框架以前由于手动移植过于困难而难以实现。这一观点认为,软件验证的未来将从人类代码审查转向更强大的回归测试套件和“评估 (evals)”。
法律与许可考虑
关于 pgrust 的许可问题正在进行讨论。虽然原始的 PostgreSQL 项目使用 PostgreSQL 许可,但 pgrust 是基于 AGPL-3.0 许可的。这引发了关于基于原始源代码进行重写是否应该受原始许可约束的问题。