2017-02-18 6 views
0

Я создаю приложение, используя AWS Mobile HUD и связанные услуги, наиболее заметно Cognito & DynamoDB. В настоящее время у меня возникла проблема с настройкой схемы, которая позволяет мне хранить информацию о пользователе на элементах DynamoDB (или наоборот).AWS DynamoDB запомнить товар для пользователя

Сценарий

Run 1

  1. Пользователь А тянет список [RootItem] = {RootItem_1, RootItem_2, RootItem_3} из DynamoDB (проверить: работает отлично)
  2. пользователя A либо распускает RootItem_1 (знак как 'не интересует' в приложении)

Run 2

  1. Пользователь А в приложении
  2. Пользователь А тянет список [RootItem] = {}
  3. пользователь А должен получить только RootItems, которые являются не отклонил
  4. Список поставляется клиенту должен быть {RootItem_2, RootItem_3}

Будучи новым для нереляционных данных/NoSQL, я не что лучший способ приблизиться к этому. Возможные идеи:

  • магазин идентификатор пользователя на RootItem_1, чтобы исключить его сканирования [вопрос: будет потенциально тысячи пользователей увольняет тот же пункт]
  • магазин UUID из RootItem_1 в USERDATA на Cognito, кэш локально перед притяжением и исключить uuid's from pull
  • Создать таблицу с исключениями/нарушениями [userid, rootItem_uuid], запросить это первым, чтобы получить список пользовательских исключений. > потенциальная проблема с производительностью?

Было бы здорово получить рекомендации относительно наилучшего подхода к обработке в среде NoSQL.

+0

Было время, когда я пробовал dynamodb, но вам следует избегать операций SCAN, если это возможно, очень тяжело. Вы изучали глобальные вторичные индексы? Это может уменьшить необходимость в SCAN-операциях и позволит вам запрашивать вместо этого таблицу. http://docs.aws.amazon.com/amazondynamodb/latest/developerguide/GuidelinesForGSI.html –

+0

Я знаю, что сканирование не является совершенным, проблема в том, что мне приходится делать довольно сложные запросы, которые кажутся невозможными с использованием запроса. aka {property 1 == x && свойство 2 beween (a, b) или (c, d) && свойство 3 = a или b, ...} всего, что я хочу фильтровать для диапазонов и совпадений на 6-7 разных свойства, с операциями OR и AND, и до сих пор я думаю, что с запросом это невозможно. –

+0

Именно по этой причине мы вышли из DynamoDB.Это отлично, когда вам не нужно делать «расширенные» запросы, но вы сталкиваетесь с стеной, когда вам нужно еще несколько условий. Это и вместе с этим: http://stackoverflow.com/questions/41520123/getting-full-access-to-dynamodb-from-my-ios-app-using-aws-cognito-developer-iden/41676547#41676547 проверьте мой ответ ПРИМЕЧАНИЕ по этому вопросу. Поскольку вы используете Cognito и iOS, я предполагаю, что вы напрямую подключаетесь к DynamoDB, что тоже нужно знать (не отпугивать вас). –

ответ

0

Это зависит от количества или RootItems и количества активных (не уволенных) RootItems для каждого пользователя. Но я бы сохранил список RootItems (или рефери к нему) и сохранил его в таблице для каждого пользователя и поддерживал этот список, поскольку пользователь отклоняет элементы. Или даже возможно, что большинство предметов уволены, а затем это будет список сохраненных элементов для пользователей?

+0

В принципе, пользователь видит список всех предметов, которые лежат в будущем, которые соответствуют его критериям. Затем он переходит через всех из них, увольняя или «запоминая» их. В идеальном мире (успешное предприятие) может быть возможно ~ 1000 + rootItems, которые соответствуют критериям пользователя. Я также склоняюсь к этому решению, имею дополнительную таблицу, в которой идентификатор пользователя является ключом, и я храню {userId, rootItemID, date} и периодически очищаю «старые» отклоненные элементы, поскольку они больше не нужны, поскольку прошлые данные не интересны приложение. Я попытаюсь настроить его таким образом и посмотреть, работает ли он. –

+0

работает отлично, еще не 100%, если это самый эффективный способ сделать это. Я решил создать ссылки на DynamoDB, загрузить их 1 раз при входе в систему, а затем сохранить локальную ссылку и локально выполнить фильтрацию –