数据库不应只是操作系统上的一个进程

Mon, 18 May 2026 14:51:04 +0800

数据库不应只是操作系统上的一个进程

是时候重新审视数据库与操作系统的边界了

长期以来，“数据库运行在操作系统之上”几乎是一个不需要解释的默认设定。操作系统负责进程、线程、文件系统、网络、内存和设备管理；数据库负责查询、事务、索引、缓存、并发控制和恢复。这个分工清晰、稳定，也支撑了过去几十年的数据库工程实践。

但这个默认设定正在变得越来越值得讨论。

问题并不在于 Linux 不好，也不在于 PostgreSQL、MySQL、RocksDB 这类系统不够优秀。真正的问题是：通用操作系统和现代数据库系统的优化目标正在出现分叉。

操作系统强调通用性、隔离性、兼容性、可维护性和公平调度；数据库则越来越关注低尾延迟、可预测执行、事务一致性、直接 I/O 路径，以及对硬件行为的精细控制。二者都在进步，但它们的目标函数并不完全一致。

如果数据库只是一个普通应用，运行在操作系统之上当然合理。但现代数据库早已不是普通应用。它自己管理缓存，自己管理并发，自己设计日志和恢复，自己实现调度和资源控制，在很多关键路径上甚至还要绕过操作系统提供的默认机制。

到了这个阶段，我们至少应该重新问一句：

继续把数据库作为一个普通用户态程序运行在通用操作系统之上，仍然是最合适的系统结构吗？

1. 数据库从来没有完全信任操作系统抽象

从工程实现看，数据库和操作系统之间一直有一种微妙关系：数据库使用操作系统，但并不完全依赖操作系统。

数据库通常不会简单地把内存管理交给操作系统 page cache，而是自己实现 buffer pool。数据库不会只依赖操作系统的文件写入语义，而是自己实现 WAL、checkpoint、group commit 和崩溃恢复。数据库也不会把并发控制交给操作系统锁，而是自己实现 latch、lock manager、MVCC 和事务调度。

这不是数据库工程师喜欢重复造轮子，而是因为操作系统提供的是通用抽象，而数据库需要的是更强的语义约束和更可预测的执行行为。

操作系统看到的是线程、文件、页、socket 和 block device。数据库看到的是事务、日志、脏页、索引、锁等待、查询计划和恢复点。二者面对的是同一台机器，但理解系统状态的方式并不一样。

这种差异过去也存在，只是没有现在这么尖锐。硬件慢、并发低、系统规模小的时候，多一层抽象、多几次上下文切换、多一点调度不确定性，未必会成为决定性问题。但在多核、NVMe、RDMA、云存储和低延迟在线服务成为常态之后，这些抽象差异会被迅速放大，最终变成性能问题、稳定性问题，甚至可靠性问题。

2. Linux 调度变化影响 PostgreSQL：问题不只是一次性能回退

Phoronix 报道过一个很典型的案例：AWS 工程师在 Linux 7.0 开发周期中发现，PostgreSQL 在 Graviton4 机器上的性能出现明显下降，吞吐量大约只有此前内核版本的一半。相关分析认为，问题与 Linux 抢占模型变化有关，PostgreSQL 在用户态 spinlock 上花费了更多时间。

参考链接：

https://www.phoronix.com/news/Linux-7.0-AWS-PostgreSQL-Drop

这个案例值得关注，并不只是因为“性能下降了一半”这个数字醒目，而是因为它暴露了数据库和操作系统之间一种长期存在的隐含依赖。

PostgreSQL 的不少关键路径依赖用户态锁和短临界区。理想情况下，锁持有者会很快完成工作并释放锁，其他线程只需要短暂等待。但如果操作系统在不合适的时机抢占了锁持有者，等待者就可能在用户态空转。单次等待看起来很小，放到高并发事务系统中，就可能被放大成吞吐下降和尾延迟恶化。

从操作系统角度看，调整抢占模型可能有充分理由。内核要面对的是各种不同类型的负载，它需要维护通用性、公平性和长期可维护性。

但从数据库角度看，这种变化可能破坏多年调优出来的并发行为。数据库以为自己控制了锁和调度，实际上仍然依赖内核调度器的具体行为。内核并不理解这些用户态锁背后的事务语义，也不会承诺永远维持一种对数据库友好的时序。

所以这个案例真正值得讨论的地方在于：

数据库的性能关键路径建立在操作系统调度语义之上，而这些语义并不是为数据库事务处理专门设计的。

这不只是某个内核版本的偶然问题。只要数据库仍然作为普通进程运行在通用操作系统上，它就必须持续适配外部调度策略的变化。

3. fsync 事件说明：文件接口和事务持久化之间存在语义裂缝

性能问题已经足够麻烦，可靠性问题更复杂。PostgreSQL 的 fsync failure 事件就是一个典型例子。

简历

Sat, 10 May 2025 17:45:07 +0800

郭华 / Hua Guo

计算机软件与理论博士，现为华东师范大学博士后。主要研究方向包括云原生数据库、分布式系统、形式化方法在系统软件中的应用、云环境零信任安全以及 AI 辅助软件工程。曾参与列存储数据库、大数据分析平台、地图基础数据平台等工程系统研发，当前重点开展新型数据库管理与应用执行一体化系统研究。

教育经历

中国人民大学，计算机软件与理论，博士，2019.9 – 2024.12
中国人民大学，计算机软件与理论，硕士，2016.9 – 2019.6
海南大学，计算机科学与技术，学士，2007.9 – 2011.6

工作经历

华东师范大学，博士后研究人员

2024.3 – 至今

围绕云原生数据库、数据密集型应用执行、系统软件验证与 AI 辅助软件工程等方向开展研究工作，重点关注数据库系统架构、分布式事务处理、形式化验证方法与系统工程实践的结合。

开珀卡珀（scuptio），创始人

2023.1 – 至今

负责MuduDB数据库系统、系统软件质量保障相关项目的设计与研发，主要项目包括：

MuduDB：面向数据密集型应用的新型数据库系统，目标是让应用逻辑能够直接运行和部署在数据库之上。
sedeve-kit：形式化验证与测试工具，面向数据库系统的规范建模、测试生成与行为验证。
零信任系统：面向云环境与分布式系统的零信任安全机制研究与原型开发。

百度地图

2014.7 – 2015.7

参与百度地图基础数据平台相关研发工作，主要涉及地图基础数据处理、平台化支撑与数据服务能力建设。

东方国信

2012.5 – 2014.7

参与列存储数据库系统与大数据分析系统研发，主要关注数据存储、查询处理与分析型系统工程实现。

目标在线

2011.8 – 2012.5

从事游戏开发相关工作，参与在线游戏系统的功能开发与工程实现。

研究方向

云原生数据库系统：数据库系统架构、事务处理、数据密集型应用执行、云环境数据库基础设施。
分布式系统：共识协议、容错机制、分布式事务、系统一致性与可靠性。
形式化方法与系统软件验证：TLA+ 规范建模、规范驱动开发、数据库与分布式系统正确性验证。
云上零信任安全：云环境访问控制、身份认证、最小权限与系统安全边界设计。
AI 辅助软件工程：大模型辅助需求分析、规范生成、代码生成、测试生成与工程流程自动化。

代表性论文与会议

学术论文

Hua Guo, Yunhong Ji, Huiqi Hu, Xuan Zhou. A Composable Architecture for Cloud Transactional DBMS. APWeb/WAIM (3), 2024: 428–443.

数据库 on 欢迎来到我的空间

数据库不应只是操作系统上的一个进程

数据库不应只是操作系统上的一个进程

是时候重新审视数据库与操作系统的边界了

1. 数据库从来没有完全信任操作系统抽象

2. Linux 调度变化影响 PostgreSQL：问题不只是一次性能回退

3. fsync 事件说明：文件接口和事务持久化之间存在语义裂缝

简历

郭华 / Hua Guo

教育经历

工作经历

华东师范大学，博士后研究人员

开珀卡珀（scuptio），创始人

百度地图

东方国信

目标在线

研究方向

代表性论文与会议

学术论文