【FoundationDB 内核】选型与阅读地图：FoundationDB vs TiKV vs etcd

本系列从 Unbundled 全景 写到 Proxy / Sequencer / Resolver、OCC 严格可串行化、TLog 与 Storage、恢复与确定性模拟、Record Layer 与排障。读到这里应能回答「一次提交穿过哪些角色」「5 秒窗口约束什么」「恢复为何便宜」。本文是系列第 18 篇（末篇），收束三件事：选型决策树、站内阅读地图、学术谱系与开放问题。

系列状态：全 18 篇已完成（2026-07-17）。规划见 PLAN.md；系列入口见 index.html。横向产品对比不重复 distributed/39 的性能表。

一、选型决策树：先定约束再选系统

flowchart TD
  START["Need a distributed KV"]
  START --> Q1{"Data small and need Watch Lease semantics?"}
  Q1 -->|yes| ETCD["etcd<br/>control plane metadata"]
  Q1 -->|no| Q2{"Need multi-key ACID across shards?"}
  Q2 -->|no| Q3{"Single process embedded?"}
  Q3 -->|yes| ROCKS["RocksDB series"]
  Q3 -->|no| ETCD
  Q2 -->|yes| Q4{"Need strict serializability and Layer-friendly KV?"}
  Q4 -->|yes| FDB["FoundationDB<br/>OCC + unbundled roles"]
  Q4 -->|no| Q5{"Need SQL + snapshot isolation at large scale?"}
  Q5 -->|yes| TIKV["TiKV + TiDB<br/>Multi-Raft + Percolator"]
  Q5 -->|no| Q6{"Analytics freshness on same data?"}
  Q6 -->|near real time| TIFLASH["TiKV + TiFlash<br/>tikv-htap series"]
  Q6 -->|minutes OK| LAKE["Lakehouse + CDC"]

1.1 路径说明

1.2 何时选 FoundationDB

• 需要严格可串行化（含对写偏斜等 SI 无法覆盖的异常的防护诉求），并能接受 OCC 重试与 5 秒事务上限；
• 希望在稳定 KV 内核上用 Layer（如 Record Layer）叠记录/索引，而不是把 SQL 引擎绑死进存储；
• 团队愿意运维 Unbundled 多角色，并依赖（或自建）与确定性模拟相近的正确性工程文化。

1.3 何时不选 FoundationDB

• 只要 Watch/Lease、数据量很小 → etcd 更匹配；
• 主路径是 SQL + 生态工具链，且 SI 足够 → TiKV/TiDB 摩擦更小；
• 需要默认提供 HTAP 列存副本 → 本系列不提供 TiFlash 对等物，应看 tikv-htap；
• 不能接受「长事务 / 超大事务」限制 → 先读 第 9 篇 与 Known Limitations，而不是上线后调客户端 timeout。

1.4 机制对照（不是吞吐排名）

flowchart LR
  subgraph fdb ["FoundationDB"]
    SEQ["Sequencer versions"]
    RES["Resolver OCC"]
    TL["TLog durable"]
    SS["Storage async"]
    SEQ --> RES --> TL --> SS
  end
  subgraph tikv ["TiKV"]
    TSO["PD TSO"]
    RAFT["Multi-Raft"]
    PERC["Percolator SI"]
    TSO --> PERC
    RAFT --> PERC
  end
  subgraph etcdnode ["etcd"]
    R1["Single Raft group"]
    KV1["MVCC + Watch"]
    R1 --> KV1
  end

本表不比较 QPS。跨系统裸吞吐在一致性与事务模型不同时没有统一口径；需要数字时只引用各系统官方、口径完整的报告，且不得冒充本站实测。

1.5 最小故事：三类落点

从 tikv-htap 第 18 篇 过来的读者：那篇把 FDB 标为「严格可串行化 + Layer」分叉；本系列补的是分叉背后的角色与恢复路径，而不是再写一张产品对比榜。

二、站内阅读地图

flowchart LR
  KVCMP["distributed/39<br/>etcd TiKV FDB compare"]
  DST["distributed/54<br/>DST methodology"]
  TIKV["tikv-htap<br/>Multi-Raft Percolator"]
  ROCKS["rocksdb<br/>LSM"]
  RAFT["raft-explained"]

  subgraph SERIES["This series: FoundationDB kernel 18"]
    P1["01-06 roles"]
    P2["07-09 txn SSI"]
    P3["10-12 log storage"]
    P4["13-18 recovery layer ops select"]
    P1 --> P2 --> P3 --> P4
  end

  KVCMP --> P1
  KVCMP --> P4
  DST --> P4
  TIKV --> P2
  ROCKS --> P3
  RAFT --> P1

三、学术谱系收束

仍活跃的争论（无定论）：

• Unbundled 多角色 vs 单进程一体化（如部分 NewSQL）的长期运维成本，缺少控制变量的公开对比；
• 强事务 KV 是否应把丰富数据模型收进核心，还是坚持 Layer（Record Layer 论文与 FDB anti-features 哲学同侧，反对方常见于「电池附带」数据库）；
• DST 与形式化验证的分工——互补是工程共识，边界随团队能力变化。

四、系列完成状态

主线是：角色分工 → 版本与 OCC → 日志存储解耦 → 恢复/模拟 → Layer/选型。与 distributed/39（横向选型）、distributed/54（DST 通识）、tikv-htap（SI / Multi-Raft）、rocksdb（LSM）分工明确。

五、开放问题（全系列收束）

1. 高冲突负载下 OCC 重试是否可接受：第 9、17 篇给出机制与排障，但「冲突率到多少应改键设计或改系统」没有跨部署通用阈值。
2. durable（TLog）与 readable（Storage）间隙的对外 SLO：论文有单集群 lag 样例，运维契约仍各自定义（第 10–11、17 篇）。
3. 恢复窗口读服务等级：写暂停清晰，读降级如何产品化仍开放（第 13 篇）。
4. Layer 与 SQL：Record Layer 证明了记录+索引路径；与完整 SQL / HTAP 生态的边界，本系列只钉机制，不宣称收敛。
5. 模拟覆盖率度量：条件覆盖宏与种子回归有效，但「恢复状态空间是否测够」仍缺标准尺度（第 14 篇）。

以上问题不承诺「下个版本统一」——它们是公开论文与文档能支撑的已知边界。

5.1 读者若只带三个问题离开

1. 我的负载冲突是否过高？ → 用第 8、9、17 篇机制判断，而不是先换系统。
   
2. 我要的是 SI+SQL 还是严格可串行化+Layer？ → 本篇决策树 Q4/Q5。
   
3. 我能否运维恢复与多角色？ → 第 13、14、16 篇；若不能，重新评估复杂度预算。

5.2 与 tikv-htap 末篇的对称收束

tikv-htap/18 从 TiKV 视角给出含 FDB 的决策树；本篇从 FDB 视角回指 TiKV/etcd。两篇应对照阅读：

• 重复的是选型问题本身；
  
• 不重复的是各自系列的机制深度（Multi-Raft/Percolator vs Sequencer/Resolver/TLog）；
  
• 共同拒绝的是无一致性上下文的吞吐排名。

六、常见误解

误解一：FoundationDB 能替代 etcd 做 Kubernetes 控制面。
控制面需要的 Watch/Lease 与运维形态与 FDB 通用 KV 不同；默认仍应评估 etcd（distributed/39）。

误解二：严格可串行化意味着可以忽略事务时间上限。
严格可串行化与 5 秒窗口、有界冲突历史是一套设计；忽略上限会直接撞 Known Limitations。

误解三：选型就是比官方 blog 的吞吐截图。
先定一致性、事务、Layer/SQL、运维复杂度，再谈性能；本系列故意不给跨系统排名。

七、小结

三句话小结：

1. 选型先问：要不要 Watch 小元数据、要不要跨分片 ACID、要不要严格可串行化与 Layer——再落到 etcd / FoundationDB / TiKV（及 RocksDB、湖仓）之一。
2. 本系列 18 篇建立的主线是 Unbundled 角色、OCC 严格可串行化、TLog/Storage 解耦、epoch 恢复与 DST、Record Layer 与排障选型，并与 39 / 54 / tikv-htap / rocksdb 分工。
3. 高冲突可接受性、durable–readable SLO、恢复期读契约、Layer 与 SQL 边界、模拟覆盖度量，仍是标注但未关闭的开放问题。

若你从本篇决策树选中了 FoundationDB，建议从 系列目录 的「必读核心」路径回读机制篇，而不是只收藏选型表。

参考资料

1. 本系列 第 1–17 篇 及 PLAN.md（写作执行文档，非发布页）。
2. Zhou J., et al. FoundationDB: A Distributed Unbundled Transactional Key Value Store. SIGMOD 2021.
3. Chrysafis C., et al. FoundationDB Record Layer…. SIGMOD 2019.
4. distributed/39 分布式 KV 对比、distributed/54 确定性模拟、tikv-htap 选型末篇。
5. FoundationDB 7.x 官方文档（Transactions、Architecture、Known Limitations、Administration、Backup）。
6. 数据库内核索引、全部系列索引。

性能与容量数字一律以各系统官方、口径完整的材料为准；本系列正文不附跨系统排名表。

至此，从 Unbundled 角色到选型决策树的链路已经闭合；后续跟踪以官方 release note 与顶会系统论文为准即可。

系列入口与五条阅读路径仍以 index.html 为准。

上一篇：生产排障：超时、冲突、切换、落后

感谢读完本系列。FoundationDB 内核系列至此完结，返回 系列目录 查看全 18 篇，或回到 数据库内核索引 探索其它系列。