Как структурировать AWS DynamoDB Table с помощью Cognito

Question

Я пытаюсь сделать что-то, что было бы относительно просто для реляционной базы данных, но я не знаю, как это сделать для нереляционной базы данных.

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

У меня есть таблица, называемая задачами, в которой используется идентификатор пользователя из токена авторизации, предоставленного AWS Cognito.Мне интересно, как я могу вернуть информацию о пользователе.Я не хочу полагаться на Cognito, просто вызывая его каждый раз, когда пользователь отправляет запрос.Итак, я подумал бы создать другую таблицу для хранения всей пользовательской информации.Это, однако, не очень нереляционный способ ведения дел, поскольку JOINS такие плохие.

Итак, мне было интересно, стоит ли мне делать что-либо из следующего
a) Использование RDS вместо
b) Не используйте Cognito и не настраивайте свою собственную систему аутентификации
c) Просто выполняйте JOIN с таблицей, содержащей всю информацию о пользователе
d) Каждый раз выполняйте запрос к Cognito

Answer 1

Хотя мне лично нравится идея cognito, в настоящее время у нее есть несколько существенных недостатков ...

1. Вы не можете выполнять резервное копирование / восстановление пула пользователей, не потеряв их пароль, также вы должны выполнить собственное резервное копирование / восстановление. Обходной путь - сохранить пароль пользователя в пользовательском атрибуте Cognito.

2. Я ожидал, что с помощью api gateway / lambda authorizer будут все пользовательские данные в контексте лямбды, но их там нет. Или что-то не так с отображением шаблона шлюза API ?

Хорошая вещь: API-шлюз / лямбда-авторизатор, может кэшироваться до часа, больше не будет вызывать функцию авторизатора, которая кажется основной функцией.

3. Не очень хорошо работает с облачной информацией: при каждом обновлении атрибута воссоздается пул пользователей без восстановления пользователей, что приводит к потере пользователей.

Я использовал его только в одной реализации и в итоге дублировал пользователей в DynamoDB.

С тех пор я избегаю этого. Я бы хотел, чтобы они решили эти проблемы, так как похоже, что сервис включается в каждый проект, экономя массу времени.

Читая твой пост, я задавал себе те же вопросы и не уверен в ответе. 10

Цены кажутся справедливыми.

Заданные по умолчанию 5 запросов в секунду для получения информации о пользователе кажутся странными, так как они потребляются при загрузке одной страницы при выполнении нескольких запросов AJAX API.

Answer 2

Для этого в DynamoDB нет необходимости в другой таблице.Если шаблоны доступа диктуют, что вы храните информацию в другом объекте, пусть будет так, но, скорее всего, она должна быть в той же таблице.Похоже, вам нужно два разных типа элементов в одной таблице.

Для задачи PK userid и SK задачи :: your-task-id.Это позволит вам легко получить все задачи пользователя или даже определенную задачу, если вы знаете идентификатор задачи.Вы могли бы даже иметь атрибут, который является меткой времени, а затем иметь GSI, который представляет собой userID в качестве PK и метку времени в качестве SK.тогда вы можете использовать оператор begin_with на SK и «разбивать на страницы все задачи пользователя, которые находятся в месяце 2019-04».

Для информации пользователя, userID должен быть PK и SKбыть user_info, а атрибуты - информацией о пользователе.

Единственная проблема для этого заключается в том, что вы должны идти на крайние меры, и один пользователь выполняет тысячи операций в секунду.например, "Все твиты от очень популярных знаменитостей".Если у вас есть такой вариант использования, есть и другие способы, например, write sharding .Это всего лишь примеры для вас, чтобы играть.Не зная всех ваших шаблонов доступа, я не могу смоделировать все, что вы, возможно, захотите сделать.Я настоятельно рекомендую вам посмотреть эту презентацию от reInvent 2018 .