Стратегия ключа раздела Dynamodb - несколько владельцев - PullRequest
Новая
       26

Стратегия ключа раздела Dynamodb - несколько владельцев

0 голосов
/ 29 января 2019

Мне сложно понять, какие атрибуты лучше всего использовать в качестве ключа раздела для моего приложения, поскольку я новичок в DynamoDB.Я пытаюсь использовать DynamoDB для простого приложения, где пары пользователей выбираются случайным образом, чтобы встретиться и познакомиться друг с другом.Мне нужно выбрать подходящие таблицы и стратегии разбиения, которые помогут при следующем запросе:

Получить собрание (введение), на которое был приглашен пользователь.Он должен показать все детали встречи, включая другого приглашенного пользователя.

Из того, что я понял из документов, чтобы "запросить" элемент, я могу использовать только ключи в выражении запроса,Кроме того, хорошим ключом раздела является тот, который имеет большую мощность и способствует равномерному распределению в пропускной способности чтения / записи.Я думал о создании таблицы Meetup, но я с трудом выбираю ключ раздела, особенно когда встреча «принадлежит» 2 пользователям, и элемент события истечет (будет неактивен) после встречи, поэтому я неуверен, что использование meetupID хорошая идея.Но я думал об использовании двух таблиц как таковых:

Таблица приглашений:

  • userId (ключ раздела)
  • eventId (ключ сортировки)
  • некоторый атрибут
  • другой атрибут

Таблица MeetUp:

  • meetupId (ключ раздела) -> Я сомневаюсь в этом
  • InviteUsers (это будет массив пользовательских объектов)
  • отменено
  • meetDate

СВ этом решении необходимо выполнить 2 запроса, чтобы сначала получить последний идентификатор события, а затем получить сведения о событии.Кажется ли это хорошим подходом?MeetupId - хороший раздел?Есть ли лучшее решение для этого?

Ответы [ 2 ]

0 голосов
/ 29 января 2019

Вы можете использовать эту схему. 

| ID (PK)   | SortKey          | MeetupId (GSI1) | 
| User1234  | metadata         |                 | age:28 | nationality: US | interestedIn:Economics | name:Tim  | ...
| User1234  | meetup#meet1234  |      meet1234   | ...
| meet1234  | metadata         |      meet1234   | location:Central Park | time:122323223 | ...
| User4567  | metadata         |                 | age:27 | nationality: US | interestedIn:Arts | name:Kira  | ...
| User4567  | meetup#meet1234  |      meet1234   | ...
...
Id is sortkey for GSI1

это решит варианты использования, такие как

  1. Получить все встречи User1234 приглашен на Select * where id=User1234 and SortKey startswith meetup

  2. Получить все встречи, на которые пользователь 1234 приглашен в течение 10 дней Select * where id=User1234 and SortKey startswith meetup filter eventDate < today +10

  3. Получить userInfo для пользователя1234 Select where id=User1234 and SortKey=metadata

  4. Получить всех приглашенных на Meet1234 Select * where MeetupId=meet1234 and SortKeystarts with User From Table GSI1

  5. Получить всю информацию о событии meet1234 Select * where MeetupId=meet1234 From Table GSI1

Неразрешенные варианты использования:

  1. Получите все встречи, происходящие сегодня.

В NoSql схема должна быть основана на сценариях использования.

0 голосов
/ 29 января 2019

Если количество встреч на пользователей соответствует нормальному распределению, вы можете безопасно иметь что-то вроде этого:

  • A users table :: Keyition key = user_id(некоторый UUID)
  • A встречи таблица :: ключ раздела = meetup_id (немного UUID)
  • A meetup_invites таблица: ключ раздела = user_id,Ключ сортировки = meetup_id

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

...