我正在考虑利用AWS guidelines中描述的稀疏索引。在所描述的例子中 -
...在GameScores表中，某些玩家可能已经为游戏赢得了特定的成就 - 例如＆＃34; Champ＆＃34; - 但大多数球员都没有。您可以使用Champ的分区键和UserId的排序键创建一个全局二级索引，而不是扫描Champs的整个GameScores表。
我的问题是：当冠军数量变得非常大时会发生什么？我认为＆＃34; Champ＆＃34;分区将变得非常大，您将开始遇到不均匀的负载分配。为了获得均匀的负载分配，我是否需要随机选择＆＃34; Champ＆＃34;通过（有效）分片n分片的值，例如Champ.0，Champ.1 ... Champ.99？
或者，在获取具有可能随时间变大的特定属性的实体时，是否可以使用不同的访问模式？
答案 0 :(得分：1)
这正是您需要的解决方案（Champ.0，Champ.1 ... Champ.N）
N应该是[此索引的预期分区+一些增长差距]（如果您期望高负载，或许多'冠军'，那么您可以选择N = 200）（对于分区上的良好散列分布）。我建议N将以userId为模。 （这可以帮助您通过userId进行一些操作。）
如果您的哈希键是布尔值，我们也会使用此解决方案（在dynamodb中您可以将boolean表示为字符串），因此在这种情况下哈希将是“true.0”，“true.1”....“true .N“和”假“相同。