Как спроектировать схему ключей, чтобы иметь только одну таблицу DynamoDB на приложение?

Согласно документу DynamoDB: https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/bp-general-nosql-design.html

"В приложении DynamoDB следует поддерживать как можно меньше таблиц. Для большинства хорошо разработанных приложений требуется только одна таблица."

Но по моему опыту вы всегда должны делать обратное из-за конструкции ключа раздела.

Давайте рассмотрим следующую ситуацию. У нас есть несколько пользовательских ролей, например, "админ", "менеджер", "работник". Обычный рабочий процесс администратора относится к данным менеджера CRUD, где операция чтения заключается в получении не одного менеджера, а всего списка менеджеров. То же самое для менеджера - он CRUDs рабочих данных. У нас есть только два сценария использования ключа для обоих случаев:

  • получить список всех элементов (ключ элемента не имеет значения)
  • работать с конкретным элементом, используя его полный ключ.

Естественно, у нас должен быть равномерно распределенный ключ раздела (как подчеркивает документ), поэтому мы не можем выбрать для него роль пользователя и должны использовать идентификатор пользователя. Поскольку в качестве ключа раздела у нас уже есть некоторый случайный идентификатор, нам совершенно не нужен ключ сортировки, поскольку он просто не работает - мы уже обращаемся к одному пользователю, используя только часть ключа раздела. В этот момент мы понимаем, что идентификатор пользователя работает как чудо для операций CUD, но для каждой операции R нам нужно сканировать всю таблицу и затем фильтровать результат по роли пользователя, что неэффективно. Как это можно улучшить? Очень естественно - пусть для каждого типа пользователя будет только собственная таблица! Затем мы просканируем список менеджеров из API администратора и список работников из менеджера.

Я использую DynamoDB почти год и до сих пор не могу его получить. Для меня реальность такова, что в реальных сценариях ключ сортировки - это то, что вы никогда не сможете использовать (у меня был единственный реальный случай - получить доступ к таким элементам, как "соглашения", которые принадлежат двум пользователям разных типов одновременно, поэтому первичным ключом был {partion: "managerId", sort: "userId"}, а вторичным глобальным индексом был {partition: "userId", sort: "managerId"}, поэтому я мог эффективно запрашивать весь список соглашений конкретного менеджера или всех конкретных пользователей список соглашений, предоставляющий только соответствующий менеджер или идентификатор пользователя для запроса. Подход обсуждается в документе здесь: https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/bp-adjacency-graphs.html).

Я чувствую, что вообще не понимаю эту концепцию. Что может быть эффективным способом схемы ключей в приведенном примере, чтобы использовать только одну таблицу DynamoDB для обоих типов пользователей?

Ответ 1

у вас может быть схема типа

user_id, role, <other columns>

где

  • user_id = хэш-ключ
  • роль = GSI хэш-ключ

Таким образом, вы можете прочитать и получить список всех менеджеров, запросив GSI

С GSI DynamoDb создает другую таблицу и поддерживает ее, поэтому вам не нужно обслуживать несколько таблиц.

Дайте знать, если у вас появятся вопросы