Относительная таблица к Dynamodb

Я долгое время работал с реляционными базами данных, а теперь собираюсь работать с DynamoDB. После, работая с реляционными базами данных, я изо всех сил пытаюсь разработать некоторые из наших текущих таблиц SQL в DynamoDB. В частности, решение о разделах и ключах сортировки. Попробую пояснить на примере:

Текущие таблицы:

Student: StudentId(PK), Email, First name, Last name, Password, SchoolId(FK)
School: SchoolId(PK), Name, Description

Я думал объединить эти таблицы в DynamoDB и использовать SchoolId в качестве ключа раздела, StudentId в качестве ключа сортировки. Тем не менее, я видел, что в некоторых подобных примерах в качестве ключа разделения используется StudentId.

И затем я понял, что мы используем «имя пользователя» в каждой функции входа в систему, поэтому приложение будет часто запрашивать «имя пользователя» (иногда с паролем или токеном авторизации). Эта ситуация заставляет меня задуматься; SchoolId как ключ раздела и имя пользователя как ключ сортировки.

Мне нужны некоторые идеи о том, что было бы лучше всего в этом случае, и некоторые предложения, которые помогут мне лучше понять концепции NoSQL и DynamoDb.


nosql amazon-dynamodb relational-database
person Orhun Karapinar    schedule 14.03.2019    source источник

Ответы (1)


arrow_upward
3
arrow_downward

В NoSql вы должны сначала попытаться перечислить все свои варианты использования, а затем попытаться смоделировать схему таблицы.

Ниже приведены варианты использования, которые я вижу в вашем приложении.

  1. Получить информацию о пользователе для одного пользователя с userId (пароль, возраст, имя, ...)

  2. Получить информацию о школе для пользователя с userId (className, schoolName)

  3. Собери всех учеников в одной школе.

  4. Соберите всех учеников в один класс одной школы.

На основе этого шаблона доступа я бы разработал схему

|    pk     |     sk        |   GSI1 PK          |  GSI1 SK            |  
|  12345    |    metadata   |                    |                     | Age:13 | Last name: Singh | Name:Rohan | ...
|  12345    |    schoolMeta |  SchoolName: DPS   | DPS#class5          | className:5 |

С помощью приведенной выше схемы вы можете решить идентифицированные варианты использования как

  1. Получить информацию о пользователе для одного пользователя с userId

    Select * where pk=userId and sk=metadata

  2. Получить информацию о школе для пользователя с userId

    Select * where pk=userId and sk=schoolMeta

  3. Собери всех учеников в одной школе.

    Select * where pk=SchoolId from table=GSI1

  4. Соберите всех учеников в один класс.

    Select * where pk=SchoolId and sk startswith SchoolId#className from table=GSI1

Но у данной схемы есть недостаток:

  1. Если вы хотите изменить название школы, вам придется обновить слишком много строк.
person best wishes    schedule 15.03.2019
comment
Спасибо за подробный ответ, это очень полезно. У меня есть еще два вопроса; для первого варианта использования: получить информацию о пользователе для одного пользователя с userId (пароль, возраст, имя, ...), приложение получит информацию о пользователе с именем пользователя вместо userID. В таком случае, как вы думаете, мне нужно использовать имя пользователя в качестве ключа раздела? И мой второй вопрос касается ключа сортировки, на что вы ссылаетесь, говоря метаданные в моем случае. Еще раз спасибо за подробный ответ. - person Orhun Karapinar; 16.03.2019
comment
pk должен быть ключом, который, по вашему мнению, вы попытаетесь выполнить выборку. На это нет никаких ограничений, единственная загвоздка в том, что он должен быть достаточно случайным, чтобы не возникло горячее разделение. metadata - это просто ключ, вы также можете использовать любое другое имя константы, единственное, что следует отметить, это то, что это имя не может быть изменено позже, и приложение должно знать это имя для выполнения выборки - person best wishes; 16.03.2019