스크립트
00:00:00有人用 Rust 重写了 Postgres，而且令人惊讶的是，发布的版本现在可以通过所有 46,000 个 Postgres 回归测试查询。
00:00:08它能与常规 PSQL 配合使用，甚至可以启动现有的 Postgres 18.3 数据目录。
00:00:14这听起来像是生产就绪的替代品，但事实并非如此。
00:00:17但该项目最令人兴奋的版本甚至尚未发布。
00:00:21那么我们看到的到底是什么？这是 Postgres 的未来，还是仅仅是一个人工智能实验？
00:00:30现在，要理解为什么这很重要，你需要了解原本的问题所在。
00:00:36必须承认，Postgres 是有史以来最优秀的数据库之一。
00:00:40但它也承载了近四十年的架构历史和大约一百万行 C 语言代码。
00:00:46每个客户端连接都会获得其自己的后端进程。
00:00:49这种隔离很有用，但也意味着更多的内存开销，更多的使用连接池的压力，
00:00:56以及在并行工作中共享状态的难度更大。
00:01:00PGRust 采取了不同的路径。
00:01:02保持 Postgres 的行为，保持客户端体验，保持磁盘格式，但用 Rust 替换底层的引擎。
00:01:09这不是一个 Postgres 扩展。
00:01:11它也不是在其上添加的某种功能。
00:01:13这是一个完全独立的实现，试图表现得就像 Postgres 一样。
00:01:18我们现在看到了很多用 Rust 重写的项目，就像我们前几天提到的 Bun 用 Rust 重写了整个代码库一样。
00:01:25我会把它放在这里。
00:01:27现在，这一切听起来不错，但它感觉真的是 Postgres 吗？
00:01:31至少测试并不充分。
00:01:32如果你喜欢能加速工作流程的编程工具，请务必订阅。
00:01:36我们会一直发布新视频。
00:01:38现在，我将从官方 Docker 镜像开始，然后用一个完全正常的 PSQL 客户端连接。
00:01:43没有任何定制内容。
00:01:44好了，我进来了。
00:01:46首先，检查一下版本。
00:01:48如你所见，它报告自己是带有最新版本的 PGRust。
00:01:53现在，我可以创建一个表，插入一些数据，并查看查询计划。
00:01:59我直接在我的终端里运行这个。
00:02:01从外部看，这与 Postgres 完全无法区分。
00:02:05相同的客户端，相同的 SQL，相同的输出。
00:02:08你甚至可以看到查询规划器选择了索引扫描，并给我们提供了真实的执行统计信息。
00:02:14现在，为了让它更有趣一点，让我们插入 100,000 行数据并运行另一个查询。
00:02:20这只是随机生成的 10 万行数据。
00:02:23我们要把它放进去。
00:02:25那么，做这一切的意义是什么呢？
00:02:27问得好。
00:02:28好吧，在这个早期的版本发布中，我们不会看到比常规 Postgres 显著的速度提升。
00:02:35更大的性能预期来自于一个尚未发布的开发版本，该版本切换到了每个连接一个线程的模型。
00:02:43这一切确实证明了，这不仅仅是一个部分实现。
00:02:47它通过了完整的官方 Postgres 回归测试套件，超过 46,000 个查询。
00:02:53它使用真实的线路协议，并拥有一个有效的查询规划和存储引擎。
00:02:59这是一个真实的数据库服务器。
00:03:01只是它是用 Rust 编写的。
00:03:03所以，随着进展，我们在速度方面可能会看到一些重大的性能提升。
00:03:08现在问题是，为什么不直接创建另一个 Postgres 扩展呢？
00:03:12因为扩展程序是建立在原始 Postgres 核心之上的。
00:03:16分叉版本可以改变核心，但随后它会继承相同的架构，以及与上游 Postgres 保持同步的持久性工作。
00:03:25你拥有像 CockroachDB 和 YugaByte 这样的数据库，但它们是独立的分布式数据库。
00:03:31完全的即插即用兼容性并不是它们的主要目标。
00:03:35PG Rust 正在尝试别的东西。
00:03:37它以实际的 Postgres 行为作为规范。
00:03:41当前版本以 Postgres 18.3 为目标。
00:03:44它通过了默认的回归套件和隔离测试，并且兼容性足以从现有的 Postgres 18.3 数据目录启动。
00:03:53这里更大的实验发生在另一个未发布的版本中，据报道，该版本将 Postgres 每个连接一个进程的模型替换为每个连接一个线程的模型。
00:04:05在正常的 Postgres 模型中，每个连接获得其自己的进程。
00:04:09使用新模型时，每个连接都在同一个进程内获得一个线程。
00:04:14这可以降低每个连接的开销，并使数据库的不同部分更容易地实际共享信息。
00:04:21但随之而来的，肯定会有权衡，对吧？
00:04:24单独的进程也在连接之间创建了有用的隔离墙。
00:04:28如果一个进程失败，这种分离有助于遏制损害。
00:04:32使用线程时，一个不安全的扩展或内存错误可能会影响更多的服务器。
00:04:38所以，每个连接一个线程并非自动更优。
00:04:41它只是打开了新的大门，但也可能移除了一些安全护栏。
00:04:45接下来是故事的第二个主要部分：人工智能。
00:04:49Michael Malice 和 Jason Siebel 大量使用编码代理来加速重写过程。
00:04:54发布版本在许多地方特意遵循了原始 Postgres 结构。
00:04:59未发布版本才是他们尝试进行更大架构更改的地方。
00:05:03所以，真正的实验不仅仅是：Rust 能让 Postgres 变快吗？
00:05:08更像是：人工智能能否使如此大规模的重写变得负担得起，以至于开发者真的可以重新思考底层的架构？
00:05:16因为人工智能在这里被大量使用。
00:05:19现在，这改变了事情吗？
00:05:20嗯，可能会。
00:05:21这也是我们需要稍微放慢脚步的地方。
00:05:25已发布的版本并没有经过深度优化。
00:05:28主要的性能声明来自未发布的线程连接版本，我们目前无法对其进行完全测试。
00:05:36开发者声称在事务性工作负载上性能提高了大约 50%。
00:05:40他们还声称在分析工作负载上性能约为 Postgres 的 300 倍。
00:05:45这些数字非常惊人，但产生这些结果的代码目前无法进行任何形式的检查或基准测试。
00:05:53因此，目前仍存在很多猜测。
00:05:57看起来这里有大约五五开的意见分歧，至少在网上阅读时，带着这类问题。
00:06:03这些只是 GitHub 上的问题。
00:06:05然后你甚至会看到像这样的一个问题，对吧？
00:06:08这是一个完全合理的问题。
00:06:10当你读到这个问题时，开发者们似乎坚决想要让它真正工作起来。
00:06:15所以，我们暂时还没有真实的统计数据。
00:06:17但这并不自动意味着这些数字是错误的。
00:06:20这只是意味着我们应该将它们视为有希望的声明，而不是确定的事实。
00:06:24老实说，确切的乘数可能并不是最重要的部分。
00:06:28我们不需要在了解一个想法是否真正有效之前，就更改整个 Postgres 项目。
00:06:34这种自由可能比我们能得到的任何单一基准测试更有价值。
00:06:38现在，开发者们对所有这些 Rust 重写（甚至这个 PG Rust）的反应非常强烈。
00:06:44主要的 Hacker News 讨论获得了数百个积分和评论，但同样的，反应非常分裂。
00:06:50双方都提出了很好的观点。
00:06:52首先，通过每个回归查询是一项了不起的成就。
00:06:56很多项目声称与 Postgres 兼容。
00:06:59这个短语可以意味着几乎任何事情。
00:07:01PG Rust 有一个可衡量的目标。
00:07:04真实的 Postgres 测试才是评判它的标准。
00:07:07而且重写的速度表明，编码代理可能会彻底改变大规模基础设施实验的成本。
00:07:13曾经看起来过于昂贵而无法尝试的想法，现在似乎变得越来越可能了。
00:07:19现在，对于另一面，通过回归测试并不等同于赢得生产信任。
00:07:24这些测试无法取代多年的崩溃恢复和复制测试，或者运行数月而不停止的数据库。
00:07:31一个项目可以通过所有已知测试，但仍在没人想到要测试的情况下失败。
00:07:37生成数十万行代码是一项挑战。
00:07:42扩展兼容性是另一个主要差距。
00:07:45现在，你应该用 PG Rust 替换你的生产 Postgres 集群吗？
00:07:49不，绝对不要。
00:07:51该项目本身尚未生产就绪。
00:07:53它是声明过的。
00:07:54它没有完全优化。
00:07:56在主要的兼容性领域，包括扩展生态系统，它们仍然未完成。
00:08:02但你应该尝试一下吗？
00:08:03当然。
00:08:03如果你从事数据库、Rust、查询执行、兼容性测试或人工智能开发工作，为什么不试一试呢？
00:08:10运行 Docker 镜像，测试你的客户端库，阅读源代码，看看会发生什么。
00:08:16所以，把你的看法留在评论区。
00:08:18这个项目将走向何方？
00:08:20我们是否会开始用 Rust 重写更多内容？
00:08:21我们拭目以待。
00:08:23如果你喜欢像这样的编程技巧，请务必订阅 BetterStack 频道。
00:08:26我们下个视频见。