UUID как первичный ключ в DynamoDB - хорошая или плохая идея?

Question

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

• ключ раздела: user_id
• ключ сортировки: entity_id

В основном, шаблоны доступа:

1. Получить конкретное сообщение от конкретного пользователя.
2. Получить конкретный комментарий от конкретного пользователя.
3. Список всех сообщений от конкретного пользователя.
4. Список всех комментариев от конкретного пользователя.
5. Список всех сущностей (сообщение или комментарий) определенного пользователя.

Какие преимущества я получу, если вместо этого использую более случайный идентификатор в качестве ключа раздела и просто использую GSI для своих шаблонов доступа выше?

• ключ раздела: pseudo_random_id (в действительности это будет UUID. Пожалуйста, не обращайте внимания на то, что это НЕ UUID на рисунке).
• GSI:
  • разделключ: user_id
  • ключ сортировки: entity_id

Answer 1

Вам не нужны UUID или псевдослучайный идентификатор.

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

(Почему вы должны ограничивать скорость, которую пользователь может публиковать? Вы не хотите, чтобы злоумышленник мог создавать новые сообщения каждые несколько миллисекунд - у вас должен быть какой-то предел скорости в качестве защиты от отказа в обслуживании атаки.)

Answer 2

Использование UUID ничего не делает для вас ...

Не имеет значения, насколько случайным является ключ раздела.Все, что имеет значение, это то, сколько у вас есть отдельных ключей разделов и объем / скорость ввода для этого ключа раздела.

Другими словами, уникальное значение является уникальным значением.Динамо не заботится, что это 16, 36 или 128 байт.

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