DynamoDB Design PartitionKey, RangeKey и GSI

Question

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

Текущий подход

Таблица - события

 - eventId (HashKey)
 - userId
 - createdAt
 - some other attributes...

Таблица - пользователи

 - userId (HashKey)
 - name
 - birth
 - address

В таблице событий будет много записей, например, миллионы. Пользователей будет около 20 записей на данный момент.

Мне нужно будет выполнить следующие запросы:

 - GET paginated events from specific userId ordered by createdAt
 - GET paginated events from specific userId between some range of dates and ordered by createdAt 
 - GET specific event entry by eventId

Поэтому я подумал о создании GSI (Global Secondary Index) для таблицы событий со следующей настройкой:

 - userId (HashKey)
 - createdAt (RangeKey)

Но мой вопрос здесь: имеет ли смысл мой первоначальный дизайн? Почему-то я чувствую, что могу разработать таблицу событий со следующей настройкой:

 - userId (HashKey)
 - eventId (SortKey)

Но я думаю, что, следуя этому подходу, я столкнусь с ошибкой Hot Partition.

Некоторые советы и рекомендации будут оценены.

Благодарю.

Answer 1

Ваш подход кажется мне довольно хорошим. Принятие во внимание лучших практик https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/bp-partition-key-design.html, в частности

Вообще говоря, вы должны спроектировать свое приложение для единой деятельности по всем ключам логических разделов в таблице и ее вторичных индексах. Вы можете определить шаблоны доступа, которые требуются вашему приложению, и оценить общее количество RCU и WCU, которые требуются для каждой таблицы и вторичного индекса.

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

Если вы решили разделить таблицу на основе eventidвы получите миллионы разделов, каждый из которых будет иметь одинаковый идентификатор пользователя. Предполагая, что вам нужно будет запрашивать события у пользователей, показания будут равномерно распределяться между всеми разделами. Пишет для каждого события тоже, будет равномерно распределен среди всех.

Однако, если вы выберете userid как ключ раздела, больше запросов попадет в один и тот же раздел по сравнению с другой ситуацией. Следовательно, я предлагаю перейти с прежним (eventid будучи ключом раздела).

Это мои 2 цента.