Question

我已经构建了一个应用程序，它目前有一个相当标准的用户表，如下所示：

int id，varchar email，varchar password

如果我要将其切换到DynamoDB，那么我将如何创建此表？

如果我使用带有电子邮件地址的哈希密钥，那么我将无法提供更新电子邮件的功能，如果我使用哈希来存储ID，那么我需要使用扫描价格昂贵且受到1Mb限制的限制。

有什么建议吗？谢谢，标记

Answer 1

您是否说使用ID作为哈希会很昂贵，因为您需要按电子邮件字段进行过滤？

如果您需要按非键列过滤查询，则通常会为其创建索引。

DynamoDB 没有内置的 secundary index ，但实现自己的解决方案非常简单。

主表可以使用 ID 作为哈希，正如您所指出的那样，一个不同的表可以作为索引，它可以是：

varchar email, int id

发送电子邮件 secundary表的哈希键。如果允许多个用户使用相同的电子邮件，则可以使用 ID 作为范围，以简化操作，否则只需要一个简单的列。

Answer 2

使用不同的索引表将导致高维护。我从前任CTO那里得到了一个多余的模型。

对于您的表格：USER

<强> RDBMS：

id，电子邮件密码

1，senthil3569 @ stack.com，问

<强> DynamoDB：

KEY，id，电子邮件，密码

1,1，senthil3569 @stack.com，问

senthil3569 @ stack.com，1，senthil3569 @stack.com，问

不是存储一条记录，而是使用非索引列进行冗余存储以获取。

希望解决方案清楚。

Answer 3

使用哈希键ID（用户UUID）和其他属性创建一个User表。使用哈希键Email创建全局二级索引，您可以根据需要（用户活动状态，用户类型）选择排序键。

您可以获取它们并使用UUID（用户ID）更新用户
使用emailId获取用户
使用户处于活动状态而无需过滤器（按排序键）

UserTable:
   Type: AWS::DynamoDB::Table
   Properties:
     TableName: UserTable
     AttributeDefinitions:
       - AttributeName: id
         AttributeType: S
       - AttributeName: email
         AttributeType: S
       - AttributeName: status(optional sort key according to your requirement)
         AttributeType: S
     KeySchema:
       - AttributeName: id
         KeyType: HASH
     ProvisionedThroughput:
       ReadCapacityUnits: 5
       WriteCapacityUnits: 5
     GlobalSecondaryIndexes:
       - IndexName: UserDetail
         KeySchema:
           - AttributeName: email
             KeyType: HASH
           - AttributeName: status(option)
             KeyType: RANGE
         Projection:
           ProjectionType: ALL
         ProvisionedThroughput:
           ReadCapacityUnits: 5
           WriteCapacityUnits: 5

DynamoDB和用户登录表

3 个答案: