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

回答

相關問題