系统与基础设施sqlite.org
SQLite 存储小对象：比文件系统快 35%
SQLite small blob storage: 35% Faster Than the Filesystem
2017 — 2024，它一次次回到首页
黑点是上首页（≥ 50 分）的那次投稿，空心点是没冲上去的投稿，点越大分数越高。
导读
这是 SQLite 官方的一篇性能说明，比较把大量小 blob 存入 SQLite 数据库与把它们作为独立文件写入文件系统的读写表现。页面结论是小对象场景下 SQLite 往往不逊于甚至快于文件系统（标题称快 35%），但评论也指出基准条件和适用范围需要谨慎看待。
为什么经久不衰：小文件/小对象该放数据库还是文件系统是长期存在的工程问题；这篇官方基准提供了具体数据点，且多年讨论沉淀出适用边界和实际案例。
HN 评论精选
引用 Jim Gray 研究：小于 256KB 数据库占优，但 SSD 改变条件；blob 有事务/恢复一致性优势，但图片上传等实际场景仍常用文件系统，因存储和运维成本。
我必须指出 Jim Gray 的论文《To Blob or Not To Blob》。他的团队比较的是 NTFS 与 SQL Server，但大部分理由适用于任何文件系统与数据库的取舍。摘要结论是：如果对象平均大于 1MB，NTFS 相对 SQL Server 有明显优势；如果对象小于 256KB，数据库有明显优势；介于两者之间则取决于写负载有多密集。但要注意这是 2006 年的旋转磁盘。现代 SSD 很大程度上改变了这个等式，因为 SSD 对随机 IO 友好得多，也更少从数据库的预写日志和缓冲池行为中获益。另外，在 blob 与文件系统之间选择时，blob 带来事务和恢复一致性：数据库自包含，所有 blob 都在其中；在不同系统上恢复数据库会得到一致系统，不会留下指向缺失文件的链接，也不会有孤儿文件。尽管如此，我的实践经验是，对于上传内容、图片、PNG/JPEG 之类，文件系统比 blob 更好。Blob 增加额外开销，需要更大的数据库存储（通常更贵，比如 AWS RDS），体积增大会连锁带来运维开销（更大的备份、更慢的恢复等）。
rusanu查看英文原文
I must point out Jim Gray's paper To Blob or Not To Blob[0]. His team considered NTFS vs. SQL Server, but most rationale applies to any filesystem vs. database decision. The summary was "The study indicates that if objects are larger than one megabyte on average, NTFS has a clear advantage over SQL Server. If the objects are under 256 kilobytes, the database has a clear advantage. Inside this range, it depends on how write intensive the workload is," but keep in mind this is spinning media from 2006. Modern SSDs change the equation quite a bit, as they are much more friendly to random IO and benefit less from database write-ahead log and buffer pool behavior. Also, when deciding between blob vs. filesystem, blobs bring transactional and recovery consistency. The DB is self contained, and all blobs are contained in it. A restore of the DB on a different system yields a consistent system, it won't have links to missing files, and there won't be orphaned files left over (files not referenced by records in DB). Despite all this, my practical experience is that filesystem is better than blobs for things like uploaded content, images, pngs and jps etc. Blobs bring additional overhead, require bigger DB storage (more expensive usually, think AWS RDS) and the increased size cascades in operational overhead (bigger backups, slower restore etc). [0] https://www.microsoft.com/en-us/research/publication/to-blob-or-not-to-blob-large-object-storage-in-a-database-or-a-filesystem/
质疑基准：对比对象不公平（多文件 vs 单库文件），未解释原因；读快或得益于预读，写快得益于批量提交减少 fsync。
这是奇怪的 benchmarketing。他们比较读取/写入 100,000 个独立文件与把 100,000 条记录写入单个文件（SQLite 数据库）。作为对照，甚至可以把同样数据拼接成一个大文件，那会比写入 SQLite 更快。他们也没有给出逻辑分析解释为什么更快。我的理解是：读可能更快，是因为数据都在单个文件内时操作系统预读能更好地预测读取；写更快是因为一次批量 COMMIT 而不是许多独立的 fsync。
tarasglek查看英文原文
This is weird benchmarketing. They are comparing reading/writing 100,000 individual files vs writing 100,000 entries into a single file(sqlite database). For comparison one could concatenate the same data into a single big file even faster than into sqlite. They then do not offer logical analysis as to why things are faster. My understanding is that reads are probably faster due to operating system readahead being able to predict reads better when they are within a single file. Writes are faster because they do one bulk COMMIT instead of many individual fsyncs.
实际案例：Mapbox 等用 SQLite/MBTiles 存海量小地图瓦片，支持小 blob 存数据库。
对于网页地图瓦片（数百万个微小 PNG），业内所有重要玩家都把瓦片存在 SQLite 里而不是磁盘上：https://www.mapbox.com/help/an-open-platform/#mbtiles
craigds查看英文原文
For web map tiles (millions of tiny PNGs), everyone who's anyone stores their tiles in sqlite rather than on disk: https://www.mapbox.com/help/an-open-platform/#mbtiles
提醒结论有 caveats，标题可能误导；不应把结果泛化到所有关系数据库。
“所以你的结论应该是：SQLite 的读写延迟与磁盘上独立文件的读写延迟有竞争力。SQLite 常常更快。有时 SQLite 几乎一样快。无论如何，这篇文章推翻了‘关系数据库一定比直接文件系统 I/O 慢’的常见假设。”这句话在 1.1 Caveats 标题下，让我觉得标题有点误导（不过大概大多数基准标题都这样）。顺便问一下，有更熟悉文件系统和数据库 I/O 的人能确认或反驳这里的断言吗？具体来说，我不确定把这些结果（即使有效）推广到所有关系数据库是否公平。但这不是我的专业领域。
dsacco查看英文原文
> So let your take-away be this: read/write latency for SQLite is competitive with read/write latency of individual files on disk. Often SQLite is faster. Sometimes SQLite is almost as fast. Either way, this article disproves the common assumption that a relational database must be slower than direct filesystem I/O. This is under the 1.1 Caveats heading, which makes me feel the title is a little misleading (but only in the way most benchmark headings probably are, I guess). Incidentally, can someone more experienced with filesystem and database I/O confirm or contest the assertion here? Specifically, I'm not sure it's fair to generalize these results (even if valid) to categorical relational databases. But this is not a special area of expertise for me.
历次讨论
同类还值得读
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编辑精选