快速写入只是把代价转嫁给了别处
Every fast write moves work somewhere else
每次看似极速的写入操作，本质上只是将工作转移到了系统的其他环节。文章深入剖析了从内存缓存、本地 NVMe SSD 的 fdatasync 到远程对象存储的 PUT 请求，不同持久化策略背后的延迟与容错权衡。在基于对象存储的新架构中，利用本地 WAL 加速写入虽能提升性能，却引入了数据丢失的风险窗口。作者通过对比不同存储层的同步点，揭示了性能数字背后的真实成本：当你看到极低的延迟时，必须清楚哪些故障场景下数据依然会丢失，以及系统能容忍多少未完成的清理工作。
每当我看到某个操作极快的性能数字时，我就想知道是哪个操作为此买单，成功之后还可能丢失什么，以及系统能容忍多少未完成的清理工作。
HN 评论区
23- aleksiy123
今天我才得知这个广义概念有个专有名词。
https://en.wikipedia.org/wiki/Waterbed_theory
在解决方案的某个阶段，你在一个领域做的任何优化（“按压”）都会导致另一个领域出现负面效应（“隆起”）。
但这确实是个很具体的例子。
- cpard
看到标题时，我第一时间想到的是数据平台中的“读时模式”（schema on read）与“写时模式”（schema on write）之争。
你可以让写入更快，其中一部分做法就是不去处理模式解析，但你确实把工作量推到了别处。
我想同样的原则适用于许多不同层面，从写入文件系统，到数据摄入过程中如何处理冲突的数据类型，皆是如此。
- xixixao
我认为数据库设计师往往忽视的两个角度：
1. 持久性延伸至客户端。复制型数据库可能向客户端确认写入成功，但如果这个确认在返回途中因网络问题丢失了怎么办？如果客户端通过简单的 HTTP 与数据库通信，写入最初看起来可能会像失败。客户端能重试吗？
2. 人类的感知时间是生物性的，变化不大。但自 80 年代以来，技术栈中的所有内容都变得快太多了。吞吐量固然重要，但延迟（相对而言）现在的约束力已远不如当年。