Question

我正在寻找设计DynamoDB表（由另一个MySQL数据库支持）以在我的Web应用程序中建立友谊系统的最佳方法。我有这些要求：检索所有用户朋友（分页应该是完美的）应该容易且具有成本效益，并且用户可以有“无限”的朋友。

我已经使用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每个项目的大小限制为400Kb，因此好友元素大约为70bytes，因此用户只能拥有5k好友。

所以我想到了另一种方法。创建仅用于友谊关系的表：

| 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

在我们的应用程序中，我们还为数百万用户提供了朋友模型，其中有超过4万个朋友。我建议建立一个双向关系条目，例如当A和B是朋友时，表应该具有两个条目，即A-> B的朋友和B-> A的朋友。友谊开始于发送对朋友的请求（邀请）然后，用户的另一端不得不接受邀请成为朋友或拒绝（删除）邀请，这意味着不想成为朋友，并且将来的请求者也将不能再次向目标用户发送朋友邀请。让我们从两个用户A作为请求者开始，然后B是与A希望与之成为朋友的目标。以下是友谊的流向：

从A到B的邀请 A->受邀B B <-邀请人A
B接受了A的邀请，然后他们都成为了朋友 A->朋友B B <-朋友A
如果B决定不与A成为朋友并拒绝了邀请 A <-Rejected_By B B->被拒绝在给定的时间点，两个用户之间应该只存在一种关系，并且您的表结构可能看起来像这样

DynamoDb表结构： Partition_Key：Requester_User_id Sort_Key：Target_User_id

其他表的列，根据您的需要可能会有用： Relationship_Status：S（已邀请，已邀请，被好友，拒绝，被拒绝） Request_Date：日期 since_Date：日期

在这种情况下，您可以获取给定用户的朋友列表，已发送邀请的用户列表，拒绝我的邀请的用户列表以及仍未对我的邀请执行任何操作的用户列表。

Answer 2

通常，以描述方式对友谊建模是一个图形问题。为了表示数据库中的图形，通常会转向图形数据库。

虽然您可以自己在DynamoDb之上构建图形数据库，也可以利用开放源代码实现JanusGraph，但Amazon现在提供了一个名为Neptune的托管图形数据库服务（请参见此处的功能：{{ 3}}）

设计DynamoDB表以建立友谊

2 个答案: