Cassandra 上的数据建模和 uuid

Question

我正在尝试在后端使用 Cassandra 构建一个用于教育目的的电影数据库。对数据库的查询主要通过电影片名进行。所以目前我拥有的数据适合以下模型。

电影名称 | imdb 评级 |发布年份 |演员

阅读 CQL 文档后，我找到了使用以下结构的音乐播放列表示例

CREATE TABLE playlists (
id uuid,
song_order int,
song_id uuid,
title text,
album text,
artist text,
PRIMARY KEY (id, song_order ) );

我的查询是使用单独的 id 列的必要性。标题栏不能作为主键吗？不使用单独的 uuid 字段有什么优缺点？

我为我的模型设计的命令是

CREATE TABLE movies (
title text,
imdb_rating double,
year int,
actors text,
PRIMARY KEY (title, imdb_rating ) );

我相信我的模型标题是PRIMARY KEY 和PARTITION KEY，imdb_rating 是CLUSTERING KEY（用于按升序排列输出）。我的模型有什么问题吗？它将如何影响数据的分布？为什么我/不应该使用 uuid？我计划将 replication_factor 保持为 2，因为我使用的节点数只有 3。

也根据文档

在这些情况下不要使用索引：
…… •在经常更新或删除的列上

在我的数据库中，最新的列是 imdb_rating，因此我没有在其上构建任何二级索引。

Answer 1

标题栏不能作为主键吗？

如果电影标题是唯一的（不一定是真的），您可以使用标题作为主键。

不使用单独的uuid字段有什么优缺点？

如果您需要一个全球唯一的唯一 id 并且您不必检查它的唯一性，那么 UUID 是很好的选择。如果您可以找到一组可以被授予其组合唯一性的列，则您不必使用 UUID（假设您不需要 id 来引用它）。 但这一切都取决于您的查询模式。如果您要查找带有 id 的电影（可能来自另一个表），请使用 UUID 作为主键。如果您想查找具有特定标题的电影，请使用标题作为主键。

在您的情况下，由于标题不是唯一的，请使用标题和 UUID 的组合作为复合键，因为您将按标题进行搜索。

在这里，我相信我的模型标题是 PRIMARY KEY 和 PARTITION KEY，而 imdb_rating 是 CLUSTERING KEY（用于按升序排列输出）。我的模型有什么问题吗？它将如何影响数据的分布？为什么我应该/不应该使用 uuid？

在这种情况下，您必须使用评级和 UUID 作为主键，但是当您查询时，您需要允许过滤。