Согласно документу 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 для обоих типов пользователей?
