我已阅读 guidelines对于二级索引，但我不确定快速搜索的能力何时超过扫描属性的缺点。让我举个例子。
我正在为用户保存游戏进度数据。 PK是用户ID。我需要能够:
了解特定游戏的用户进度。
获取用户所有已完成/正在进行的游戏。
因此，我可以将我的 SK 设计为 progress_{state} ，以便能够通过进度快速查询所有游戏(状态代表开始/完成)，或者我可以将我的 SK 设计为 progress_ {gameId}能够快速查询给定游戏的进度。然而，我不能只使用 SK 来两者兼得。当我选择其中一项时，另一项操作将需要扫描。
因此，我正在考虑使用 LSI，这会增加整个表的开销，正如 Amazon here 所指出的那样。 :
Every secondary index means more work for DynamoDB. When you add, delete, or replace items in a table that has local secondary indexes, DynamoDB will use additional write capacity units to update the relevant indexes.
我估计最多有数千种游戏类型，我想知道是否值得使用 LSI，或者对于我选择的其他操作使用扫描是否更好。
有人对此类问题有任何实际经验吗？我找不到有关此主题的任何内容。
最佳答案
当您设计 DynamoDB 表时，主要成本因素是读取和写入的 IOPS。
这就是为什么避免扫描通常更好的原因。扫描将消耗大量的读取 IOPS，并且会随着表中项目数量的增加而增加，因为扫描需要读取表中的所有项目，然后才能返回匹配的项目。
然后回到使用 SK 来取得进展的用例，最好使用属性并定义二级索引，因为稍后您需要更新状态(这对于 PK 和 SK 来说是不可能的)表)。
因此，根据您的用例和问题中给出的信息，您可以将架构定义为；
PK-用户ID SK-游戏ID GSI-进展(PK)
快速按进度查询所有游戏 GSI 进展(PK)
注意:如果这是针对特定用户的；您可以将其更改为 LSI Progress。
快速查询给定游戏的进度(假设对于给定用户) 使用Table的UserID(PK)和GameID(SK)查询
关于amazon-web-services - 何时值得在 DynamoDB 中使用本地二级索引进行权衡？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/53982164/