pgrust 事务性能为何快 50%深入分析并发模型与优化【免费下载链接】pgrustPostgres rewritten in Rust, now faster than Postgres and Clickhouse项目地址: https://gitcode.com/GitHub_Trending/pg/pgrustpgrust 是一个用 Rust 重写 Postgres 的开源数据库项目最新版本在事务负载上比原生 Postgres 快 50%在分析型负载上更是快了约 300 倍。本文将从 pgrust 的并发模型入手深入拆解线程替代进程的核心架构改造以及事务提交路径上的关键优化帮你理解这 50% 的性能提升究竟从何而来。pgrust 是什么一个 Rust 重写的 Postgres简单来说pgrust 把 PostgreSQL 18.3 的内核用 Rust 重新实现了一遍目标是行为保持 Postgres 形状、性能远超原生。它最了不起的地方在于兼容性磁盘格式与 Postgres 完全兼容可以直接从一个现有的 Postgres 18.3 数据目录启动通过超过 46,000 条 Postgres 官方回归测试查询依然使用真实的 Postgres 测试作为裁判确保行为不出偏差这意味着一句话你的 SQL、数据文件、工具链不用变底层引擎却换成了一个更快的 Rust 实现。Postgres 的传统并发模型每连接一个进程要理解 pgrust 快在哪先得看原生 Postgres 的架构。传统 Postgres 采用的是**每连接一个进程process per connection**模型每个客户端连接到来时postmaster 通过fork()复制出一个独立进程每个连接进程有自己独立的内存空间、独立的页缓存视图进程之间通过共享内存shared memory交换全局状态这套模型非常稳健但代价也很明显对比项进程模型线程模型内存开销每个进程独立地址空间开销大线程共享地址空间开销小连接建立成本fork 复制页表、文件描述符成本高创建线程轻量得多上下文切换内核级切换成本高更轻量缓存共享进程间不能直接共享热数据天然共享并发度连接数越多进程数越多可支撑更高并发在 pgrust 的代码中你还能看到传统fork()路径的忠实移植——fork_process.rs 完整保留了信号屏蔽、OOM 调整等细节这正说明了旧模型的历史包袱有多重。pgrust 的杀手锏每连接一个线程pgrust 新版的核心架构决策就是把进程模型换成线程模型thread per connection。这个改动听起来只是进程变线程实际上牵一发动全身1. 连接成本断崖式下降创建线程远比 fork 进程便宜。在高并发连接场景下Postgres 大量时间花在 fork 子进程、初始化独立内存上而 pgrust 的线程创建开销几乎可以忽略。连接不再昂贵意味着可以轻松支撑成千上万的并发会话。2. 线程本地状态thread_local!取代全局变量Postgres 的 C 代码里到处是文件级静态全局变量如MyProc、CurrentTransactionState这在多线程下是灾难。pgrust 用 Rust 的thread_local!机制把一个后端 一个线程的状态隔离做得干净利落。在事务核心 transam_xact/src/lib.rs 中事务状态栈XactState、子事务 ID 列表等都放进thread_local!每个线程各有一份既不需要加锁也不会互相干扰——这在 C 语言里几乎不可能安全地做到。3. 共享内存的读写效率大幅提升进程模型下Postgres 的全局状态如事务 ID 分配器TransamVariables必须放在共享内存里每次访问都要经过系统调用级的映射。pgrust 的线程模型下这些状态可以更自然地共享。以事务 ID 分配为例varsup/src/lib.rs 依然保留 LWLock如XidGenLock做跨线程序列化但线程间的通信成本远低于进程间通信。更重要的是线程共享的页缓存让热数据命中率更高——一个连接读过的数据页另一个连接可以直接复用这在进程模型下是做不到的。事务提交路径的优化WAL 不再是瓶颈事务性能的核心在提交路径。每一次 COMMIT 都要写 WAL预写日志这是所有数据库最昂贵的操作之一。pgrust 在 transam_xact/src/wal.rs 中重写了提交/中止记录的构建逻辑用 Rust 的Vec和安全的序列化替代 C 的手工缓冲区管理减少内存拷贝资源所有者ResourceOwner机制被 RAII 取代提交时的资源释放路径更短内存上下文MemoryContext的切换样板代码被消除事务生命周期管理更直接再加上线程模型带来的组提交group commit效率提升——多个线程的提交可以更高效地合并成一批 WAL 写入磁盘 fsync 的次数更少。这就是事务负载快 50% 的主要来源。分析负载快 300 倍不止是并发模型的功劳pgrust 在 ClickBench 基准上分析型查询比 Postgres 快约 300 倍比 ClickHouse 只慢 2 倍官方认为还有望反超。这部分性能来自多线程并行执行线程模型让查询并行化parallel query的成本大大降低多核利用率远高于进程模型更少的锁竞争线程共享地址空间后很多原本需要跨进程的同步可以直接用轻量级原子操作Rust 的零成本抽象编译器优化 无 GC内存分配和回收路径更可预测兼容性与未来46,000 条回归测试的底气性能再快兼容性不行也没用。pgrust 的做法是把 Postgres 官方回归测试套件作为唯一真相与 Postgres 18.3 的预期输出完全匹配超过 46,000 条查询磁盘兼容意味着迁移成本极低initdb出来的数据目录pgrust 直接就能启动项目路线图包括内置连接池、无 VACUUM 的存储实验、针对 AI 生成 SQL 的运行时护栏等这些目标README.md 中的 Roadmap都建立在多线程内核的基础上而线程模型正是这一切的前提。如何快速体验 pgrust想亲眼看看这个更快的 Postgres最简单的途径是用 Dockerdocker run -d --name pgrust -e POSTGRES_PASSWORDsecret malisper/pgrust:v0.1启动后直接psql连上去你的 Postgres 客户端、工具链全都照常使用背后却是 Rust 引擎在高速运转。总结pgrust 的 50% 从何而来回到标题的问题pgrust 事务性能快 50% 的核心答案就三点并发模型革命每连接一线程替代每连接一进程连接成本、上下文切换、内存开销全面下降Rust 语言红利thread_local!安全隔离后端状态RAII 取代手工资源管理编译期就消灭了一整类并发 bug提交路径瘦身WAL 写入、资源释放、内存管理全部精简配合线程模型下的高效组提交对于追求高并发、低延迟的团队来说pgrust 展示了一条极具吸引力的路径保留 Postgres 的全部兼容性却拿到接近专用数据库的性能。虽然不是生产就绪版本但它已经证明了Postgres 内核 Rust 重写 线程模型这个组合的巨大潜力。想深入了解代码细节可以直接阅读 transam_xact 和 varsup 这两个核心模块感受 Rust 版事务引擎的设计之美。【免费下载链接】pgrustPostgres rewritten in Rust, now faster than Postgres and Clickhouse项目地址: https://gitcode.com/GitHub_Trending/pg/pgrust创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考