Моделирование данных и uuid на Cassandra

Я пытаюсь создать базу данных фильмов для образовательных целей, используя 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 ) );

Вопрос, который у меня есть, заключается в том, что необходимо использовать отдельный столбец идентификатора. Нельзя ли использовать столбец title в качестве первичного ключа? каковы преимущества и недостатки использования отдельного поля 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, поэтому я не строю для него вторичный индекс.


database cassandra data-modeling cql cql3
person Abhiroop Sarkar    schedule 18.02.2014    source источник

Ответы (1)


arrow_upward
2
arrow_downward

Нельзя ли использовать столбец title в качестве первичного ключа?

Если название фильма уникально (что не обязательно верно), вы можете использовать название в качестве первичного ключа.

каковы преимущества и недостатки использования отдельного поля uuid?

UUID хорош, если вам нужен уникальный идентификатор, уникальный во всем мире, и вам не нужно проверять его уникальность. Если вы можете найти набор столбцов, которым может быть предоставлено, что их комбинация уникальна, вам не нужно использовать UUID (при условии, что вам не нужен идентификатор для ссылки на него). Но все зависит от вашего шаблона запроса. если вы собираетесь искать фильм с его идентификатором (возможно, из другой таблицы), используйте UUID в качестве первичного ключа. если вы хотите найти фильмы с определенным названием, используйте название в качестве первичного ключа.

в вашем случае, поскольку заголовок не уникален, используйте комбинацию заголовка и UUID в качестве составного ключа, учитывая, что вы будете искать по названию.

Здесь я считаю, что название моей модели - это ПЕРВИЧНЫЙ КЛЮЧ, а КЛЮЧ РАЗДЕЛА, а imdb_rating - это КЛАСТЕРИРУЮЩИЙ КЛЮЧ (для упорядочения вывода в порядке возрастания). Что-то не так в моей модели и как это повлияет на распределение данных и почему я должен/не должен использовать uuid?

в этом случае вы должны использовать рейтинг и UUID для первичного ключа, но при запросе вам нужно разрешить фильтрацию.

person Navid    schedule 18.02.2014
comment
повлияет ли это на производительность, если я использую составной первичный ключ (movie_title, year), поскольку есть очень редкие шансы, что фильмы с таким же названием будут выпущены через год. Кроме того, несмотря на то, что название фильма не является уникальным, если я использую его в качестве ПЕРВИЧНОГО КЛЮЧА, как это повлияет на производительность запроса? - person Abhiroop Sarkar; 18.02.2014
comment
› повлияет ли это на производительность, если я использую составной первичный ключ (movie_title, year), поскольку есть очень редкие шансы, что фильмы с таким же названием будут выпущены через год. это совершенно нормально, в этом нет недостатка в производительности. › Кроме того, несмотря на то, что название фильма не является уникальным, если я использую его в качестве ПЕРВИЧНОГО КЛЮЧА, как это повлияет на производительность запроса? если вы запрашиваете по заголовку, производительность оптимальна. но таким образом вы не сможете эффективно запрашивать рейтинг. - person Navid; 18.02.2014
comment
@Navid Как вы будете обновлять imdb_rating в этом случае? Поскольку вы не можете обновлять значения в столбце кластеризации, вам нужно удалить всю строку и вставить новую (которая создаст надгробную плиту)? - person pratsJ; 07.12.2016