SpiceDB在CockroachDB上的事务表性能问题分析

在分布式权限数据库SpiceDB中，设计了一个专门用于防止"NewEnemy"错误的事务表机制。这个机制通过在transactions表中记录额外的时间戳信息来确保线性一致性，但同时也带来了显著的性能开销。

问题背景

SpiceDB使用一个集中式的事务表来跟踪所有事务的时间戳。这个设计初衷是为了防止在CockroachDB分布式环境中出现"NewEnemy"错误（即由于时钟偏移导致的事务冲突）。然而，由于所有事务都需要频繁更新这个表中的同一行数据，实际上在CockroachDB集群中创建了一个热点，导致大量不必要的UncertaintyRetries错误。

技术原理分析

CockroachDB本身通过max_clock_skew机制来处理时钟偏移问题。当检测到数据比当前事务的时间戳更新时，会触发UncertaintyRetries让客户端重试。SpiceDB额外的事务表机制实际上是在应用层又实现了一次类似的功能。

理论上，使用SELECT FOR UPDATE语句配合SERIALIZED隔离级别应该足以防止"NewEnemy"错误。SELECT FOR UPDATE会为查询返回的行获取排他锁，防止在读取过程中数据被修改。这种方案可以避免集中式事务表带来的热点问题。

历史考量与现状

五年前SpiceDB团队在设计这个机制时，曾测试过SELECT FOR UPDATE方案，但发现由于CockroachDB写意图(Write Intent)创建方式的特殊性，仍可能出现时间戳乱序的情况。写意图的创建顺序在分布式节点间无法保证完全一致，导致从全局视角看数据顺序可能违反线性一致性。

现有解决方案

对于不关心"pop-in"问题（新创建关系短暂不可见）的场景，SpiceDB提供了配置选项可以完全禁用事务表机制。此外，也可以通过设置租户键(tenant key)来将事务表的使用范围限定在特定数据子集内，从而减轻热点问题的影响。

未来优化方向

虽然目前仍需保留事务表机制，但值得考虑以下优化方向：

1. 重新测试新版本CockroachDB中SELECT FOR UPDATE的行为，确认是否已有改进
2. 探索混合方案，结合SELECT FOR UPDATE和部分使用事务表
3. 优化事务表的分片策略，减少热点影响

分布式系统的时间一致性始终是一个复杂问题，需要在正确性和性能之间做出权衡。SpiceDB团队将持续关注底层数据库的演进，寻找更优的解决方案。