什么时候值得权衡使用 DynamoDB 中的本地二级索引？
When it's worth the tradeoff of using local secondary index in DynamoDB?
我已阅读 guidelines 二级索引，但我不确定何时快速搜索的能力超过扫描属性的缺点。我举个例子。
我正在为用户保存游戏进度数据。 PK 是用户 ID。我需要能够：
了解特定游戏的用户进度。
获取一个用户的所有finished/in进度游戏。
因此，我可以将我的 SK 设计为 progress_{state} 以便能够通过进度快速查询所有游戏（状态代表 started/finished）或者我可以设计我的 SK 为 progress_{gameId} 以便能够快速查询给定游戏的进度。但是，我不能同时使用 SK。当我选择了一个时，另一个操作将需要扫描。
因此，我正在考虑使用 LSI，这会增加整体的开销 table，正如 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 tables 时，主要的成本因素是读写的 IOPS。
这就是避免扫描通常更好的原因。扫描会消耗大量的读取 IOPS，并且会随着 table 中项目的数量增加而增加，因为扫描需要在返回匹配项目之前读取 table 中的所有项目。
然后回到您使用 SK 取得进展的用例，最好使用属性并定义二级索引，因为稍后您需要更新状态（这对 PK 和 SK 是不可能的在 table).
因此，根据您的用例和问题中提供的信息，您可以将架构定义为；
PK- 用户 ID
SK-游戏ID
GSI- 进度 (PK)
按进度快查询所有游戏
GSI 进度 (PK)
注意：如果这是针对特定用户的；您可以将其更改为 LSI Progress。
快速查询给定游戏的进度（假设对于给定用户）
使用 Table
的 UserID (PK) 和 GameID (SK) 查询
我已阅读 guidelines 二级索引，但我不确定何时快速搜索的能力超过扫描属性的缺点。我举个例子。
我正在为用户保存游戏进度数据。 PK 是用户 ID。我需要能够：
了解特定游戏的用户进度。
获取一个用户的所有finished/in进度游戏。
因此，我可以将我的 SK 设计为 progress_{state} 以便能够通过进度快速查询所有游戏（状态代表 started/finished）或者我可以设计我的 SK 为 progress_{gameId} 以便能够快速查询给定游戏的进度。但是，我不能同时使用 SK。当我选择了一个时，另一个操作将需要扫描。
因此，我正在考虑使用 LSI，这会增加整体的开销 table，正如 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 tables 时，主要的成本因素是读写的 IOPS。
这就是避免扫描通常更好的原因。扫描会消耗大量的读取 IOPS，并且会随着 table 中项目的数量增加而增加，因为扫描需要在返回匹配项目之前读取 table 中的所有项目。
然后回到您使用 SK 取得进展的用例，最好使用属性并定义二级索引，因为稍后您需要更新状态（这对 PK 和 SK 是不可能的在 table).
因此，根据您的用例和问题中提供的信息，您可以将架构定义为；
PK- 用户 ID SK-游戏ID GSI- 进度 (PK)
按进度快查询所有游戏 GSI 进度 (PK)
注意：如果这是针对特定用户的；您可以将其更改为 LSI Progress。
快速查询给定游戏的进度（假设对于给定用户） 使用 Table
的 UserID (PK) 和 GameID (SK) 查询