我正在考虑利用
AWS guidelines中描述的稀疏索引.在所描述的示例中 –

… in the GameScores table, certain players might have earned a particular achievement for a game – such as “Champ” – but most players have not. Rather than scanning the entire GameScores table for Champs, you could create a global secondary index with a partition key of Champ and a sort key of UserId.

我的问题是：当冠军数量变得非常大时会发生什么？我认为“Champ”分区会变得非常大,你会开始经历不均匀的负载分配.为了获得均匀的负载分布,我是否需要通过(有效地)分割n个分片来随机化“Champ”值,例如, Champ.0,Champ.1 …… Champ.99？

或者,在获取具有可能随时间变大的特定属性的实体时,是否可以使用不同的访问模式？

最佳答案 这正是您需要的解决方案(Champ.0,Champ.1 … Champ.N)

N应该是[此索引的预期分区有一些增长差距](如果您期望高负载,或许多’冠军’那么您可以选择N = 200)(对于分区上的良好散列分布).我建议N将以userId为模. (这可以帮助您通过userId进行一些操作.)

如果您的哈希键是布尔值,我们也会使用此解决方案(在dynamodb中您可以将布尔值表示为字符串),因此在这种情况下哈希将是“true.0”,“true.1”….“true.N”和“假”一样.