如何有效地拆分 dynamoDB 分区？

Question

我有一个用例，其中生成的分区数量很少，这会导致限制问题。

假设我的项目有几个字段，其中三个是organizationId, createdTime and itemType。我们正在尝试实现分页，我们希望按 createdTime 的降序检索项目。

The GSI we had was organizationId (hash) and createdTime (range)（非常糟糕）。我们选择这个的原因是，这是我们可以按排序顺序为整个组织检索项目的唯一方法。后来我们开始将 itemType 附加到 organizationId，然后哈希键变为organizationId-itemType。但是这些 itemType 只是其中的一小部分，所以我们仍然会看到限制问题。

我想提高这种性能。如果我们将记录分成随机的 10/20/50 分区，那么收集所有数据并按排序顺序提供数据是一项繁重的操作并且非常耗时。我知道最坏的情况。

我知道对于许多从事 dynamoDB 工作的人来说，应该有很多这样的用例。人们如何在发电机中实现这一目标？您是否说 dynamoDB 的用例是错误的，或者有什么想法可以使它变得更好（例如计数器 .. 每个计数器分区都有有限的记录集.. 如果发生任何并发操作，则锁定计数器分区.. 等等）？

您的想法/建议将真正帮助我们解决这个巨大的用例。

Answer 1

您可以简单地为每条记录分配一个 uniq id/散列，并在 uniqid 上创建一个仅散列表。

然后根据需要添加尽可能多的 GSI 索引。
例如：organizationid+createdTime

在大多数情况下，具有投影属性 = KEYS ONLY 的 GSI 索引是最佳选择，因为它小而快，并且可以在一次查询中提取数千个项目。此外，表读取更便宜，在非一致读取的情况下甚至便宜 10 倍，而非 KEYS ONLY 索引也会更新 GSI，从而花费写入。

仅适用于 KEYS：
分页显示数据，对于每块 50/100 个项目，批量获取这些项目。

此外，您可以使用 filterExpression 仅选择所需的 itemTypes 并执行尽可能多的查询，直到获得所需数量的要返回的记录，然后通过批量读取来丰富您的数据，而不是为 itemType 创建另一个索引