F1：能扩展的分布式 SQL 数据库

一句话

F1 是 Google 为 AdWords 打造的分布式关系数据库：它建在 Spanner 之上，既继承了 Spanner「能水平扩展 + 全球强一致」的存储底座，又在其上重新提供了完整 SQL、ACID 事务、一致的二级索引——正面推翻了「要扩展就必须放弃 SQL 与事务」的行业成见。为吞下同步复制带来的高提交延迟，它用层级式 schema（把相关数据物理聚簇成一棵树）、Protocol Buffer 列类型、乐观事务、以及批量+并行的客户端访问模式把延迟摊平，并把变更历史做成一等公民来维护一致索引。它自 2012 年起在生产环境管理着 AdWords 的全部数据。

Glossary · 术语表

坐标

作者是 Jeff Shute 等一大队 Google 工程师，论文发在 VLDB 2013。它上承 Google 自家的 Spanner（2012，提供强一致、可扩展的存储与事务）——F1 是盖在 Spanner 上的 SQL 层；它要替换的是 AdWords 底下那套手工分片的 MySQL（一次重新分片耗时以年计、动用大批人力）。它也是「NewSQL」浪潮的标志性系统之一：与它同时代的 Google Spanner、以及后来的 CockroachDB、TiDB 等，都在回答同一个问题——能不能既要扩展、又要 SQL 和事务。

问题与动机

2000 年代，做大规模系统的人被逼进一道二选一。传统关系数据库给你 SQL、事务、强一致，但扩不动：数据超过单机就得手工分片，之后跨分片的事务、跨分片的 JOIN、以及业务增长后的再分片，都是巨大的运维负担。Google 的 AdWords 正卡在这里——它跑在一套人工切分的 MySQL 上，一次重新分片要动员一个团队、耗时约两年。

另一条路是 NoSQL（Google 自家的 Bigtable 是代表）：天生能摊到几千台、随便扩，但代价是放弃了跨行事务、放弃了 SQL、只给最终一致。逃到 NoSQL 的应用开发者，得在应用层自己拼事务、自己维护索引一致、自己写查询逻辑——把数据库本该干的脏活全背到身上。

F1 的动机就是：这道二选一是假的。只要底层能提供「可扩展 + 强一致」的存储，就能在其上把关系数据库最有价值的东西（SQL、事务、索引）重新装回来。而这样的底层，Google 刚好有了——Spanner。作者明确列出四个必须同时满足的目标：可扩展、可用、一致、好用——尤其强调「好用」，因为要让几百个工程师顺手把 AdWords 迁上来。

核心思想 / 方法

骨架：把「扩展」甩给 Spanner，自己专心做 SQL 层

F1 的第一层设计哲学是分工。最难的「水平扩展 + 跨机房强一致复制」交给下面的 Spanner：数据按目录切成许多片，每片由一组副本（通常 5 个、跨多机房）用 Paxos 同步复制。F1 自己则是一层基本无状态的 SQL 引擎：客户端可以连到任意一台 F1 server，server 本身几乎不存数据，因此可以随意增删、按需扩容。大查询则交给一个 F1 slave pool（分布式查询 worker 池）并行执行。

层级式 schema：把相关数据聚成一棵树，物理挨着放

这是 F1 最关键的设计，直接决定它能不能扛住延迟。传统关系模型里各张表互相独立、物理上四散；F1 允许把表声明成父子层级：子表的主键以父表主键为前缀，于是一个父行和它名下的所有子孙行被物理聚簇（clustering）在一起、交错存放，归入同一个 Spanner 目录、也就是同一个 Paxos 组。

以 AdWords 为例：Customer（广告主）→ Campaign（广告系列）→ AdGroup（广告组）。一个广告主的整棵数据树落在同一格里。好处是决定性的：取一个客户的全部资料是一次本地读取（不必跨组四处捞），改动这棵树内部的数据是一次单组本地事务（不必发起昂贵的跨组分布式提交）。因为真实业务里绝大多数事务恰好都局限在「一个客户」范围内，这一步就把大部分写操作变成了便宜的本地操作。

Protobuf 列：把「一对多」塞进一行，少连几次表

F1 的列不止能存数字和字符串，还能直接存 Protocol Buffer 对象——包括可重复字段（一个字段里装一串值）。这意味着许多本该拆成子表、查询时要 JOIN 的一对多关系，可以直接内嵌进父行的一个 protobuf 列里，少建几张表、少连几次表。而且 Google 的应用代码本来就用 protobuf 传数据，让数据库原生理解 protobuf，抹掉了对象与关系表之间的阻抗失配，开发体验更顺。

与延迟共处：乐观事务 + 批量并行读

代价躲不掉：Spanner 的同步复制让一次提交要跨机房投票，延迟约 50–150 毫秒（读则约 5–10 毫秒）。F1 用两手化解。

其一是乐观事务（optimistic transaction），也是默认模式。它分两段：读阶段可以任意长、不加任何锁，只默默记下读过的每一行的「最后修改时间戳」；随后一个很短的写阶段把要写的改动打包，提交前重新核对那些时间戳有没有变——没变就落盘，变了（说明被人抢先改过）就中止重试。类比多人协作编辑共享文档：不锁文档，只在保存那一刻查一下「我读的内容有没有被人动过」。好处一串：慢吞吞或崩掉的客户端不会一直占着锁堵别人；重试幂等、服务端好实现；配合无状态的 F1 server 天然合拍。（另有快照事务做只读一致快照、悲观事务直接用 Spanner 的加锁事务，按需选用。）

其二是改造应用的访问模式。既然每次访问都像一通慢速越洋电话，就别一句一句地串行问：F1 鼓励应用批量地、并行地发起读取，用「次数更少、彼此并行」抵消单次的慢。配合层级式 schema（一次读回整棵树），AdWords 迁到 F1 后，网页端到端延迟反而与旧 MySQL 相当、部分页面还更快——单次操作虽慢，但并行度上来了。

一致的索引与变更历史

索引有两种物理形态：本地索引与被索引的行同处一个目录，随行的事务一起更新，便宜；全局索引横跨众多目录、独立分片，更新它要发起跨组的分布式事务，昂贵，因此 F1 会限制一个事务里能改多少条全局索引。两种索引都随事务同步维护、保证一致——这正是 NoSQL 交给应用层自己扛、而 F1 替你扛下的活。此外，F1 把变更历史（change history）做成一等公民：每个事务都把自己的改动作为变更记录一并写下，下游可以订阅这些变更用于增量维护索引、失效缓存、同步到其它系统——一个内建、一致的「变更数据捕获」。

关键结果

最有说服力的结果是它真的在跑 Google 最赚钱的业务：F1 自 2012 年初起在生产环境管理 AdWords 的全部数据，取代了之前手工分片的 MySQL，规模达上百 TB 级、承载持续的高并发 OLTP 负载。性能上，论文诚实地给出数字：得益于同步复制，提交延迟约 50–150 毫秒，明显高于单机数据库；但通过层级 schema、乐观事务与批量并行读，AdWords 的用户可见延迟与旧系统相当。可用性上，靠 Spanner 的多副本（典型 5 副本跨多机房），系统能扛住整个机房下线而不丢数据、几乎不中断。扩展性上，加机器即扩容，彻底告别了「以年计的重新分片」。

为什么重要 / 影响

F1 与 Spanner 一起，把行业从「扩展就得放弃 SQL 与事务」的宿命里拉了出来，亲手证明了「可扩展」与「强一致 + 完整 SQL + 事务」可以并存——只要肯为一致性付出一点延迟、并在设计上把它摊平。它是 NewSQL 潮流的旗帜之一，直接启发和印证了后来一批分布式 SQL 数据库（CockroachDB、TiDB、YugabyteDB 等）的路线：底层做可扩展强一致存储，上层重铸 SQL。它示范的几样具体工程——层级聚簇换数据局部性、乐观事务对抗高延迟与不良客户端、内建变更历史维护一致索引——也成了后来系统反复借鉴的套路。对 Google 自己，它更是把最核心业务的数据底座换血成功的一次实战。

局限与批评

• 提交延迟天生高：同步跨机房复制让单次提交要 50–150 毫秒，比单机数据库慢一个数量级。F1 靠 schema、乐观事务和应用改造摊平，但这要求应用配合改写（批量、并行、容忍延迟），不是把老应用原样搬上来就能用。
• 资源成本更高：为达到同一目标，F1 消耗的 CPU 等资源比原 MySQL 更多——强一致与可扩展不是免费的。
• 全局索引昂贵：跨目录的全局索引更新要分布式事务，写多、跨度大的负载会受限；schema 设计得尽量让操作落在单个层级树内才划算，这对建模提出了要求。
• 乐观事务在高冲突下吃亏：热点行被反复并发修改时，乐观事务会频繁中止重试，吞吐下降；此时需退回悲观（加锁）事务或更细粒度的冲突跟踪。
• 强依赖 Spanner：F1 的一致性、可用性、扩展性几乎全建立在 Spanner 之上——而 Spanner 又依赖 TrueTime 那套 GPS + 原子钟的专用授时基础设施，这是 Google 的家底，别处未必复制得来。

要点