json - 使用 Murmur3 哈希作为数据库主键的优缺点

Question

我正在创建数据库，有多个表，例如Apps, Space, Builds, Processes.

我要使用这个数据库的应用程序就像一个用于平台监控的实时仪表板，数据库每秒都会更新新信息。

每当收到新信息时，apps_guid 都会重复行，这就是我不能使用 apps_guid 作为主键的原因。

我打算在这些表中使用 Murmur3 哈希作为主键并用于检查重复项。

我知道 Cassandra 使用它作为主键，但不确定它将如何在关系数据库中执行，这是个好主意吗？你有更好的建议吗？

应用栏：

--
id int IDENTITY
app_guid binary
name varchar(255)
state varchar(255)
created_at datetime
updated_at datetime
type varchar(255)
stack varchar(255)
apphash binary PK
timestamp datetime

Answer 1

对主键使用散列函数从来都不是一个好主意。

Cassandra 没有这样使用，它可以使用 murmur 来定义记录所在的分区/分片，这是完全不同的。哈希函数有冲突。这对他们来说没问题，因为他们不应该被用来保证唯一性。您将获得可变大小输入的固定输出。不言自明为什么碰撞对于这类函数来说很好。

即使对于非常大量的摄取/输入，也有不同的算法可以生成唯一 ID。您可以创建一个单独的 GUID（不同于您的apps_guid）或查看更复杂的算法，例如：

• FlakeId（示例）
• ksuid( https://github.com/segmentio/ksuid )

但是还有其他...

还要检查Instagram 的方法；来自Segment和这篇论文的好文章。