DynamoDB 分区键如何工作？答案

【问题标题】：How does the DynamoDB partition key work?DynamoDB 分区键如何工作？
【发布时间】：2018-01-16 19:35:02
【问题描述】：

我试图了解如何为 DynamoDB 表创建分区。

根据blog，“所有具有相同分区键的项目都存储在一起”，所以如果我有一个用户 ID 从 1 到 1000 的表，这是否意味着我将有 1000 个分区？或者这取决于“内部哈希函数”，但是我们怎么知道会有多少个分区呢？

它后来建议使用 1-10 的随机后缀来平均分配每个分区的数据，但它怎么知道它会查询 10 次给定的发票编号？只有当你有 10 个分区时？但在这种情况下，您可能有数千个发票编号，这意味着将创建相同数量的分区，并进行查询以查询发票编号

【问题讨论】：

我也对这条评论感到困惑，“所有具有相同分区键的项目都存储在一起”如果分区键是主键（他们在文章中这么说），你不能具有相同分区键值的多个项目。他们一定是在谈论哈希函数的结果。

标签： amazon-dynamodb

【解决方案1】：

创建 Amazon DynamoDB 表后，您可以以每秒读取数和每秒写入数指定所需的吞吐量。然后将在足以提供请求的吞吐量的多个服务器（分区）中配置该表。

您无法查看创建的分区数量——它完全由 DynamoDB 管理。随着数据量的增加或预置吞吐量的增加，将创建额外的分区。

假设您已请求每秒 1000 次读取，并且数据已在 10 台服务器（10 个分区）内部进行了分区。每个分区将提供每秒 100 次读取。如果所有读取请求都针对同一个分区键，则吞吐量将限制为每秒 100 次读取。如果请求分布在不同的值范围内，则吞吐量可以是完整的每秒 1000 次读取。

如果对同一个分区键进行了多次查询，则可能会导致 热分区，从而限制总可用吞吐量。

把它想象成一个在柜员窗口前排着行的银行。如果每个人都在一个柜员面前排队，那么可以为更少的顾客提供服务。将客户分布在许多不同的柜员窗口会更有效。用于分配客户的良好的分区键可能是客户编号，因为每个客户的编号都不相同。 分区键差可能是他们的邮政编码，因为他们都住在银行附近的同一区域。

简单的规则是您应该选择具有不同值范围的分区键。

见：Partitions and Data Distribution

【讨论】：

如果我想获取单个银行柜员完成了多少工作的记录怎么办？是否也可以（从同一张表）将客户编号作为分区键进行计算。
所以这意味着任何特定的分区键值都在一个分区上，只要该分区键没有太多的记录会超过最大分区大小，对吧？那么每条记录最好有一个唯一的分区键吗？排序键在哪里输入？显然不是为了分区推理。
@SamanthaAtkins SortKey 是可选的。但是，规则是 partitionKey 或 partitonKey+SortKey 的组合应该是唯一的。因此，如果一个表有 SortKey，那么它允许有多个具有相同 partitionKey 的项（前提是 sortKey 不同）。如果没有 sortKey，那么 partitionKey 应该是唯一的。

【解决方案2】：

根据 AWS DynamoDB 博客帖子：Choosing the Right DynamoDB Partition Key

选择正确的 DynamoDB 分区键是设计和构建可扩展且可靠的应用程序 DynamoDB。

什么是分区键？

DynamoDB 支持两种类型的主键：

分区键：也称为哈希键，分区键由单个属性组成。 DynamoDB 中的属性在其他数据库系统中的字段或列的多种方式。

分区键和排序键：称为复合主键或哈希范围键，这种类型的键由两个属性组成。这第一个属性是分区键，第二个属性是排序键。这是一个例子：

为什么需要分区键？

DynamoDB 将数据存储为属性组，称为项目。项目类似于其他数据库系统中的行或记录。动态数据库根据主键值存储和检索每个项目必须是唯一的。项目分布在 10 GB 存储单元中，称为分区（DynamoDB 内部的物理存储）。每张桌子有一个或多个分区，如图 2 所示。信息，请参阅了解 DynamoDB 中的分区行为开发者指南。

DynamoDB 使用分区键的值作为内部哈希函数。哈希函数的输出决定了将存储项目的分区。每个项目的位置是由其分区键的哈希值决定。

具有相同分区键的所有项目都存储在一起，并且对于复合分区键，按排序键值排序。动态数据库如果集合大小变大，将按排序键拆分分区超过 10 GB。

分区键建议

使用高基数属性。这些属性具有每个项目的不同值，例如电子邮件 ID、员工编号、 customerid、sessionid、ordered 等。

使用复合属性。尝试组合多个属性以如果符合您的访问模式，则形成唯一的密钥。例如，考虑一个带有 customerid+productid+countrycode 的订单表作为分区键和 order_date 作为排序键。

在读取流量较大时缓存热门项目。缓存充当低通滤波器，防止异常读取来自沼泽分区的热门物品。例如，考虑一个表具有产品交易信息。一些交易预计将在黑色星期五或黑色星期五等大型促销活动中比其他人更受欢迎网络星期一。

从预定范围内添加随机数/数字以进行大量写入 用例。如果您预计分区键的写入量很大，使用额外的前缀或后缀（预先确定的固定数字范围，比如 1-10）并将其添加到分区键。例如，考虑一张发票交易表。一张发票可以包含每个客户有数千笔交易。

【讨论】：

这个页面对我来说似乎很矛盾。它建议使用“高基数属性”，例如employeeID、customerID、orderID 等……但是在页面下方，它将关系数据库引擎生成的顺序 ID 或唯一 ID（在我看来就像完美的高基数属性）描述为“分区键的反模式”。我很困惑！
链接材料上给出的示例似乎担心在移植期间依赖于其他一些生成机制，这些机制在移植后难以支持，或者特别是某些外部事务。我不明白为什么应用生成的唯一 ID 不起作用。

【解决方案3】：

混淆点：

其他答案已经详细解释了 DynamoDB 如何创建分区。因此，在不涉及这些细节的情况下，让我解释一下在尝试了解 DynamoDB 中分区键和分区之间的关系时造成混淆的根本原因。

恕我直言，将密钥命名为“分区密钥”会造成混淆。它应该被称为主键。通过听到分区键，我们的大脑开始将每个分区键与一个分区相关联。一对一的关系。事实并非如此。如问题本身所述，密钥是“内部散列函数”的输入。函数的输出是对分区的实际引用。
因此，对于有 1000 个用户 ID（分区键）的表，DynamoDB 不需要有 1000 个分区。 它可能有 1/5/10 任意数量的分区，这由整体决定（容量单位）您已指定的设置。
当您增加吞吐量设置时，分区可能会增加。
当现有分区无法处理时，分区数量也会随着数据量的增加而增加。
因此，我们在 DynamoDB 中所说的分区键只不过是表示表中唯一项的主键（在复合键的情况下借助排序键）。它不直接与分区（由 SSD 支持的表的存储分配单元）一一对应。分区的实际键是通过将此分区键传递给内部 has 函数来获得的。

更多详情here.

【讨论】：

这解释了我昨天在尝试为我的“分区键”建模时遇到的困难，就像在其他 NoSQL 数据库中所做的那样。这应该是最好的答案。