postgresql - Citus 上的主键(UUID、序列)策略

Question

Citus 上主键的最佳方法是什么？

UUID:不需要锁定，与身份/序列号相反。但存储成本高，最终查询成本高 + 会导致碎片化。

序列 - 身份在创建实体时造成瓶颈。存储成本更低，查询速度更快 + 没有碎片。

如果我们想成为规模就绪的项目，使用 UUID 会更好吗？

根据这篇文章: https://www.cybertec-postgresql.com/en/uuid-serial-or-identity-columns-for-postgresql-auto-generated-primary-keys/

对于分片，建议最终使用 UUID。

它在 Citus 上的表现如何？

我将给出一个模式示例:

User
UserId uuid/bigint?

Device
Device Id uuid/bigint?
UserId (here for the distribution key)

在上面的例子中，我们想根据UserId来分配用户数据，比如他的Devices。主键 ID 类型应该是什么？如果 UUID 是答案，我们是否应该担心节点中的碎片？

Answer 1

免责声明:我是从事 Citus 引擎工作的软件工程师，我打开了一个 PR 以支持列默认中的 UDF。

在您在问题 gen_random_uuid() 中分享的帖子中，UDF 用作列默认值。 Citus 尚不支持此功能。

我建议你使用 bigserial。

我还想指出，博客中的某些陈述对 Citus 来说是不正确的。例如:

So if you use sharding, where you distribute your data across several databases, you cannot use a sequence.

在 Citus 中，您可以创建分布式序列对象，其中每个工作节点将使用序列允许值的不相交子集。应用程序在协调器节点上看到单个序列，而分片有自己的具有不同起始值的序列。

(You could use sequences defined with an INCREMENT greater than 1 and different START values, but that might lead to problems when you add additional shards.)

Citus 通过 node_group_id * 2^48 移动 bigserial 的开始，这意味着您被限制为最多 2^18 分片，这实际上是无限的。当您在单个表中有数 PB 的数据或四分之一百万个分片时，您会遇到更大的问题，而这里的这种限制不会真正影响您的集群。

PS:我在 UDF 列默认值方面的工作现在暂停，因为最近的一些代码更改将使解决方案更清晰，更易于维护。我们尚未发布已发布版本中的更改。 https://github.com/citusdata/citus/pull/5149