我有一个大的(2B + 记录(DynamoDB 表。 我想通过在创建或更新项目时添加一个新字段"index_due_at"来实现分布式锁定过程。 创建/更新后，我将对该项目进行一些进一步的处理，然后删除"index_due_at"字段。
我想创建一个清理器作业，它将定期提取具有未完成"index_due_at"字段的任何记录(假设上述过程的某些内容失败(以进一步处理这些记录。我预计在任何时候最多会有 100 条记录处于这种状态，更有可能是 10 条。
为了优化扫地机的性能，我想创建一个包含新字段的 GSI(并将关键数据投影到其中(。
似乎使用时间戳(以毫秒为单位(作为 GSI HASH 密钥应该给出一个良好的分布。我不需要查询这个字段的值，只需要查询它的存在。 任何人都可以确定这种方法的任何缺点，如果是，建议替代方案？
我可以预料到的问题包括： * 毫秒级时间戳的非唯一性。 * 数值可能存在哈希键问题？ * 数字值可能存在哈希键问题，这些数字在最高有效数字中变化不大。
这比你想象的要小。GSI哈希键实际上不一定是唯一的，所以你比前面很好。
您可能已经知道这一点，但是您的 GSI 只会包含带有 GSI 密钥的项目，因此您的 GSI 应该非常小(100 多个项目(。
我的一个想法是，index_due_at实际上可能更适合作为 GSI 排序键而不是哈希键。数据在分区内按排序键排序。因此，您可以有一个 GSI 哈希键 index_due_at_flag 如果存在，则会Y，然后是 index_due_at 的排序键。这意味着您的所有数据都将自然排序，因此您可以按日期顺序处理它。
也就是说，您可能永远不会查询此 GSI，因此我怀疑您选择的密钥根本不重要。大概你只会进行扫描，获取所有项目并尝试处理它们。在这种情况下，您甚至永远不会使用密钥。只需存在一个关键属性就会将项目放入 GSI 中。
另一个想法是，您需要处理 GSI 与基表不完全同步的事实。有可能(诚然不太可能(您的 GSI 中的项目实际上刚刚被处理过。因此，如果您的清理器脚本从 GSI 中选取一个项目，您应该处理它可能已经在基表中更新的事实(例如，在尝试处理基表项目之前检查它(。
祝你好运。我回答是因为我喜欢你的简历！希望留在桶形的右侧正在解决:)
这应该是使用 DynamoDB 稀疏索引的完美方案 在GSI中使用"index_due_at"作为排序键，只有您感兴趣的项目才会出现在索引中，从而大大减少了所需的空间和性能。