Как создать хороший первичный ключ в DynamoDB

Question

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

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

Я думаю, что это из-за моего первичного ключа, и мне интересно, что может быть хорошим первичным ключом в этом случае.

В настоящее время я использую случайный guid в качестве первичного ключа.

Я ищу, чтобы получить все сообщения, соответствующие пользователю, я выполняю операцию сканирования.

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

Каким будет хороший первичный ключ здесь?

Спасибо!

Answer 1

Будет лучше, так как кажется, что вы часто делаете запрос на основе идентификатора пользователя. Сканирование стоит дорого, и его следует избегать, где это возможно. В AWS есть отличная статья о передовых методах выбора ключа раздела (первичного ключа). Ключевой вывод заключается в следующем:

1. Вы должны оценить различные подходы, основанные на потреблении данных и шаблон доступа , затем выбрать наиболее подходящий ключ с наименьшей вероятностью возникновения проблем регулирования.
2. Использование guid для раздела / первичного ключа является пустой тратой, если вы никогда не запрашиваете данные, используя его. Поскольку использование операции запроса (а не сканирования) требует запросов с использованием раздела / первичного (и ключа сортировки), вы хотите убедиться, что вы выбираете значение, которое вы используете для частого извлечения данных, а также обладаете достаточным количеством элементов для обеспечения ваших данных. распределяется по разумному количеству разделов.

Какие еще шаблоны доступа есть в вашем приложении? Судя по тому, что вы упомянули, userid кажется разумным выбором.