系统与数据库2012research.google.com编辑精选
F1：支撑 Google 广告业务的容错分布式关系数据库
F1 - The Fault-Tolerant Distributed RDBMS Supporting Google's Ad Business
进阶 · 约 60 分钟读完前置知识：分布式系统基础、ACID 事务、Spanner 基础
导读
这篇论文介绍 Google 的 F1，一个支撑其广告业务（AdWords）的容错分布式关系型数据库。F1 构建在 Spanner 之上，通过将数据划分为可跨节点复制的聚合（aggregate）来兼顾分布式扩展性与传统 RDBMS 的 ACID 事务、SQL 查询能力。它以较高的读写延迟为代价换取强一致性和高可用性，适合广告这类需要事务语义的业务。
HN 关注点：Google 广告业务如何从 MySQL 迁移到自研分布式 RDBMS，以及分布式数据库在一致性与延迟之间的取舍。
后来怎么样
F1 与 Spanner 的设计直接启发了 NewSQL 运动，催生了 CockroachDB、TiDB 等一批支持分布式 ACID 事务的数据库，'可扩展的强一致关系数据库'由此成为行业标准方向。
HN 评论精选
这几条评论里：支持 1 质疑 1 补充 1 亲历 1
亲历亲历者解释 AdWords 长期使用 MySQL 的原因：可预测、有大量人才懂它
我 2003-2005 年左右在 Google 参与 AdWords 的 MySQL 系统。我们投入了大量精力，配合合适的分区和缓存策略，MySQL 表现得相当不错。考虑到 Google 拥有这么多系统专家，它花了这么久才迁移走，我有点意外。不过 Google 大部分工程精力都用在超大规模数据上，那里允许少量数据丢失和最终一致性。AdWords 更像传统的 ACID 应用，而不是搜索引擎。MySQL 相比当下这批 NoSQL 或自研系统的一个特别优势是：有很多人懂 MySQL 怎么出故障、怎么调优。它是可预测的。我猜这也是它在 AdWords 里服役如此之久的原因之一。
NelsonMinar查看英文原文
I worked on the AdWords MySQL system while at Google around 2003-2005. We put a lot of work into it and with the right partitioning and caching strategies MySQL held up pretty well. I'm a little surprised it took so long for Google to migrate away from it, given all the systems expertise the company has. But most of Google's engineering efforts are for enormously large data where a little data loss and slow consistency is OK. AdWords is more like a traditional ACID application than, say, a search engine. A particular advantage of MySQL over the current crop of NoSQL systems or a home-grown system is there's a lot of people who understand how MySQL fails and how to tune it. It's predictable. I suspect that's part of why it had such a long life in AdWords.
质疑指出论文中的关键取舍：延迟远高于 MySQL，且不支持 join
我很惊讶没人注意到这里的主要取舍：非常高的写入延迟（读延迟也高，只是没那么夸张）。来自第 9 页幻灯片：性能方面——提交延迟极高，50-100ms；读取需要 5-10ms，比 MySQL 慢得多；吞吐量高。（而且这是不支持 join 的读取，因为 join 也不被支持。）
jbellis查看英文原文
I'm surprised nobody's picked up on the main tradeoff here: very high write latencies (and high read latencies too, just not as spectacularly). From slide 9: Performance: ● Very high commit latency - 50-100ms ● Reads take 5-10ms - much slower than MySQL ● High throughput (And that's reads-with-no-joins, since they are not supported either.)
支持赞赏聚合分片设计，认为企业市场需要 schema 和事务，胜过 MongoDB
看起来相当棒。避开假设频繁交互连接的 ORM 是务实的做法，他们也指出了需要预先显式取数据的代码复杂度代价。我喜欢他们把聚合（aggregate）加进 SQL schema 的做法，我一直希望有 RDBMS 能用这个特性来透明地处理分片。让我惊喜的是他们（据我所知）允许跨聚合的事务/join，尽管要用两阶段提交。如果只支持聚合内的事务/join 我也能接受，因为只要每个聚合自身是一致的，即使应用代码需要以最终一致的方式处理跨聚合协调，程序员仍然可以轻松推理这种模型。如果我是 VC，我会给做这种产品的公司投 4000 万美元，而不是 MongoDB。企业（在许可证/支持上的花费远超初创公司）历来想要 schema 和事务这类特性——关系型数据库流行这么久是有原因的。
stephen查看英文原文
Looks pretty awesome. Avoiding ORMs that assume a chatty connection make pragmatic sense, and they note the code complexity trade-off of having to explicitly fetch the data up-front. I like that they basically added aggregates to the SQL schema, I'd been hoping a RDBMS would come out with that feature as a way to transparently handle sharding. I'm pleasantly surprised they allow (AFAICT) transactions/joins across aggregates, albeit with 2PC. I would have been just fine accepting transactions/joins only within aggregates, as even if the application code has to handle coordination across aggregates in an eventually consistent manner, as long as each aggregate itself is consistent, I think programmers can still easily deal with/reason about that sort of model. If I were a VC, I'd give $40 million to a company building this product over MongoDB. Enterprises (who spend money on licenses/support much more than startups do) historically want features like schemas and transactions (i.e. there is a reason relational databases have been popular for so long).
补充遗憾 Google 只发布论文而不开源这些前沿系统
唉，真想深入研究这个东西并参与开发。令人沮丧的是，Google 一些最有前景、最有趣的技术（比如 BigTable）只能以白皮书或规格说明的形式流出。我能理解他们这么做的一些商业上的理由，但还是……很沮丧。
DEinspanjer查看英文原文
::sigh:: Would love to see this thing in detail and work on it. Frustrating that some of the most promising and interesting technologies in Google (e.g. BigTable) come out of there only in whitepaper or spec form. I can see several business advantage reasons for them to do so, but still... frustrating.
相关资源
从这篇论文所有 HN 讨论帖的全部评论里整理出来的链接。
历次讨论
- 2012Hacker News 讨论帖201 分 · 56 评
同领域还值得读
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 分钟编辑精选