Cassandra的数据建模和uuid

我想在后端使用Cassandra为教育目的构建一个电影数据库。查询数据库主要由电影标题制作。所以目前我的数据适合以下模型。Cassandra的数据建模和uuid

movie title | imdb评级|发布年份|演员

阅读CQL文件，我发现在以下结构中使用

查询我的是什么，是使用单独的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？我打算保持2 replication_factor因为我使用的节点数量只是3

而且根据文档

不要在这些情况下使用索引：
... ... •在频繁更新或删除列

在我的数据库的最新列imdb_rating所以我不上构建任何辅助索引。

来源

2014-02-18 Abhiroop Sarkar

不能将标题列用作主键吗？

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

不使用单独的uuid字段有哪些优缺点？

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

在你的情况下，由于标题不是唯一的，所以使用标题和UUID组合作为组合键，因为你会按标题搜索。

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

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

来源

2014-02-18 07:54:32 Navid

如果我使用（movie_title，year）的复合主键，它会影响性能，因为一年内发布同名电影的机会非常少。另外，尽管电影标题不是唯一的，但如果我将它用作PRIMARY KEY，这会如何影响查询的性能？ –

>如果我使用（movie_title，year）的复合主键，它会影响性能，因为一年内发布同名电影的机会非常少。这是完全没有问题，这是没有性能缺陷。 >尽管电影标题不是唯一的，如果我将它用作PRIMARY KEY，这会如何影响查询的性能？如果您是按标题查询，则表现最佳。但通过这种方式，您无法通过有效评估来查询。 – Navid

@Navid如何在这种情况下更新imdb_rating？既然你不能更新聚类列中的值，你需要删除完整的行并插入新的行（这将创建墓碑）？ – pratsJ

Cassandra的数据建模和uuid

回答

相关问题