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