我有一个用例，其中生成的分区数量很少，这会带来节流问题。
可以说我的项目有几个字段，其中三个是organizationId, createdTime and itemType。我们正在尝试实现分页，并希望按createdTime的降序检索项目。
The GSI we had was organizationId (hash) and createdTime (range)（非常糟糕）。我们之所以选择这个原因，是因为这是我们可以按整个组织的排序顺序检索项目的唯一方法。稍后，我们开始将itemType附加到organizationId，然后哈希键变为organizationId-itemType。但是这些itemTypes只是其中的少数几个，因此我们仍然遇到节流问题。
我想提高这种性能。如果我们将记录分成随机的10/20/50分区，则收集所有数据并按排序顺序提供数据将是一项繁重的工作，而且非常耗时。我知道最糟糕的情况。
我知道对于许多使用dynamoDB的人来说应该有很多这样的用例。人们如何在发电机中实现这一目标？您是否说用例对于dynamoDB是错误的，或者是否有任何使它变得更好的想法（例如，计数器..每个计数器分区都有有限的记录集..如果发生任何并发操作，则锁定计数器分区。等等）？
您的想法/建议将真正帮助我们解决这个巨大的用例。
答案 0 :(得分：0)
您只需为每个记录分配一个uniq id /哈希，并在uniqid上创建一个仅哈希表。
然后根据需要添加尽可能多的GSI索引。
例如：organisationid + createdTime
大多数情况下，具有GSI索引且仅包含预测属性= KEYS是最佳选择，因为它既小又快速，并且可以在一个查询中提取数千个项目。同样，表读取更便宜，在非consendend读取的情况下甚至便宜10倍，而非KEYS ONLY索引也会更新GSI，从而浪费了写操作。
仅适用于KEYS的完美保护套：
显示分页的数据，对于每50/100项的数据块，批量获取这些项。
此外，您可以使用filterExpression仅选择所需的itemTypes并进行多次查询，直到获得所需的返回记录数，然后通过批处理读取来充实数据，而不必为itemType创建另一个索引