Используйте один и тот же атрибут DynamoDB в качестве ключа ХЭША и диапазона

#amazon-dynamodb #amazon-dynamodb-index

Вопрос:

У меня есть DynamoDB, который индексируется одним цифровым ключом. Я хотел бы иметь возможность как извлекать элементы, имеющие определенное значение ключа, так и находить его максимальное значение путем запроса одного элемента в обратном порядке сортировки. Когда я пытаюсь определить 2 индекса, как в приведенном ниже отрывке, для одного и того же ключа, я получаю ошибку «Два ключа не могут иметь одинаковое имя».

 "KeySchema": [
  {
    "AttributeName": "logs",
    "KeyType": "HASH"
  },
  {
    "AttributeName": "logs",
    "KeyType": "RANGE"
  }
]

1. Каков формат и назначение атрибута ‘logs’?

2. Это целое число, которое приложение увеличивает на 1 каждый раз, когда добавляет новую запись. В SQL я бы использовал для этого ключ в стиле SERIAL или AUTOINCREMENT.

Ответ №1:

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

 "KeySchema": [
  {
    "AttributeName": "logs",
    "KeyType": "HASH"
  }
]

Чтобы запросить элемент, используя определенное значение ‘logs’, используйте GetItem.

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

Возможно, вы захотите пересмотреть свой подход. Если вы просто пытаетесь создать уникальные идентификаторы, это неправильный подход для DynamoDB. Что вам следует сделать, это:

Сгенерируйте длинный UUID
Выполните GetItem, чтобы убедиться, что UUID доступен. В DynamoDB это очень дешево и быстро
Используйте UUID

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

2. Вы могли бы перейти к созданию длинных случайных UUID и не использовать старые данные. По сути, вы заменяете медленное сканирование очень быстрым GetItem, чтобы проверить, доступен ли случайный идентификатор.

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

4. Отвечает ли это на ваш вопрос?

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