系统与数据库2022db.cs.cmu.edu编辑精选
你确定要在数据库管理系统中使用 MMAP 吗？
Are you sure you want to use MMAP in your database management system?
进阶 · 约 35 分钟读完前置知识：数据库缓冲池管理、操作系统虚拟内存与页缓存、文件 I/O 基础
导读
这篇 CIDR 2022 论文探讨数据库管理系统是否应该使用 mmap（内存映射文件）。作者通过基准测试和系统分析指出，mmap 虽然看似简化了缓冲区管理，却让 DBMS 失去了对页面缓存、替换策略和 I/O 调度的控制，从而带来性能问题，因此建议数据库开发者谨慎使用，或自行实现缓冲区管理。
HN 关注点：这个话题，因为 mmap 是系统编程中常被当作简化利器的抽象，而论文论证它在数据库场景下弊大于利；讨论焦点集中在替代 mmap 的工程难度和实践经验上。
后来怎么样
该论文成为数据库社区讨论是否使用 mmap 时的重要参考，强化了“DBMS 应显式控制缓冲池与 I/O”的实践共识，并引发 RavenDB 等系统开发者的公开回应。
HN 评论精选
这几条评论里：支持 1 补充 3
补充替代 mmap 虽可能更优，但学习曲线陡峭、关键设计细节缺乏文献，早期尝试往往糟糕；LRU 和许多学术缓存方案在真实系统中都有问题。
决定用 mmap() 的务实考量，通常是替代它所需的技能存在巨大断层。自己写替代方案在性能和功能上可能明显更优，架构也更干净，但前提是设计足够精巧。学习曲线很陡，现成文献很少探讨关键细节，缺少可依赖的操作指南。因此早期替代尝试往往很糟糕——你不知道自己不知道什么，而那些常被忽略的实现细节在实践中至关重要。比如大多数人最终会发现 LRU 缓存替换是个坏主意，但许多学术替代方案在真实系统中会导致 CPU 缓存抖动，只是用一个问题换另一个问题。有些巧妙且不明显的设计元素能大大缓解这一点，但在大多数讨论中它们被视为实现细节，第一次写的人很难发现。虽然 mmap() 对数据库来说是平庸的工具，但我们也必须认识到，对大多数工程师来说称职地替代它并非易事。
jandrewrogers查看英文原文
The pragmatic consideration that usually influences the decision to use mmap() is the large discontinuity in skill and expertise required to replace it. Writing your own alternative to mmap() can be significantly superior in terms of performance and functionality, and often lends itself to a cleaner database architecture. However, this presumes a sufficiently sophisticated design for an mmap() replacement. The learning curve is steep and the critical nuances of sophisticated and practical designs are poorly explored in readily available literature, providing little in the way of "how-to" guides that you can lean on. As a consequence, early attempts to replace mmap() are often quite poor. You don't know what you don't know, and details of the implementation that are often glossed over turn out to be critical in practice. For example, most people eventually figure out that LRU cache replacement is a bad idea, but many of the academic alternatives cause CPU cache thrashing in real systems, replacing one problem with another. There are clever and non-obvious design elements that can greatly mitigate this but they are treated as implementation details in most discussions of cache replacement and largely not discoverable if you are writing one for the first time. While mmap() is a mediocre facility for a database, I think we also have to be cognizant that replacing it competently is not a trivial ask for most software engineers. If their learning curve is anything like mine, I went from mmap() to designing obvious alternatives with many poorly handled edge cases, and eventually figuring out how to design non-obvious alternatives that could smoothly handled very diverse workloads. That period of "poor alternatives" in the middle doesn't produce great databases but it almost feels necessary to properly grok the design problem. Most people would rather spend their time working on other parts of a database.
支持与 Tanenbaum 的 "RPC Considered Harmful" 类比：抽象掩盖了重要复杂性，并让人失去控制。
这项工作与 Tanenbaum 的《RPC Considered Harmful》有有趣的相似之处；两者都是用一个抽象掩盖了大量复杂性，最终却反噬你，因为很多复杂性其实相当重要，而抽象让你失去了对它的控制。
tptacek查看英文原文
Interesting parallels in this work to Tanenbaum's "RPC Considered Harmful"†; in both cases, you've got an abstraction that papers over a huge amount of complexity, and it ends up burning you because a lot of that complexity turns out to be pretty important and the abstraction has cost you control over it. † https://www.cs.vu.nl/~ast/Publications/Papers/euteco-1988.pdf
补充指出 RavenDB 官方博客对此论文有回应/反驳。
RavenDB 对这篇论文的回应：https://ayende.com/blog/196161-C/re-are-you-sure-you-want-to-use-mmap-in-your-database-management-system
assface查看英文原文
RavenDB's response to this paper: https://ayende.com/blog/196161-C/re-are-you-sure-you-want-to-use-mmap-in-your-database-management-system
补充补充了论文摘要页、讲解视频和基准测试代码链接。
链接已从 https://db.cs.cmu.edu/mmap-cidr2022/ 更改，该页面有摘要和视频链接：https://www.youtube.com/watch?v=1BRGU_AS25c，以及代码：https://github.com/viktorleis/mmapbench
dang查看英文原文
Url changed from https://db.cs.cmu.edu/mmap-cidr2022/, which has the abstract and a link to this video: https://www.youtube.com/watch?v=1BRGU_AS25c and this code: https://github.com/viktorleis/mmapbench
相关资源
从这篇论文所有 HN 讨论帖的全部评论里整理出来的链接。
历次讨论
- 2022Hacker News 讨论帖162 分 · 127 评
同领域还值得读
I/O 比 CPU 更快——让我们划分资源并消除操作系统抽象
I/O Is Faster Than CPU – Let’s Partition Resources and Eliminate OS Abstractions
指出在现代服务器硬件上 I/O 速度已接近甚至超过 CPU，传统操作系统抽象反而成为瓶颈。
系统与数据库2019 · 817 分 · 277 评进阶 · 约 30 分钟编辑精选使用 io_uring 的高效 I/O
Efficient IO with io_uring
由 Linux 内核开发者 Jens Axboe 撰写，介绍 Linux 新的异步 I/O 接口 io_uring。
系统与数据库2019 · 426 分 · 96 评进阶 · 约 45 分钟编辑精选线程对大多数用途而言是个坏主意（1995）
Threads Are a Bad Idea for Most Purposes (1995)
这篇 1995 年的文章由 John Ousterhout 撰写，讨论为什么线程对大多数用途而言是坏主意，并主张事件驱动编程通常更简单、更高效。
系统与数据库2017 · 423 分 · 382 评进阶 · 约 25 分钟编辑精选学习型索引结构之论证
The Case for Learned Index Structures
提出把索引看作一种"模型"：既然 B-tree 等结构本质上是在学习数据的分布，就可以用机器学习模型（如回归模型、神经网络）来近似键到位置的映射，从而替代 B-tree、哈希索引…
系统与数据库2017 · 398 分 · 66 评 · 引用 25进阶 · 约 60 分钟编辑精选FoundationDB：一个分布式、解耦的事务型键值存储
FoundationDB: A distributed, unbundled, transactional key value store
介绍 FoundationDB：一个分布式、解耦设计的事务性键值存储。
系统与数据库2021 · 283 分 · 99 评进阶 · 约 90 分钟编辑精选