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 来说是不正确的。例如：

因此，如果您使用分片（将数据分布在多个数据库中），则无法使用序列。

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

（您可以使用使用大于 1 的 INCREMENT 和不同的 START 值定义的序列，但这在您添加其他分片时可能会导致问题。）

Citus 改变了大连续剧的开始时间node_group_id * 2^48，这意味着您的分片数量上限2^18实际上是无限的。当您在单个表中拥有 PB 级数据或一百万个分片中的四分之一时，您将遇到更大的问题，并且这里的限制不会真正影响您的集群。

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