Crate:为什么要求 PRIMARY KEY 列出现在 PARTITIONED BY 子句中？

Question

您能帮我理解我在这份文档中阅读的内容吗？ https://crate.io/docs/reference/sql/partitioned_tables.html

在这些示例表中，id long 列不是 primary_key；事实上，id 在这里不能是主键，因为如下所述“如果设置了主键，它必须出现在 PARTITION BY 子句中”

在我的应用程序中，我以前在 id string NOT NULL 上有一个 primary key，但现在我想在生成日期在此表上添加分区列就像在示例 partition_date timestamp GENERATED ALWAYS AS date_trunc('day', created_at) 中一样。我读过在日期列上进行分区将有助于提高按时间段范围查询的速度(例如，计算今天的所有记录只会命中今天的分区)，并帮助我归档较旧的数据帧(例如任何> 180天的数据) )，但我不想失去单个 PK 查找的性能。

既然我不能只做 PARTITIONED BY (partition_date)，我最好是...

a) 从 id 中删除主键约束？我很紧张这会影响我的单行查找性能!在这种情况下，PK 必须在分区键中是有意义的，因为要查找 WHERE id = "abc-123" 理想情况下应该只需要命中一个节点。

或

b) 将两列都用作分区键，例如 PARTITIONED BY (id, partition_date) -- 这看起来很奇怪，因为本能地，我想假设 id 会具有高基数并且对于分区列来说是一个糟糕的选择，并且“日”或“月”会更好，就像您文档中的示例所示。在这种情况下，我的 PK 查找是否命中了每个分区，或者它是否确切地知道要去哪里？如果我运行仅限于今天的聚合查询，它会命中每个分区还是只命中包含今天数据的分区？

Answer 1

这是一个很好的问题!由于分区是排序的“子表”，这有助于减少查询数据的大小。

主键影响 routing在 CrateDB 中，因此将其添加到分区表(这需要更广泛的路由)将拒绝 partitioned by clause 中的任何非主键列.因此，您的选择如下:

• a) 虽然这消除了有效执行 PK 查找的能力，但这似乎是一个明智的选择 - 使用 fulltext index 可以加速常规字符串查找。 - 但它也将删除 read-after-write-consistent 主键查找添加。根据生成主键的方式，使用内部 _id 列(用于查找)或发出 REFRESH TABLE 可能是可行的在 ID 查找之前。
• b) 将导致与主键一样多的分区(并且因为它们是唯一的......) - 所以这个选项将创建太多分区

因为选项 b) 会导致困惑，我推荐选项 a)。但是，如果主键查找对您的应用程序至关重要并且预期的数据量不是那么大(几百万就可以了 - 当然取决于集群大小和机器规范)，它可能在没有分区的情况下工作得很好!

干杯，克劳斯