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