2

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 是答案，我们应该害怕节点中的碎片吗？

4

1 回答 1

2

免责声明：我是在 Citus 引擎上工作的软件工程师，他在列默认值中打开了一个支持 UDF 的 PR。

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

我建议你使用 bigserial。

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

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

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

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

Citus 将大型连续剧的开头移动了node_group_id * 2^48，这意味着您被限制在2^18几乎无限的最大分片上。当您在单个表中拥有数 PB 的数据或百万分之一的分片时，您会遇到更大的问题，而这里的限制不会真正影响您的集群。

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

于 2021-12-30T02:30:48.847 回答