dynamo db 中唯一哈希键和范围键之间的比率

Question

如果我选择我的散列键和范围键，使得唯一散列键的数量非常少（最大值：1000），而有更多的唯一范围键，会不会有问题？

唯一哈希和范围键的数量之间的比例是否影响信息检索的性能？

Answer 1

在以下情况下，为每个散列键设置多个范围键应该不是问题：

1. 哈希键的数量不会太少
2. 您的访问权限随机分布在哈希键中
3. 你不需要扩展到极端水平

根据AWS Developer Guidelines for Working with Tables：

预配置吞吐量取决于主键选择和单个项目的工作负载模式。在存储数据时，DynamoDB 将一个表的项目划分为多个分区，并主要根据哈希键元素来分配数据。与表关联的预配置吞吐量也在分区之间平均分配，不会跨分区共享预配置吞吐量。

本质上，每个散列键都驻留在单个节点（即服务器）上。实际上，它被冗余存储以防止数据丢失，但在本次讨论中可以忽略这一点。当您提供吞吐量时，您是在间接确定散列键分布的节点数量。但是，无论您提供多少吞吐量，单个节点可以处理的单个哈希键都会受到限制。

解释我的三个警告：

1. 哈希键的数量并不太低
您提到最多 1000 个哈希键，但关注的是最小值是多少。例如，如果只有 10 个哈希键，那么您将很快达到每个键的吞吐量限制，而实际上不会实现预配置的吞吐量。

2. 你的访问是随机分布在散列键上的
如果有少量的“热”键，你有多少散列键并不重要。也就是说，如果您经常只读取或写入散列键的一小部分，那么您将达到存储这些键的节点的吞吐量限制。

3. 你不需要扩展到极端级别
即使假设你有 1000 个不同的哈希键并且你的访问是随机分布在它们之间，如果你需要扩展到极端级别你最终会达到一个点，每个哈希键都在单独的节点。也就是说，如果您提供足够的吞吐量以将每个散列键分配给一个单独的节点（即您有 1000 多个节点），那么任何超出该级别的吞吐量都将无法实现，因为您将达到每个节点对每个键的限制.

范围键与散列键的比率应该对获取、扫描和查询性能几乎没有影响。

我的理解是，每个散列键的范围键都有效地存储在某种可以很好扩展的索引中。但是，请记住，给定散列键的所有行都存储在同一个节点上，因此您可能会遇到给定散列键数据过多的情况。DynamoDB 中的AWS 限制指出：

对于具有本地二级索引的表，项集合大小有限制：对于每个不同的哈希键值，所有表项和索引项的总大小不能超过 10 GB。根据您的项目大小，这可能会限制每个散列值的范围键数。