系统与数据库2021foundationdb.org编辑精选
FoundationDB：一个分布式、解耦的事务型键值存储
FoundationDB: A distributed, unbundled, transactional key value store
进阶 · 约 90 分钟读完前置知识：分布式系统基础、事务与隔离级别、Paxos/共识协议
导读
这篇论文介绍 FoundationDB：一个分布式、解耦设计的事务性键值存储。核心亮点是其通过确定性仿真进行严格正确性测试，使系统极为可靠——CloudKit 部署超过 50 万磁盘年未发生一次数据损坏，生产集群中也从未发现过不一致的数据副本。
HN 关注点：HN 读者长期关注 FDB（被 Apple 收购后开源），讨论焦点是其传奇般的可靠性和独特的仿真测试方法论。
后来怎么样
FoundationDB 的确定性仿真测试方法成为分布式系统可靠性测试的标杆，被广泛借鉴；Apple 收购后将其作为 CloudKit 底层存储，2018 年开源后社区活跃，影响了后续多个系统的设计。
HN 评论精选
这几条评论里：支持 1 补充 2 亲历 1
亲历亲历者盛赞 FDB 运维省心、数据零丢失，可在高负载下无缝更换硬件
对 FoundationDB 只有赞美，它是我用过的最稳固的分布式数据库。以前管理 HBase 集群时，从不用手动拆分 region、也不用调 JVM GC，简直是运维福音。我们用三数据中心副本跑了多个 FDB 集群，从未丢过数据。有一次想替换 AWS 上的全部硬件，只需把集群规模翻倍、等数据迁移平稳后直接下线旧机器，全程在生产 10 万+ TPS 下进行。客户端会自动更新 cluster file，无需逐个修改连接参数。
monstrado查看英文原文
Have nothing but praise for FoundationDB. It has been by far the most rock solid distributed database I have ever had the pleasure of using. I used to manage HBase clusters, and the fact that I have never once had to worry about manually splitting "regions" is such a boon for administration...let alone JVM GC tuning. We run several FDB clusters using 3-DC replication and have never once lost data. I remember when we wanted to replace all of the FDB hardware (one cluster) in AWS, and so we just doubled the cluster size, waited for data shuffling to calm down, and just started axing the original hardware. We did this all while performing over 100K production TPS. One thing that makes the above seamless for all existing connections is that clients automatically update their "cluster file" in the event that new coordinators join or are reassigned. That alone is amazing...as you don't have to track down every single client and change / re-roll with new connection parameters. Anyway, I talk this database up every chance I get. Keep up the awesome work. - A very happy user.
支持FDB 通过 Jepsen 全部测试，作者亲测断电后总能自动恢复
推荐一篇我最喜欢的 FDB 文章：它首次跑 Jepsen 就全部通过。FDB 是我近十年用过最酷的技术之一，tuple 键空间和多键事务非常好用。我在家里的服务器上多次物理切断 FDB 节点甚至整个集群的电源，每次都能自动恢复。
rubyn00bie查看英文原文
Here's one of my favorite articles on FoundationDB, where it (FDB) passes Jepsen first try: https://web.archive.org/web/20150312112556/http://blog.foundationdb.com/foundationdb-vs-the-new-jepsen-and-why-you-should-care > I ran FoundationDB Key-Value Store through every nemesis in Jepsen - including those that found failures in other databases - and FoundationDB passed all of them with flying colors. FoundationDB is one of the coolest pieces of technology I've used in the past decade. The tuple keyspace is incredibly useful, so are the multi-key transactions. I've physically killed the power on an FDB node and FDB cluster; multiple times (heh, home servers)... and every time the cluster or node just comes back.
补充摘录论文关键数据：50 万磁盘年零数据损坏，自研 Paxos 替换 Zookeeper 后零生产 bug
引用论文中两段话激励大家去读原文：一是 CloudKit 部署 FDB 超过 50 万磁盘年无一次数据损坏，且持续做副本一致性校验，至今未发现不一致副本；二是早期 FDB 依赖 Zookeeper，2010 年前后通过真实故障注入发现其两个独立 bug 后，改用 Flow 自研的 Paxos 实现，此后再无生产 bug 报告。
ryanworl查看英文原文
Two quotes from the paper that I think will motivate people to read it: "Rigorous correctness testing via simulation makes FDB extremely reliable. In the past several years, CloudKit [59] has deployed FDB for more than 0.5M disk years without a single data corruption event. Additionally, we constantly perform data consistency checks by comparing replicas of data records and making sure they are the same. To this date, no inconsistent data replicas have ever been found in our production clusters." "For example, early versions of FDB depended on Apache Zookeeper for coordination, which was deleted after real-world fault injection found two independent bugs in Zookeeper (circa 2010) and was replaced by a de novo Paxos implementation written in Flow. No production bugs have ever been reported since."
补充补充资料：推荐关于 FDB 测试方法的演讲视频
Snowflake 的 Markus Pilman 在 CMU 的 Quarantine Tech Talks（2020）做了一个关于 FoundationDB 测试方法的精彩演讲《How I Learned to Stop Worrying and Trust the Database》。
jorangreef查看英文原文
Markus Pilman from Snowflake did an awesome talk on FoundationDB's testing at CMU's Quarantine Tech Talks (2020), How I Learned to Stop Worrying and Trust the Database: https://www.youtube.com/watch?v=OJb8A6h9jQQ
相关资源
从这篇论文所有 HN 讨论帖的全部评论里整理出来的链接。
历次讨论
- 2021Hacker News 讨论帖283 分 · 99 评
同领域还值得读
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 分钟编辑精选SQLite：过去、现在与未来
SQLite: Past, Present, and Future
这篇 VLDB 论文梳理 SQLite 的历史、当前架构与性能表现，并展望未来方向。
系统与数据库2022 · 282 分 · 86 评进阶 · 约 40 分钟编辑精选