Amazon dynamodb 对象的DynamoDB表结构

各位， 对于以下对象，您建议DynamoDB表结构是什么？大约有200万个对象，需要通过电子邮件和/或组织进行搜索

{
  email: 'foo@bar.com',
  organization: 'foobar'
}

您会将哈希/范围键设置为什么？我需要能够执行以下操作：

• 检索特定组织的所有电子邮件
• 删除特定的

  电子邮件

我应该向表中添加一个随机id参数吗？我认为以下是正确的方法：

• organization

  是散列键，

  email

  是范围键

---

谢谢

看起来这两种方法中的任何一种都能很好地分发对象和散列键，所以我不知道这两种方法本身是否一定是更好的散列键。我认为，您需要检索一个

组织的所有特定电子邮件这一事实使得它更适合作为散列键。您可以使用组织进行查询，以获取组织的所有电子邮件

注意，为了支持您描述的用例，您需要一个全局二级索引。可能有助于说明原因，但假设您使用
Organization
作为表哈希键，则需要
email
上的全局二级索引来检索特定电子邮件（或检索该项目以删除它）
 问题在于配置的容量和扫描操作。如果您有100万条记录，每条记录85字节，总计86000 KB，这将需要21000次已配置的读取

在这一点上，为了降低成本，我认为除了采用以下结构外，别无选择：

| Hash Key | Range Key    | Secondary Range Key |
| 1        | organization | email               |

换言之：

| Hash Key | Range Key    | Secondary Range Key |
| 1        | foo          | asdf@foo.com        |
| 1        | bar          | asdf@bar.com        |
| 1        | foo          | fdsa@foo.com        |

这意味着您总是知道您的HashKey。使用它，您可以查询特定的RangeKey

想法？
在基本表中，使用电子邮件作为哈希键，因为它比部门更随机，所以可以很好地进行分区

创建一个以组织为哈希键的GSI

1） 检索特定组织的所有电子邮件

使用hashkey等于目标组织的方式查询GSI

2） 删除特定电子邮件

很容易做到，因为电子邮件是基本表的哈希键

低配置吞吐量仍能正常工作。唯一的影响是你的扫描需要更长的时间。如果读取配置的吞吐量读取为10，则扫描将花费大约：

21000/10=2100秒

我认为对于扫描操作，您可以设置它应该返回多少项的限制。结果还将包括一个lastEvaluatedKey，您可以在下一页的扫描调用中提供它。
因此，如果
organization
是hashKey，而
email
是rangeKey，那么我必须进行表扫描以获取所有组织，并进行查询以获取特定组织的电子邮件。正确吗？因此，如果我有100万条记录，每个记录86字节，即86000 KB，这意味着我需要21500个已设置的读取！？如果hashKey是一个已知的值，比如说
1
，那么你可以将rangeKey作为你的
组织
，将二级索引作为你的
电子邮件
，或者这是一个黑客行为吗？Amazon非常明确地指出，你的表hash key应该相对统一地分配你的项目，所以我不认为对所有项目使用相同的键是一个好主意。我建议先弄清楚应用程序需要支持哪些查询，然后用本地和全局二级索引适当地设计表。在某些情况下，这可能是不可避免的，但如果可以避免的话，你不想做
Scan
s。@RyanM用我的例子，我正在避免做任何扫描。只有查询。是的，读取数据未分发。。。但这似乎是唯一的选择。无论是
scan
还是拥有一个已知的hashkey如果你避免进行扫描，你不需要像你在对我的答案的评论中建议的那样读取所有100万条记录。