Spanner 如何索引主键字符数 'deep'?例如如果前 2 个字符相同 +1,会不会有超级热点

Spanner how 'deep' is primary key character count indexed? e.g. would there be mega-hot spot if the first 2 characters are the same +1

我是第一次使用 Spanner。

我正在使用 UUIDv4 作为主键,但我正在构建一个 table,我认为根据我的理解可以从另一个主键中获益(或者辅助索引可能更好?但我'我仍在学习如何在 Spanner 中使用它们,但我的知识较少,尤其是如何在新行或修改行之后构建/维护)。

因为在某些情况下我会选择 WHERE primary_key AND another_primary_phone_number_key

例如这个 table 让我们称它为用户 org_id | uuid | formatted_phone_number,其中所有 phone 数字都以 +1 开头,然后到达最均匀分布的 1-9 第 3 个字符串字符

下面是该模式的外观 - 为示例缩短了

我相信 Spanner 将它们称为 Splits,这实际上会均匀分布吗?或者它会成为一个巨大的热点,因为它们都以 + 开头吗?

CREATE TABLE users (
  org_id STRING(MAX) NOT NULL,
  user_uuid STRING(MAX) NOT NULL,
  formatted_phone_number STRING(MAX),
  fb_uuid STRING(MAX),
  FOREIGN KEY(org_id) REFERENCES accounts(org_id),
) PRIMARY KEY(org_id, user_uuid, formatted_phone_number),
  INTERLEAVE IN PARENT accounts ON DELETE NO ACTION;

这个具体示例应该(可能)很好,因为重要的部分是避免主键的第一个 不是单调递增或递减。在您的示例中,第一列是组织密钥。如果这个密钥分布良好,例如因为它是一个 UUID,那么这应该没问题。

因此,即使作为主键第三列的 phone 数字是单调的 increasing/decreasing,你仍然很好,因为它不是钥匙。

此外:假设 phone 数字是主键的第一列,并且它们都以 '+1' 开头,后跟一些随机字符串,它仍然是一个很好的主键,因为索引是基于整个字符串构建的。如果您按字母顺序将所有 phone 数字写入 table.

,这只会是一个问题