Выбор ПК и СК в ДинамоДБ

Question

У меня есть следующие два предмета, которые мне нужно сохранить в DynamodB

• Исполнители
• Песни

У исполнителей есть идентификатор (уникальный для артисты), имя и пол. Песни имеют идентификатор (уникальный для песен), название, жанр, исполнителя и рейтинг.

Как мне смоделировать это в DynamoDB ?.

Я думал об этом: ID в качестве первичного ключа и наличие ключа сортировки, который содержит исполнителя или песню, чтобы их можно было различить. Это хороший выбор? В примерах я вижу больше разнообразия в ключе сортировки.

А как насчет полевого исполнителя в элементах песни? Должен ли я просто указать идентификатор художника?

Обновление: у меня много общих шаблонов доступа. Я, вероятно, могу решить эту проблему, создав некоторые индексы, но все же мне нужно выбрать хороший PK / SK:

get songs based on title
get songs based on rating
get songs based on genre
get songs based on artist

get artist based on rating
get artist based on gender
get artist based on name

Спасибо

Answer 1

Одна вещь, которую я узнал (трудный путь) о моделировании No SQL (DynamoDB), заключается в том, что вам нужно знать все ваши шаблоны доступа до Вы моделируете свой стол. В РСУБД довольно часто сначала моделируют, а потом оптимизируют индексы при изменении шаблонов доступа. Это не просто при моделировании No SQL (в противном случае произошел бы массовый переход от СУБД к No SQL).

С учетом вышесказанного я предложу упрощенную модель c и обновлю мой ответ на вопрос обновляется с помощью шаблонов доступа (например, «Мне нужно получить все песни для исполнителя»).

Исполнитель:

PK: Artist-<Artist ID>, т.е. Artist-1234 SK : <Name> Атрибуты: Gender et c.

Песня:

PK: Song-<Song ID>, то есть Song-5678 SK: <Genre> Атрибуты: жанр, идентификатор исполнителя, рейтинг

Этот подход позволит вам получить ваши сущности только по их идентификатору.

Хотя в No SQL обычно принято ненормализировать данные (то есть сохранять данные об исполнителе в песне) для простоты / более эффективный доступ позволил бы go с сохранением идентификатора артиста, поскольку он обеспечивает более простые обновления и лучшую согласованность.