Рекомендации при разработке эталонной модели данных в DynamoDB

#amazon-web-services #nosql #amazon-dynamodb

#amazon-веб-сервисы #nosql #amazon-dynamodb

Вопрос:

Мне нужно спроектировать базу данных с одной основной функциональной таблицей данных и подумать о том, чтобы хранить все справочные данные в отдельной таблице. Я могу сохранить оба типа данных в одной таблице, но для большей ясности хочу сохранить их отдельно. Мой шаблон доступа к справочным данным прост, так как позволяет получить все данные поиска. У меня есть следующие сомнения по этому поводу:

  1. Если мне нужно получить все справочные данные, мне нужно сохранить одинаковый PK для всех типов ссылочных объектов. например, база данных фильмов может содержать ссылки на такие объекты, как жанр, категории, возрастные группы и т.д. Все они имеют PK как REF_Data, а SK — как GENRE, CATEGORY, AGE_GROUP и т. Д. Но в этом случае в моей таблице будет только один PK, что кажется мне абсурдным дизайном или, возможно, не очень хорошим использованием nosql. Также я не хочу сохранять PK как разные имена сущностей и сканировать таблицу, поскольку она работает плохо.
  2. Второй вопрос, на который я пытаюсь ответить сам, заключается в том, какова наилучшая практика: создавать ли по 1 элементу для каждого ссылочного объекта и сохранять все данные в одном атрибуте в виде документа JSON. например, 1 элемент для всех жанров и добавлять все жанры в документ JSON в одном атрибуте, например, ДАННЫЕ. ИЛИ я должен сохранить ЖАНР как SK и создать несколько элементов и получить доступ с помощью составного ключа (PK SK) для 1 типа справочных данных, чтобы получить много элементов в 1 запросе. Я имею в виду, что 1 элемент в Dynamo имеет ограничение не более 400 КБ. Каков наилучший способ с точки зрения цены и производительности.

Пожалуйста, сообщите.

Спасибо

Комментарии:

1. Это описано в руководстве по DynamoDB docs.aws.amazon.com/amazondynamodb/latest/developerguide /…

2. Когда вы пишете PK и SK, вы имеете в виду ключ раздела DynamoDB и ключ сортировки?

3. Да, @jarmod. Я должен был уточнить это раньше.