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