我需要创建一个表，其中包含由连续运行的进程生成的数据片段。此过程生成包含两个必需组件的消息，其中包括：全局唯一消息 UUID 和消息时间戳。
这些消息稍后将由 UUID 检索。
此外，我需要定期从该表中删除所有太旧的消息，即时间戳与当前时间相差超过 X 的消息。
我一直在阅读 DynamoDB v2 文档（例如Local Secondary Indexes），试图弄清楚如何组织我的表以及是否需要二级索引来搜索要删除的消息。我的问题可能有一个简单的答案，但我有点困惑......
那么我是否应该创建一个表，其中 UUID 作为哈希，messageTimestamp 作为范围键（连同包含实际消息的“消息”属性），然后不创建任何二级索引？在我看到的示例中，哈希值不是唯一的（例如，上述链接下的 ForumName）。在我的情况下，哈希将是唯一的。我不确定这是否有任何区别。
如果我按照所述创建具有哈希和范围的表，并且没有二级索引，那么我将如何查询特定时间范围内的所有消息，而不管它们的 UUID 是什么？
DynamoDB 引入了全球二级索引来解决这个问题。 http://docs.aws.amazon.com/amazondynamodb/latest/developerguide/GSI.html
我们也为此苦苦挣扎。我们提出的最佳解决方案是创建第二个表来存储时间序列数据。去做这个：
1）使用日期加上“桶”ID作为哈希键
您可以只使用日期，但我猜今天的日期将成为一个“热”键 - 一个写入频率过高的键。这可能会造成严重的瓶颈，因为特定 DynamoDB 分区的总吞吐量等于预置的总吞吐量除以分区数 - 这意味着如果您的所有写入都针对单个键（今天的键）并且您有一个吞吐量每秒 20 次写入，然后使用 20 个分区，您的总吞吐量将是每秒 1 次写入。超出此范围的任何请求都将受到限制。不是一个好情况。
存储桶可以是从 1 到 n 的随机数，其中 n 应大于底层 DB 使用的分区数。当然，确定 n 有点棘手，因为 Dynamo 没有透露它使用了多少个分区。但我们目前正在根据此处找到的示例使用 200 的上限。此链接上的文章是我们提出这种方法的想法的基础。
2) 使用 UUID 作为范围键
3）通过对每天和桶发出查询来查询记录。 这可能看起来很乏味，但它比完整扫描更有效。另一种可能性是使用 Elastic Map Reduce 作业，但我自己还没有尝试过，所以不能说使用它有多容易/有效。
我们仍在自己解决这个问题，所以我很想听听其他人的评论。我还发现这个演示文稿非常有助于思考如何最好地使用 Dynamo： 爱上和爱上 Dynamo
-约翰
总之你不能。所有 DynamoDB 查询必须在查询中包含主哈希索引。或者，您还可以使用范围键和/或本地二级索引。使用当前的 DynamoDB 功能，您将无法使用 LSI 作为主索引的替代方案。您也无法仅使用范围键发出查询（您可以在 AWS 控制台中轻松测试）。
我能想到的一个（昂贵的）解决方法是对表进行扫描，根据时间戳值添加过滤器，以找出要删除的字段。请注意，过滤不会减少查询的使用容量，因为它会解析整个表。