Вопрос, который вам нужно задать себе, касается не только «операции», но и того, как вы моделируете свои данные в DynamoDB. Т.е. как показанный вами массив JSON преобразуется в таблицу DynamoDB с хэш-ключами и ключами сортировки?
В то время как DynamoDB номинально поддерживает вложенные атрибуты, эта поддержка на самом деле только частичная, с некоторыми функциями (в частности, вторичными индексами)не поддерживаю их, поэтому, как я сейчас покажу, лучше их не использовать. Для моделирования ваших данных без вложенных атрибутов вы можете использовать ключ хеша"имя пользователя" и ключ сортировки"имя приложения". Каждый элемент в этой таблице является одним приложением, принадлежащим одному пользователю. Флаг «active» пользователя представляет собой небольшую проблему в этом моделировании, но вы можете реализовать его, используя поддельное имя приложения для хранения таких пользовательских параметров.
Это моделирование позволяет эффективно перечислять все приложения, принадлежащие одномупользователь (я полагаю, вам также нужна эта функция ...), но не все пользователи с определенным приложением. Но вы искали обратную операцию - чтобы получить список пользователей с указанным именем приложения.
Вы можете получить это обратное действие с помощью операции Scan, но это сканирование полной таблицы, и соответственноочень медленный и дорогой (вы будете платить за чтение всей базы данных, даже если пользователю фактически будет возвращена только часть данных).
Если эффективный поиск по приложениям важен, вам следует создать дополнительныйиндекс (GSI), хеш-ключ которого равен app-name, а ключ сортировки - user (т. е. порядок ключей, противоположный порядку в базовой таблице). Затем вы можете запросить этот индекс, чтобы получить - эффективно - список имен пользователей, которые имеют это приложение.
Обратите внимание, что такой GSI был бы невозможен, если бы вы настаивали на том, чтобы моделировать ваш элемент пользователя свложенные атрибуты, потому что GSI не поддерживают вложенные атрибуты в качестве ключа.