#amazon-dynamodb #dynamodb-queries
#amazon-dynamodb #dynamodb-запросы
Вопрос:
Допустим, у меня есть таблица Dynamo DB с именем ‘student_course’. Я хочу сохранить курс, который каждый студент проходит в университете. Один студент может посещать несколько курсов одновременно, и на одном курсе может одновременно обучаться несколько студентов. Так что в основном это мульти-отображение.
Мой шаблон доступа к данным имеет только один вариант использования —
- получить запись об одном студенте и одном курсе за раз, то есть получить данные для каждой комбинации идентификаторов студента и идентификатора курса. Гарантируется, что для комбинации идентификатора студента и идентификатора курса доступна только одна запись.
Чтобы достичь этого, я могу хранить данные следующими 2 способами —
- Ключ раздела = {идентификатор студента}, ключ сортировки = {идентификатор курса}
- Ключ раздела = «Идентификатор студента:{идентификатор студента}_courseId:{идентификатор курса}», ключ сортировки не существует
Мой вопрос в том, какой запрос будет работать лучше, если есть какая-то разница, то есть? Какой из них я должен предпочесть другому и почему?
Ответ №1:
С точки зрения проектирования для DDB
повышения производительности, Get API
это ключ к возможности извлечения данных DDB за миллисекунды, поэтому логично проектировать ваши данные на основе этого API
Таблица с ключом раздела ключ сортировки
Partition Key | Sort Key
-------------- -------------
Course1 | Student1
Course1 | Student2
Преимущество:
- Возможность использовать
Get API
для получения одной записи с помощьюPartition Key
иSort Key
, например, получить одну запись, где ключ раздела = «Курс1» и ключ сортировки = «Студент1» - Возможность использовать
Get API
для получения списка записей только поPartition Key
, например, Получить все записи, где ключ раздела = «Курс1»
Недостаток:
- Если вы знаете только
Sort Key
(т.е. Студент), а неPartition Key
(т.е. Курс), вы не сможете использоватьGet API
для извлечения записи только с помощьюSort Key
Примечание: В целом, эффективность (такая, что запросы не попадают ReadThroughput
на «крышу» исключения легко) Get API
запросов DDB в значительной степени связана с уникальностью и распределением Partition Key
. Чем больше ключей раздела у вас есть и распределены, тем выше производительность
Таблица только с ключом раздела
Partition Key Only
--------------------
Course1#Student1
Course1#Student2
Преимущество:
- Возможность использовать
Get API
для получения одной записи,Partition Key
например, получить одну запись, где ключ раздела = «Курс1 #Студент1»
Недостаток:
- Не сможет использовать
Get API
для получения списка записей, используя только подмножествоPartition key
, например, получить список записей, где ключ раздела = «Курс1»
О GSI
Примечание: Обычным сценарием является добавление глобального вторичного индекса к таблицам для поддержки Get API
вызовов с использованием альтернативного ключа, например, получение списка записей, где GSI Partition Key
= название курса
Partition Key Only | Non Key Attribute (Course) For GSI
--------------------- ---------------------------
Course1#Student1 | Course1
Course1#Student2 | Course1
У вас может быть до 20 GSI
индексов (мягкое ограничение), с возможностью снять это ограничение с помощью запроса в службу поддержки
Partition Key Only | Non Key Attribute (Course) For GSI | Lecturer (For GSI 2)
--------------------- ------------------------------------ ---------------------
Course1#Student1 | Course1 | Lecturer1
Course1#Student2 | Course1 | Lecturer1
Заключение
Я бы создал таблицу, в которой было бы как можно больше уникальных значений для Partition Keys
, насколько это возможно, если производительность является ключевой, т.е. Ключ раздела = Курс1 # Студент1 ПРОТИВ ключа раздела = Курс1, ключ сортировки = Студент1
Добавляйте GSIs
в таблицы по требованию, если вам нужно выполнить запрос по альтернативному ключу
(Исторически GSIs
они были ограничены 5 на таблицу и должны были быть указаны при создании таблицы, но с тех пор эти ограничения сняты)