Я практикуюсь в работе с DynamoDB и другими бессерверными инструментами, предлагаемыми AWS. Я привык работать с реляционными базами данных, такими как MySQL, поэтому с Dynamo для меня было немного сложно.
По сути, я хотел сделать что-то похожее на то, что уже есть в Facebook, Instagram, Youtube и других популярных сайтах. И это создание платформы, которая позволяет пользователям регистрироваться, подписываться на других и публиковать медиафайлы (видео и изображения), которые можно лайкать и комментировать. Элементы, которые могут расти, например, подписчики или лайки, я изначально сохранял в виде списков в соответствующих таблицах; однако я понимаю, что это может быть не лучший подход, поскольку DynamoDB имеет ограничение на объем данных. Например, если кто-то вроде Коби Брайанта присоединился к приложению и сразу же получил миллионы подписчиков, подход со списком может быть не лучшим.
Нравится,
Средства массовой информации:
- МедиаID
- ID пользователя
- Тип медиа
- Размер
- S3_URL
- Нравится: {
...
...
}
- Комментарии: {
...
...
}
Не лучше ли хранить такие вещи в отдельных таблицах? Или я сейчас вспоминаю реляционные базы данных?
Например,
СМИ:
- МедиаID
- ID пользователя
- Тип медиа
- Размер
- S3_URL
Медиа_лайки:
- НравитсяID
- МедиаID
- ID пользователя
- Дата лайка
Media_Comments:
- Идентификатор комментария
- МедиаID
- ID пользователя
- Текст
- ДатаКомментарий
Или что еще было бы лучшим способом спроектировать что-то подобное?





Ознакомьтесь с рекомендациями DynamoDB по управлению отношениями «многие ко многим» docs.aws.amazon.com/amazondynamodb/latest/developerguide/…