我正在构建一个包含通知消息的DynamoDB表。消息从给定用户（from_user）定向到另一个用户（to_user）。他们很简单：
{“to_user”：“e17818ae-104e-11e3-a1d7-080027880ca6”，“from_user”：“e204ea36-104e-11e3-9b0b-080027880ca6”，“notification_id”：“e232f73c-104e-11e3-9b30-080027880ca6 “，”“消息”：“鲍勃推荐好读。”，“类型”：“推荐”，“isbn”：“1844134016”}
这些是表格中定义的哈希/范围键：
HashKey：to_user，RangeKey：notification_id
案例1 ：用户经常打电话回家询问任何可用的通知。
使用这些键，可以轻松获取等待给定用户的通知：
notifications.query（to_user = “e17818ae-104E-11e3-a1d7-080027880ca6”）
案例2 ：一旦用户看到消息，他们就会明确地确认消息并将其删除。使用给定的Hash / Range键也可以很容易地实现这一点：
notifications.delete（to_user =“e17818ae-104e-11e3-a1d7-080027880ca6”，notification_id =“e232f73c-104e-11e3-9b30-080027880ca6”）
案例3 ：有时可能需要删除此表中由to_user和notification_id以外的键标识的项目。例如，用户Bob决定取消推荐一本书，我们希望使用from_user = Bob，action = recommended和isbn = isbnval来提取通知。
我知道我选择的哈希/范围键无法做到这一点。本地二级索引在这里似乎也没有用，因为我不想在表中选择的HashKey中工作。
所以我坚持做完全扫描？我可以想象创建第二个表来将from_user + action + isbn映射回原始表中的项目，但这意味着我必须管理那些额外的复杂性......而且看起来这个手动滚动的索引可能很容易失去同步。
任何见解都将不胜感激。我是DynamoDB的新手，并试图了解典型的数据模型如何映射到它。感谢。
答案 0 :(得分：1)
您的分析是正确的。对于案例3和此架构，您必须执行表扫描。
您已经确定了许多选项，但所有选项都会为您的应用添加一层复杂性。
在您说明时使用第二个表格。您正在有效地创建自己的全局索引，并且必须自己管理这种复杂性。由于您需要更多索引，因此复杂性会增加。
执行全表扫描。查看DynamoDB的扫描分段，了解跨多个工作节点分发扫描的方法。根据您的延迟要求（如果建议在下次扫描之前不会消失，可以吗？）您可以将此和其他未来的后台任务组合到一个持续的后台进程中。这也比1简单。
这两种似乎都是相当常见的模型。