系统与基础设施sqlite.org
SQLite4 的设计
The Design Of SQLite4
2012 — 2022，它一次次回到首页
黑点是上首页（≥ 50 分）的那次投稿，空心点是没冲上去的投稿，点越大分数越高。
导读
这是 SQLite4 的设计文档页面，介绍它改用键值存储模型、默认内置日志结构合并（LSM）存储引擎，支持嵌套事务并把所有内容存在单个磁盘文件中，据称速度快于 LevelDB。页面也涉及与 SQLite3 的差异，例如主键元素必须非空等 SQL 标准约束。评论主要争论它仍缺少真正的 ALTER TABLE/模式迁移支持。
为什么经久不衰：它把 SQLite 从传统 B-tree 关系库转向键值/LSM 架构，并集中呈现了兼容性、模式迁移与存储引擎取舍，所以多年后仍值得回看。
HN 评论精选
批评键值化让完整 ALTER/模式变更更难，认为自动重写数据的迁移也聊胜于无。
加倍押注键值模型让我觉得，一个真正完整可用的 ALTER 命令会比现在更不可能，更不用说这里压根没提这个广受期待的功能。关系模型的一大优势是我们拥有模式；但如果你不能对模式做合理修改、除非把所有数据从头重写，这就严重抵消了那些优势。注意，一个自动重写所有数据的 ALTER 命令虽然性能会很差，也比没有强，因为大家反正都在这么做。
zzzeek查看英文原文
Doubling down on the key/value model gives me the impression that a real and fully functional ALTER command is becoming even more unlikely than it already is, not to mention that this widely desired feature is not even mentioned here. A key advantage to the relational model is that we get to have schemas. But if you can't make reasonable changes to those schemas without explicitly rewriting all your data from scratch, that works pretty hard against those advantages. Note that an ALTER command that rewrites all the data automatically, while it would perform like crap, would be better than none at all. Because that's what everyone is doing anyway.
呼吁支持真正的 ALTER TABLE，避免 ORM 迁移依赖 hack。
请提供真正的表修改功能，这样 ORM 开发者就不必用一个关键性的 hack 来在 SQLite 中实现迁移。
eudox查看英文原文
Actual table alterations please, so ORM developers don't have to use a load-bearing hack to implement migration in SQLite.
对 SQLite3 因兼容性不强制主键 NOT NULL 感到遗憾，并质疑为何会在主键中放 NULL。
SQLite4 要求 PRIMARY KEY 的所有元素都非空。这是 SQL 标准。由于早期版本的一个疏漏，SQLite3 没有对 PRIMARY KEY 列强制执行 NOT NULL 约束；等到发现这个遗漏时，SQLite3 已经使用得太广，启用 NOT NULL 强制会破坏太多程序。我觉得这很悲哀，也想知道那些“太多程序”到底是什么。为什么会有人把 NULL 放进 PRIMARY KEY 呢？
sanxiyn查看英文原文
"SQLite4 requires all elements of the PRIMARY KEY to be non-null. This is an SQL standard. Due to an oversight in early versions, SQLite3 does not enforce the NOT NULL constraint on PRIMARY KEY columns since by the time the omission was discovered SQLite3 was in such widespread use, activation of NOT NULL enforcement would have broken too many programs." I find this sad, and I wonder what those too many programs are. Why would one put NULL on PRIMARY KEY?
关注 SQLite4 默认 LSM 引擎：单文件、支持嵌套事务且据称快于 LevelDB。
“默认内置存储引擎是日志结构合并（LSM）数据库。它非常快，比 LevelDB 还快，支持嵌套事务，并把所有内容存在单个磁盘文件中。未来版本的 SQLite4 可能也会内置 B-Tree 存储引擎。”比 LevelDB 快，还是单文件？有意思。
gojomo查看英文原文
"The default built-in storage engine is a log-structured merge database. It is very fast, faster than LevelDB, supports nested transactions, and stores all content in a single disk file. Future versions of SQLite4 might also include a built-in B-Tree storage engine. " Faster than LevelDB, and in a single file? Interesting.
历次讨论
同类还值得读
TTY 揭秘（2008）
The TTY demystified (2008)
经典文章深入剖析了 Unix/Linux 中 TTY 子系统的工作原理，包括线路规程、终端驱动、信号与控制字符等机制。
系统与基础设施上首页 11 次 · 2009–2025linusakesson.net编辑精选为什么 GNU grep 这么快
Why GNU grep is Fast
FreeBSD 邮件列表上一篇广为流传的帖子，解释 GNU grep 为什么快：核心在于 Boyer-Moore 字符串搜索算法配合精心优化的内部循环和 I/O，让程序在搜索时“…
系统与基础设施上首页 9 次 · 2010–2022lists.freebsd.orgXplain：为普通人讲解 X11
Xplain – Explaining X11 for the rest of us
《Xplain》是作者（HN 用户 Jasper_）写的一系列 X11 长文，用他在浏览器中重建的 X11 绘图模型做交互演示，讲解 X11 的绘图模型与窗口系统设计。
系统与基础设施上首页 6 次 · 2013–2020magcius.github.io编辑精选旋风教程：为 Linux 创建极小 ELF 可执行文件（1999）
A Whirlwind Tutorial on Creating Really Teensy ELF Executables for Linux (1999)
breadbox 写于 1999 年的经典教程，主题是如何为 Linux 手工构造并裁剪出体积极小的 ELF 可执行文件。
系统与基础设施上首页 6 次 · 2007–2025muppetlabs.comPostgreSQL 内部原理
The internals of PostgreSQL
《The Internals of PostgreSQL》是一本免费在线书籍，系统讲解 PostgreSQL 的内部实现，包括查询处理、并发控制、WAL、缓冲区管理等核心机制。
系统与基础设施上首页 5 次 · 2017–2025interdb.jp编辑精选