Дизайн таблицы DynamoDB для социальной сети - PullRequest
Новая
       17

Дизайн таблицы DynamoDB для социальной сети

0 голосов
/ 12 июня 2019

У меня проблема с мышлением в DynamoDB. Моя структура выглядит следующим образом:

  • первичный ключ = "id"

  • sort key = "sort" У меня есть сообщения, пользователи и отношения "пользователь A, следующий за пользователем B".

Пользователи:

  • ID = 1234
  • рода = "USER_USER_1234"
  • name = "max" (например)

-

  • ID = 3245
  • рода = "USER_USER_3245"
  • имя = "Томь"

Сообщение:

  • ID = 9874

  • sort = "POST_POST_1234 (потому что он создан идентификатором пользователя 1234)

  • createdAt = 1560371687

После:

  • ID = 1234

  • sort = "USER_FOLLOW_3245"

-> Том следует за Максом (но Макс не за Томом)

Как мне составить запрос на получение всех сообщений от людей, за которыми следует том (id = 3245)? Так в моём случае почтовый идентификатор 9874? Мой подход заключался в том, чтобы поместить GSI, где sort является первичным ключом, а id - ключом сортировки (чтобы я мог запросить всех людей, за которым следует пользователь A), а затем получить все сообщения от пользователей (с помощью того же GSI) и отсортировать результат по второму индексу, где createAt - это ключ сортировки. Проблема в том, что для этого нужно много запросов (представьте, что пользователь А будет подписываться на 10000 человек, и все они будут создавать сообщения). Есть ли методика или подход к проектному мышлению, который вы могли бы порекомендовать для этой ситуации? Мой второй подход заключался в индексации всей таблицы приложения для упругого поиска и выполнения вложенного запроса. Будет ли это иметь больше смысла? Или вы бы порекомендовали использовать базу данных другого типа, например AWS neptune?

1 Ответ

1 голос
/ 18 июня 2019

В Amazon Neptune это было бы так просто: 

g.V(3245).E('post')

Приведенный выше запрос вернул бы итератор для всех вершин, соединенных меткой Edge "post", начиная с вершины сID "3245".Вы можете еще усилить его, либо проецируя определенные свойства (.property('name')) из этих вершин, либо материализуя всю вершину (.valueMap()).Это всего лишь синтаксис Gremlin, и вы можете легко сделать то же самое, используя SPARQL, и Amazon Neptune поддерживает их оба.

Более важный вопрос для вас - оценить все типы запросов, которые вы хотите выполнить для ваших данных, и посмотреть, имеет ли смысл моделирование их в графовой базе данных.Если это так, то вам лучше использовать Neptune, а не что-то нестандартное, используя смесь других продуктов.Запросы / обход данных с высокой степенью связи, навигация по отношениям и т. Д. Являются одними из классических вариантов использования графической модели данных.

...