Я действительно изо всех сил пытаюсь придумать способ сохранить данные встреч в DynamoDB. Я чувствую, что это может быть должно быть , и я провел много исследований, чтобы изучить хорошие методы моделирования DynamoDB. Но я чувствую, что что-то упускаю. Я публикую здесь проблему в надежде, что кто-то может помочь добавить некоторое понимание, которое, как мне кажется, мне не хватает.
Информация для хранения:
- DateTime, на которое запланирована встреча начало
- Отображаемое название собрания
- Идентификатор организации, которая созвала собрание (будет одной из 4 возможных организаций)
- S3 расположение повестки дня собрания
- S3 расположение протокола собрания
Шаблоны доступа
- Запрос n самых последних собраний
- Запрос n последних собраний, отфильтрованных по организации
- Спецификация поиска c Встреча по ID
Рабочий процесс пользователя
- Планирует встречу.
- Публикует позже повестка дня.
- Обновить повестку дня новой версией.
- Опубликовать sh минут после собрания.
- Опубликовать sh пересмотренный протокол, если есть исправления.
Эта информация о встрече также отправляется в c, где пользователи могут увидеть 10 или 15 последних или предстоящих встреч. В SQL это будет просто SELECT * FROM Meeting ORDER BY date DESC LIMIT 10
Моя первоначальная мысль заключалась в том, чтобы определить таблицу как:
PK: meetingId // Generated UUID
SK: Date // ISO Date for the meeting's time i.e. '2020-07-15T18:30:00'
Однако, если я сделаю это, я сделаю «Найти 10 самые последние собрания »- это полное сканирование таблицы, что является дорогостоящим антишаблоном.
Так что я мог бы добавить GSI в код организации с другим ключом сортировки по дате. Но поскольку существует только 4 возможных кода организации, разве это не «горячая клавиша»? У меня могут быть тысячи собраний с течением времени, но все равно только 4 ключа разделов.
Это также позволило бы мне выполнить только «Найти n собраний по организации». Что мне использовать в качестве ключа раздела для фильтрации всех дат? Разве это не был бы второй GSI со всеми собраниями, имеющими один и тот же ключ раздела, чтобы я мог фильтровать по дате? Кажется, это самая горячая из горячих клавиш, разве это не антипаттерн?
Я действительно пытаюсь применить методы, описанные AWS здесь: https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/bp-modeling-nosql-B.html
Я тоже рисую из этой статьи: Обсуждение изобретений: https://youtu.be/HaEPXoXVf2k