Дизайн DynamoDB Стол для дружбы

Question

Я ищу лучший способ создать таблицу DynamoDB (поддерживаемую другой базой данных MySQL), чтобы создать систему дружбы в моем веб-приложении. У меня есть эти требования: это должно быть легко и экономически выгодно для всех пользователей-друзей (нумерация страниц должна быть идеальной), и у пользователя могут быть «неограниченные» друзья.

Я уже использую DynamoDB для отслеживания n-арного дерева между всеми моими пользователями, поэтому я подумал, что первым способом было расширить мою предыдущую работу.

{
  "children": [
    1,
    1
  ],
  "id": 0,
  "parentId": -1
}

Просто добавьте новый список в мой элемент:

{
  "children": [
    1,
    1
  ],
  "friends": [{"friend":"100","pending":"false","since":"2015-12-21T17:42:34Z","request":"2015-12-21T17:42:34Z"}],
  "id": 0,
  "parentId": -1
}

Таким образом, получить список всех друзей очень просто и экономически эффективно, но DynamoDB ограничен 400 КБ на элемент, поэтому элемент друга составляет более или менее 70 байт, поэтому у пользователя может быть только 5 КБ друзей.

Так что я подумала об этом другом методе. Создать таблицу только для дружеских отношений:

| User | Friend | Pending |         Since        |         Request       |
--------------------------------------------------------------------------
|   1  |    2   |  false  | 2015-12-21T17:42:34Z | 2015-12-21T17:42:34Z  |
|   2  |    1   |  false  | 2015-12-21T17:42:34Z | 2015-12-21T17:42:34Z  |

Так что здесь у Пользователя могут быть «неограниченные» друзья, но когда мне нужен список друзей, я должен прочитать всю таблицу, так что я думаю, что это не очень экономически эффективно, я могу сделать это даже с MySQL.

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

Answer 1

У нас также есть модель фридайнинга в нашем приложении для миллионов пользователей, у нескольких из которых более 40 тысяч друзей. Я бы посоветовал построить двунаправленные записи о взаимоотношениях, например, когда A и B являются друзьями, в таблице должно быть две записи: A -> Friend of B и B -> Friend of A. Фриндинг начинается с отправки запроса для друзей (приглашение). и затем другая сторона пользователя должна либо принять приглашение стать другом, либо отклонить (удалить) приглашение, что означает, что он не хочет быть другом, и в будущем запрашивающая сторона также не сможет снова отправить приглашение друга целевому пользователю. Давайте начнем с того, что два пользователя A - запросчик, а B - цель, с которой A хочет дружить. Ниже приведен поток дружбы:

1. Приглашение от А до Б A -> Приглашенный B B <- Invited_By A </li>
2. B принял приглашение от А, тогда они оба стали друзьями A -> Друг B B <- Друг A </li>
3. В случае, если B решил не быть другом A и отклонил приглашение A <- Rejected_By B B -> Отклонено A В данный момент времени между двумя пользователями должна существовать только одна связь, и ваша структура таблицы может выглядеть следующим образом

Структура таблицы DynamoDb: Partition_Key: Requester_User_id Sort_Key: Target_User_id

Столбец другой таблицы, который может быть полезен в соответствии с вашими потребностями: Relationship_Status: S (Приглашенный, Invited_By, Друг, Отклонить, Rejected_By) Request_Date: Date С даты: дата

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

Answer 2

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

В то время как вы можете построить базу данных графов на основе DynamoDb самостоятельно или используя реализацию с открытым исходным кодом JanusGraph , Amazon теперь предлагает службу базы данных управляемых графов под названием Neptune (см. Функции здесь: https://aws.amazon.com/neptune/features/)