如果我选择我的哈希键和范围键以使得唯一哈希键的数量非常低（最大值：1000），同时还有更多唯一范围键，这是一个问题吗？
唯一散列和范围键的数量之间的比率是否会影响信息检索的性能？
答案 0 :(得分：4)
在以下情况下，每个哈希键都有很多范围键，这应该不是问题：
根据AWS Developer Guidelines for Working with Tables：
预配置吞吐量取决于主键选择，以及 单个项目的工作负载模式。存储数据时，DynamoDB 将表的项划分为多个分区，并分发 数据主要基于散列键元素。预备 与表相关的吞吐量也平均分配 分区，没有共享预配置吞吐量 分区。
基本上，每个散列密钥驻留在单个节点（即服务器）上。实际上，它是冗余存储的，以防止数据丢失，但在本次讨论中可以忽略。在配置吞吐量时，您间接确定要散布散列密钥的节点数。但是，无论您提供多少吞吐量，单个节点都可以处理单个散列密钥。
解释我的三个警告：
1。散列键的数量不会太低
你提到最多1000个哈希密钥，但关注的是最小值。例如，如果只有10个哈希密钥，那么您将很快达到每个密钥的吞吐量限制，并且实际上不会实现预配置的吞吐量。
2。您的访问权限随机分布在哈希键上
如果存在少量“热”键，则无论有多少哈希键都没关系。也就是说，如果您经常只读取或写入一小部分散列键，那么您将达到存储这些键的节点的吞吐量限制。
3。你不需要扩展到极端水平
即使假设您有1000个不同的哈希键并且您的访问权限随机分布在它们之间，如果您需要扩展到极限级别，您最终将达到每个哈希键位于单独节点上的点。也就是说，如果您提供足够的吞吐量以将每个哈希密钥分配给单独的节点（即您有1000多个节点），那么超出该级别的任何吞吐量都将无法实现，因为您将达到每个密钥的每个节点的限制
范围键与散列键的比率对获取，扫描和查询性能几乎没有影响。
据我所知，每个散列键的范围键都有效地存储在某种可以很好地扩展的索引中。但是，请记住，给定哈希键的所有行都存储在同一节点上，因此您可以到达给定哈希键的数据太多的点。 AWS Limits in DynamoDB州：
对于具有本地二级索引的表，项目有限制 集合大小：对于每个不同的散列键值，总大小 所有表和索引项不能超过10 GB。取决于你的 项目大小，这可能会限制每个哈希的范围键的数量 值。
答案 1 :(得分：2)
据我所知，这没关系。负载分布取决于访问的“频率”而不是“可能的组合”。如果您的访问权限是在您正在使用的1000个密钥中均匀分布的，那么就可以了 - 这意味着通过key1获取的概率应该类似于获取key10或key100的概率。在内部，我猜他们会将你的1000个密钥分成3个组，每个组“可能”由3台机器提供服务。您需要确保您的访问几乎是一致的，以便所有3台机器获得均匀的负载分配。