FoundationDB 的“Anti-Features”：一个数据库把限制写进设计说明，意味着什么

大多数数据库的文档里，“限制”藏在附录或 FAQ 的角落。FoundationDB 反其道而行：它专门维护一个叫 Anti-Features 的页面，开篇第一句就是——“一个系统不是什么，有时和它是什么同样重要”[reference:0]。另一页 Known Limitations 则把这些条目分成两类：一类是“来自根本设计决策、短期内不太可能改变”的限制，另一类是“可能在未来版本中解决”的限制[reference:1][reference:2]。把限制当作设计意图的公开声明，而不是需要遮掩的缺陷——这本身就是一个值得读的信号。

5 秒，不是超时设置，是内存的容量

Known Limitations 里最显眼的一条：FoundationDB 不支持运行超过 5 秒的事务。从第一次读开始超过 5 秒后，后续读通常返回 transaction_too_old，带写入的提交返回 transaction_too_old 或 not_committed[reference:3]。

这个数字不是拍脑袋选的。FoundationDB 用 MVCC 实现严格可串行化，而多版本数据存放在 Resolver 和 StorageServer 的内存里。5 秒的 MVCC 窗口，直接对应的是“愿意为并发控制保留多少历史版本”这个内存预算问题[reference:4]。窗口拉长，内存占用随之上涨；窗口缩短，长事务被拒绝的概率上升。5 秒是这个权衡下的一个具体选择，官方论文的判断是：对大多数 OLTP 场景够用，超过这个时间的操作往往暴露的是应用端效率问题，而不是数据库不够快[reference:5]。

更关键的是，这条限制在协议层面是“硬”的。Resolver 只保留最近约 5 秒的已提交写入范围，一个比这更老的事务，Resolver 已经没有足够的历史来检查冲突，只能拒绝[reference:6]。transaction_too_old 不是一个可以被调大的参数，它是协议暴露在 API 表面的边界。

10 MB，来自客户端侧的一层缓冲

另一条设计限制是事务大小上限：受影响数据不能超过 10,000,000 字节，键不超过 10 KB，值不超过 100 KB[reference:7][reference:8]。

10 MB 的上限有一个容易被忽略的来源：客户端缓冲。事务在提交之前，写入在客户端侧被缓冲，冲突范围也在客户端侧被追踪；这个缓冲区的大小天然地给事务体量设了一个天花板[reference:9]。同时，OCC 的冲突检测也参与其中——一个事务影响的数据越多、冲突范围越宽，它在 Resolver 侧需要比对的窗口就越大，提交时因为冲突被拒绝的概率也随之上升。10 MB 不是“网络能传多大”的问题，而是乐观并发控制在这个数据量级上还能保持可接受冲突率的问题[reference:10]。

Anti-Features：核心被故意做小，因为层在等着

如果只看 Known Limitations，容易把 FoundationDB 理解成一个“能力有限”的键值存储。但 Anti-Features 页面给出了另一半解释：核心 API 被刻意限制在暴露一个可扩展、容错、带 ACID 事务和高性能的数据库所需的最小集合上[reference:11]。

这个“最小集合”具体排除了什么？没有查询语言，没有内建的数据模型（JSON、XML、列族、关系模型都不在核心里），没有分析框架，不支持断连操作，也没有用户级访问控制[reference:12][reference:13]。这些不是尚未实现的功能，而是被明确列为“不打算在数据库核心中提供”的反功能。

理由在 Layer Concept 里：核心只暴露一个有序键值存储，加上多键 ACID 事务，就足以成为更高级数据模型的基础。一个层可以在单个事务里更新多个键值对来保证一致性，可以自己实现索引（核心里没有索引，而且“永远不会有”），可以实现查询语言、分析逻辑，甚至整个框架[reference:14][reference:15]。换句话说，Anti-Features 不是能力的缺口，而是把复杂性从核心推到了层的一次架构分工。

这也解释了为什么 5 秒和 10 MB 的限制在核心层面不可协商：核心的职责是提供短小、可预测的事务，让层在这个基础上组合出更长的业务语义。如果核心自己支持长时间运行的事务，MVCC 内存和 OCC 冲突窗口都会失控，层的组合空间反而被压缩。

还有一些限制，指向的是复制与规模的物理事实

Known Limitations 里有一组不来自事务协议、而来自分布式复制本身的条目。

读取负载均衡有一条值得注意的边界：FoundationDB 会把读请求分散到持有副本的服务器上，但它不会因为某个键被频繁读取就自动提高该键的复制因子。在一个三副本系统里，单个键或一小段连续键的聚合读吞吐，上限就是三个服务器进程的总性能，官方给出的量级是“大约每秒 100,000 次读”[reference:16]。对于热点数据，绕过方式是在应用层把同一份数据存到多个子空间里，等价于手动提高复制因子[reference:17]。

集群规模方面，经过性能测试和调优的上限是 500 核/进程；更大的集群可能遇到性能瓶颈，表现为亚线性扩展[reference:18]。数据库大小经过测试的上限是 100 TB（键值对的总大小，实际磁盘占用在复制和开销之后会显著更高）[reference:19]。这些数字不是理论极限，而是“已经被验证过的区间”；超出区间不是不能用，而是进入了未经验证的地带。

还有一条看似与性能无关、但同样被归入设计限制的条目：FoundationDB 不是安全边界。任何能连接到集群的人都可以读写每一个键，没有用户级访问控制，外部防护必须由部署方自行提供[reference:20]。核心把这件事也划在了外面。

边界写在设计里，比写在 FAQ 里更有用

把 FoundationDB 的这些限制串起来，会看到一条一致的分界线：核心只承诺短小、可组合、强一致的事务，其余的一切——长逻辑、丰富模型、访问控制、热点扩展——都被推给层或部署方。5 秒和 10 MB 是这条分界线在内存和冲突检测上的投影；Anti-Features 是它在 API 范围上的投影；复制因子和集群规模的上限，则是它在物理资源上的投影。

这条分界线的价值不在于“FoundationDB 不能做什么”，而在于它让“应该在哪里做”变得没有歧义。当一个数据库把限制和反功能当作设计声明来写，读者不需要猜它的适用边界——它自己已经把边界画在了架构图上。对于选型来说，这比任何基准测试的峰值数字都更值得先读。