Amazon web services AWS DynamoDB表格设计：在表格中存储两个用户ID和详细信息

我正在构建一个应用程序，其中两个用户可以相互连接，我需要将该连接（例如友谊）存储在DynamoDB表中。基本上，连接表有两个字段：

• userIdA（散列键）
• userIdB（排序键）

我正在考虑在userIdB上添加一个索引来查询这两个字段。我应该存储一条记录（ALICE，BOB）或两条记录（ALICE，BOB；BOB，ALICE）的连接吗？第一个选项需要一个写操作和更少的空间，但我必须查询两次才能获得用户的所有连接。第二个选项需要两个写操作和更多的空间，但我只需要查询一次userId

用户表包含姓名和电子邮件等详细信息：

• 用户ID（散列键）
• 名称（排序键）
• 电子邮件

在我的应用程序中，我想在列表视图中用用户详细信息显示某个用户的所有连接。这意味着我有两个选择：

将已连接用户的用户详细信息也存储在连接表中，例如，在该表中添加两个名称字段。这很快，但如果用户名更改（从Facebook检索姓名和电子邮件），则详细信息无效，我需要更新所有条目

使用批处理Get请求查询每个userId的用户详细信息，以读取多个项目。这可能会慢一些，但我总是有最新的用户详细信息，不需要将它们存储在连接表中

那么，更好的解决方案是什么，或者是否有其他我可能忽略的优点/缺点

编辑 在谷歌对NoSQL数据库中的友谊表进行了一些研究之后，我发现了以下两个链接：

第一个链接建议使用两条记录双向存储连接（或友谊），因为这样可以更容易、更快地查询：

Connections:
    1 userIdA    userIdB
    2 userIdB    userIdA

第二个链接建议将重复数据的子集（“摘要”）保存到表中，以便只需一次查询就可以更快地读取。这意味着将用户详细信息也保存到连接表中，并将userid保存到用户表的属性中：

Connections:
    #    userIdA    userIdB    userDetails                    status
    1        123        456    { userId: 456, name: "Bob" }   connected
    2        456        123    { userId: 123, name: "Alice" } connected

Users:
    #     userId       name    connections
    1        123      Alice    { 456 }
    2        456        Bob    { 123 }   

这种数据库模型使查询连接变得非常容易，但如果某些用户详细信息可能发生更改，则似乎很难更新。另外，我不确定是否需要用户表中的userId，因为我可以很容易地查询userId

---

您认为该数据库模型如何？

我建议您在表中有以下字段：

• 用户ID（散列键）
• 名称（排序键）
• 电子邮件
• 连接（逗号分隔或userId数组，假设一个用户有多个连接）

---

这种结构可以确保数据的一致性。

一般来说，nosql数据库通常与两个假设相结合：

• 最终的一致性是可以接受的。也就是说，如果在更新过程中某些中间答案不正确，那么在应用程序设计中通常是可以接受的。也就是说，如果在alice成为Bob的朋友的几秒钟内，如果“is alice Bob's friend”返回true而“is Bob alice's friend”返回false，则可以

• 表现很重要。如果您使用nosql，通常是因为性能对您很重要。这几乎可以肯定，因为您关心最常见的操作的性能。（可能您遇到了一个问题，即某些不常见操作的性能太差，无法执行；在这种情况下，nosql通常不是解决方案）

• 您愿意降低不常见操作的速度，以提高常见操作的性能

那么，这如何适用于你的问题呢。首先，它表明最终答案取决于性能。也就是说，不管人们在这里说什么，正确的答案取决于你在实践中观察到的情况。你可以尝试多种选择，看看你得到了什么结果

关于你列举的具体选项

• 假设性能已经足够令人担忧，nosql是应用程序的合理解决方案，那么您关心的几乎肯定是查询性能，而不是更新性能。如果您让更新变得更慢、更昂贵，以便查询更快，您可能会很高兴。这就是重点

• 您可能可以处理带外的更新—这就是一致性最终可能适合您的方式。您可以将更新操作提交到SQS队列，而不是在页面加载期间处理它们。因此，如果有人单击“确认好友”按钮，您可以排队请求实际更新数据库。即使这涉及到重建他们的用户行、重建朋友行，甚至更新他们有多少朋友的一些计数，这也是可以的

• 在每个方向上存储一个朋友行可能是有意义的，因此您只需要一个查询

• 将用户信息（如姓名和图片）存储在友谊行中复制的好友列表中可能是有意义的。请注意，每当名称或图片更改时，您都需要更新所有这些行

• 将好友存储在用户表中是否有意义还不太清楚。那可能会变大。此外，要保证最终的一致性可能很难。考虑一下如果你同时处理两个用户的友情更新会发生什么。一旦尘埃落定，你就不要以矛盾告终，这一点非常重要

• 每当您有非规范化的数据时，例如在每个方向复制行，或者将用户信息复制到友谊表中，您都需要某种方法来重新验证和修复数据。您希望编写的代码可以在后台扫描系统中由bug或崩溃的活动引起的不一致，并修复它们

---

不幸的是，这不是一个