系统与数据库2022vldb.org编辑精选
SQLite：过去、现在与未来
SQLite: Past, Present, and Future
进阶 · 约 40 分钟读完前置知识：数据库基础（B-Tree 索引）、查询执行与查询优化基础、嵌入式/低内存系统概念
导读
这篇 VLDB 论文梳理 SQLite 的历史、当前架构与性能表现，并展望未来方向。文中讨论了 SQLite 在嵌入式/低内存场景下的设计取舍，例如用 B-Tree 临时索引而非哈希表处理哈希连接，以及为大型分析查询引入 Bloom filter 等查询计划器优化。
HN 关注点：这篇综述对 SQLite 设计取舍（如无哈希表、用 B-Tree）和面向分析查询的 Bloom filter 优化的解释，以及它引发的 SQLite 与 DuckDB 对比讨论。
HN 评论精选
这几条评论里：补充 3
补充提供论文速读笔记，降低阅读门槛。
我在博客上分享了关于这篇论文的笔记，因为我猜很多人并没有足够投入去读完整篇论文：https://simonwillison.net/2022/Sep/1/sqlite-duckdb-paper/
simonw查看英文原文
I shared some notes on this on my blog, because I'm guessing a lot of people aren't quite invested enough to read through the whole paper: https://simonwillison.net/2022/Sep/1/sqlite-duckdb-paper/
补充指出 SQLite 用 B-Tree 临时索引替代哈希表是嵌入式场景的取舍，并关联 Bloom filter 优化与 3.38.0 查询计划器增强。
关于哈希连接，SQLite 文档说明它没有真正的哈希表：SQLite 会构造临时索引而非哈希表，因为它已有高性能的 B-Tree，额外加哈希表会增加面向低内存嵌入式设备的库体积且收益很小。论文还提到为分析查询实现 Bloom filter；我好奇这是否与 SQLite 3.38.0 的查询计划器增强（用 Bloom filter 加速大型分析查询）有关。
polyrand查看英文原文
Regarding hash joins, the SQLite documentation mentions the absence of real hash tables [0] SQLite constructs a transient index instead of a hash table in this instance because it already has a robust and high performance B-Tree implementation at hand, whereas a hash-table would need to be added. Adding a separate hash table implementation to handle this one case would increase the size of the library (which is designed for use on low-memory embedded devices) for minimal performance gain. It's already linked in the paper, but here's the link to the code used in the paper [1] The paper mentions implementing Bloom filters for analytical queries an explains how they're used. I wonder if this is related to the query planner enhancements that landed on SQLite 3.38.0 [2] Use a Bloom filter to speed up large analytic queries. [0]: https://www.sqlite.org/optoverview.html#hash_joins [1]: https://github.com/UWHustle/sqlite-past-present-future [2]: https://www.sqlite.org/releaselog/3_38_0.html
补充提供论文 PDF 直链。
PDF：https://www.vldb.org/pvldb/vol15/p3535-gaffney.pdf
dang查看英文原文
The pdf: https://www.vldb.org/pvldb/vol15/p3535-gaffney.pdf
相关资源
从这篇论文所有 HN 讨论帖的全部评论里整理出来的链接。
历次讨论
- 2022Hacker News 讨论帖282 分 · 86 评
同领域还值得读
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 分钟编辑精选