Я новичок в DynamoDB и хотел бы получить некоторую помощь о том, как лучше всего структурировать вещи, и о том, является ли это правильным инструментом для работы.
Допустим, у меня есть тысячи пользователей, подписанных для получения сообщений. Они могут получать сообщения каждые полчаса, час, пару часов или каждые 4 часа. По сути, для каждого сообщения пользователя есть атрибут расписания. Пользователи также могут указать временное окно для получения этих сообщений, например, с 09:00 до 17:00, а также для переключения активного состояния.
Я хочу, чтобы можно было легко получать сообщения для отправки различным пользователи в нужное время. Если бы это было сделано в SQL, это было бы действительно легко, с чем-то вроде:
Select * from UserMessageSchedules
where
now() > startTime
and now() < endTime
and userIsActive
and schedule = 'hourly'
Но я изо всех сил пытаюсь сделать что-то подобное в DynamoDB. Сначала я думал, что у меня будет следующая схема:
userId (ключ раздела)
messageId (ключ сортировки)
расписание (один из half_hour, hour, two_hours, four_hours)
startTime_userId
endTime
Я бы создал глобальный вторичный индекс с атрибутом schedule, являющимся ключом раздела, а startTime + userId, являющимся ключом сортировки. Затем я мог бы легко запросить сообщения, которые нужно отправить после startTime. Но мне все равно придется проверить endTime> now () в моей лямбде. Кроме того, я буду читать в большей части таблицы, которая кажется неэффективной и может привести к проблемам с пропускной способностью? И с ограниченным числом расписаний, я получу горячие разделы на GSI?
Так что тогда я подумал, что вместо отправки сообщений из таблицы, предназначенной для хранения пользовательских настроек, я мог бы обработать эту таблицу, когда будет сделана запись / отредактировал и заполнил таблицу toSend, которая выглядела бы так:
timeSlot (pk) timeSlot_messageId (sk)
00:30 00: 30_Message1_Id
00:30 00: 30_Message2_Id
01 : 00 01: 00_Message1_Id
Поиск сообщений для отправки в определенное время был бы приятным и быстрым, поскольку я просто запросил бы временной интервал. Но опять же я беспокоюсь о горячих точках и пропускной способности. Это нормально для каждого раздела иметь 1000 строк и только для этого раздела для чтения? Есть ли другие проблемы с этим подходом?
Другая возможность - иметь разные таблицы (а не разделы) для каждого получаса, когда что-то может быть отправлено, например, toSendAt_00: 30, toSendAt_01: 00, toSendAt_01: 30 и они будут иметь messageId в качестве первичного ключа и будут содержать данные, которые необходимо отправить. Я бы просто просмотрел таблицу. Является ли это излишним?
Вместо того, чтобы делать большие чтения данных каждые полчаса, лучше бы мне дублировать данные в Elasti c Искать и запрашивать это?
Спасибо!