在 postgres 中的多个表中使用相同的序列会出现什么问题？

Question

我们正在考虑使用共享序列为数据库中所有表的主键分配 ID。其中大约有 100 个。只有一对夫妇经常和定期插入。在我们进入实际尝试和负载测试阶段之前，我们想排除它是“出于明显原因的糟糕想法”。

我们的峰值负载是每秒 1000 次插入，跨几个表。

到目前为止，我们的研究表明 - 序列生成速度不应该是问题 - 序列碎片（间隙）会发生，但不应该是问题 - id 耗尽不会是问题

我们不确定我们是否错过了其他重要的事情。我们会感谢人们的意见，尤其是那些之前尝试过并有过正面或负面经历的人的意见。

对于上下文 - 我们这样做有两个主要动机。

这样做的一个动机是我们可以定义一堆字典（我们称之为范围）并将人类可读的单词分配给这些 id，因此我们希望确保不同表中的 id 永远不会重叠。因此，在一个范围内，id 12345 可能被分配值“Green”，而在另一个范围内，它可能被分配“Verde”。（实际上，我们不会将它用于国际化，但我们可能有一天会使用它）。

另一个动机是使在现场有多个部署变得容易，并且知道（通过唯一设置每个部署的几个最高有效数字的序列）我们的部署不会重叠主键。（就像一个 GUID 精简版）。

Answer 1

想到的三个可能的问题是：

1. 任何共享资源都会造成潜在的瓶颈。我的直觉说，对于您的峰值负载，这应该不是问题，但我强烈建议在类似生产的生产规模环境中对任何此类解决方案进行基准测试。

2. 您实际上是在为代理键分配含义，这违背了 RDB 理论中的部分目的。就其性质而言，代理键除了作为识别该关系中的元组的键之外，不应具有任何意义。如果实体可能一起有意义并且因此需要无冲突的密钥，它们被单独建模或在需求和/或数据模型设计中遗漏了什么是正确的吗？

3. 您正在引入潜在的故障点。如果部署没有获得其初始序列起点集怎么办？然后，您要么遇到部署阻止错误，要么部署从“破坏”您的功能的同一个地方开始。此外，如果在某个地方有人认为分支部署是个好主意，你会怎么做（在生产中，租户公司可能剥离了自己的一部分并需要分离出数据）。如果种子以某种方式被错误的升级部署或其他迁移重置怎么办？^[0]

如果这些问题都与您无关，那么请继续，这个想法不会破坏 IMO 的任何内容。当然，即使这个方法本身没有错，也可能有更好的方法。

当您说“UUID-lite”时，您暗示您已经考虑过并打折了 UUID。是这样吗，如果是这样，是否有特殊原因决定它们不适合这个项目？

不使用 UUID 的一个可能原因是索引碎片，尽管其重要性通常被大大夸大了^[1]。SQL Server 对此的回答是“顺序 GUID”，如果我们不考虑为键值分配含义，它几乎等同于您所建议的 - 也许 postgres 与此等效？当然，在某些非常特定的大容量工作负载中，总是增加索引可能会产生其自身的性能问题（最后一页争用、索引统计数据越来越陈旧）^[2]。

另一个反对 UUID 的常见论点是密钥长度：当 4 或 8 个字节就足够时，为什么每个值使用 16 个字节？如果唯一性确实是一个有用的属性，那么这通常会显着胜过关键大小的问题。如果密钥大小是一个问题，但您很乐意使用 64 位 INT 而不是需要保持在 32 位内，您可以使用您的技术，而不会通过执行种子整数密钥的想法而增加潜在的共享资源争用问题每个表^[3]使用正常的INT IDENTITY(<start>, 1)^[4]列定义，尽管这再次增加了部署复杂性（少量，但肯定不是零）。

人类可读性有时被认为是一个问题，但这可以追溯到为代理键分配含义。

可压缩性是一个不太常见的问题，但您可能会遇到。对于几乎任何压缩算法，UUID 都可能看起来像随机（因此不可压缩）数据，除非您使用类似 SQL 服务器的顺序 UUID 之类的东西。这可能是一个非常大的链接集（或其他数据块）的问题，其中包含许多实体 ID ，这些实体 ID 通过慢速网络提供给应用程序，或者如果需要使用 SQL Server 的索引压缩功能之类的东西，尽管这些都很重要本质上只是以稍微不同的方式重申密钥大小问题，顺序 UUID 也可能在这里有所帮助。

^{[0] 当然，这也可能发生在普通的身份列上，但是由于您使用的是一个不太常见的功能，因此您在错过问题后会增加经验不足的 DBA 的机会，如果一旦您停止做一些新的和令人兴奋的事情就会发生这种情况别处！}

^{[1] 我是一个 SQL Server 人，我怀疑 postgres 中的潜在问题是相同的，但据我所知，它可能有不同的索引布局可以减轻影响。}

^{[2] 尽管这些可能是特定于 SQL Server 的，尤其是我列出的两个示例中的后者}

^{[3] 前两个字节：因数据库而异，接下来的两个：因表而异，其余四个：递增位}

^{[4] 那是 MS SQL Server 语法，postgres 语法可能会有所不同，但您应该明白我的意思并能够翻译}

tl; dr：如果您发现自己在重新发明轮子，请确保在开始考虑为什么新设计可能适用或可能不适用之前，所有现有设计都确实不合适。