Производительность запросов DynamoDB с уникальным ключом раздела по сравнению с уникальным ключом раздела сортировки

#amazon-dynamodb #dynamodb-queries

#amazon-dynamodb #dynamodb-запросы

Вопрос:

Допустим, у меня есть таблица Dynamo DB с именем ‘student_course’. Я хочу сохранить курс, который каждый студент проходит в университете. Один студент может посещать несколько курсов одновременно, и на одном курсе может одновременно обучаться несколько студентов. Так что в основном это мульти-отображение.

Мой шаблон доступа к данным имеет только один вариант использования —

  1. получить запись об одном студенте и одном курсе за раз, то есть получить данные для каждой комбинации идентификаторов студента и идентификатора курса. Гарантируется, что для комбинации идентификатора студента и идентификатора курса доступна только одна запись.

Чтобы достичь этого, я могу хранить данные следующими 2 способами —

  1. Ключ раздела = {идентификатор студента}, ключ сортировки = {идентификатор курса}
  2. Ключ раздела = «Идентификатор студента:{идентификатор студента}_courseId:{идентификатор курса}», ключ сортировки не существует

Мой вопрос в том, какой запрос будет работать лучше, если есть какая-то разница, то есть? Какой из них я должен предпочесть другому и почему?

Ответ №1:

С точки зрения проектирования для DDB повышения производительности, Get API это ключ к возможности извлечения данных DDB за миллисекунды, поэтому логично проектировать ваши данные на основе этого API

Таблица с ключом раздела ключ сортировки

 Partition Key | Sort Key    
-------------- -------------
Course1       | Student1
Course1       | Student2
 

Преимущество:

  1. Возможность использовать Get API для получения одной записи с помощью Partition Key и Sort Key , например, получить одну запись, где ключ раздела = «Курс1» и ключ сортировки = «Студент1»
  2. Возможность использовать Get API для получения списка записей только по Partition Key , например, Получить все записи, где ключ раздела = «Курс1»

Недостаток:

  1. Если вы знаете только Sort Key (т.е. Студент), а не Partition Key (т.е. Курс), вы не сможете использовать Get API для извлечения записи только с помощью Sort Key

Примечание: В целом, эффективность (такая, что запросы не попадают ReadThroughput на «крышу» исключения легко) Get API запросов DDB в значительной степени связана с уникальностью и распределением Partition Key . Чем больше ключей раздела у вас есть и распределены, тем выше производительность

Таблица только с ключом раздела

 Partition Key Only   
--------------------
Course1#Student1
Course1#Student2
 

Преимущество:

  1. Возможность использовать Get API для получения одной записи, Partition Key например, получить одну запись, где ключ раздела = «Курс1 #Студент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 на таблицу и должны были быть указаны при создании таблицы, но с тех пор эти ограничения сняты)