DynamoDB Design PartitionKey, RangeKey и GSI
Я разрабатываю новую таблицу поверх 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)
Но я думаю, что, следуя этому подходу, я попаду в ловушку горячих разделов.
Будем признательны за некоторые советы и рекомендации.
Спасибо.
@bwinant Эти события будут запрашиваться пользователями, когда пользователь войдет в свою учетную запись бэк-офиса, поэтому это не запрос на основе времени или что-то в этом роде. Наверняка будут пользователи с миллионами событий, а некоторые другие с сотнями или тысячами. Число пользователей будет расти, но медленно и ненамного (возможно, мы ожидаем, что на данный момент у нас будет 10/20 пользователей в месяц, но мы можем масштабироваться до сотен в месяц) Спасибо.
Ответы 1
Мне ваш подход кажется неплохим. Принимая во внимание передовой опыт https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/bp-partition-key-design.html, в частности
Generally speaking, you should design your application for uniform activity across all logical partition keys in the Table and its secondary indexes. You can determine the access patterns that your application requires, and estimate the total RCUs and WCUs that each table and secondary Index requires.
Это означает, что мутация данных должна быть как можно более равномерно распределена между всеми разделами. В вашем случае будет много событий и ограниченное количество пользователей, предполагая, что у каждого пользователя должно быть множество событий.
Если вы выберете разделение таблицы на основе eventid, вы получите миллионы разделов, каждый из которых будет иметь один и тот же идентификатор пользователя. Предполагая, что вам нужно будет запрашивать события у пользователей, операции чтения будут равномерно распределяться по всем разделам. Записи для каждого события также будут распределены между всеми равномерно.
Однако, если вы выберете userid в качестве ключа раздела, больше запросов попадет в тот же раздел по сравнению с другой ситуацией. Следовательно, я предлагаю использовать предыдущий (eventid является ключом раздела).
Это мои 2 цента.
Ваш подход кажется разумным, но ответ зависит от обстоятельств? Как часто вы будете запрашивать события у пользователей? Будет ли у некоторых пользователей больше событий, чем у других? Будет ли со временем расти количество пользователей?