我设计了这个聊天演示应用程序，其中有一个相当简单的用例：我使用 AppSync 和 GraphQL 从我的 DynamoDB 表中查询对话，并将我的 PK 设置为对话 ID，并将 LastActive 或 LastMessageDate 用作排序键。
正如您所猜测的，我想使用这个lastMessageDate属性对查询结果进行排序，因此每次在该对话中发送新消息时，我都可以将该对话显示为列表中的最新消息。
我知道您无法修改 dynamoDB 中的排序键（或 PK），这也是行不通的，因为 SK 和 PK 构成了项目中的主键。所以我的问题是，有没有办法使用 LSI 或 GSI 来实现这一目标？必须有一种方法可以修改您排序所依据的属性。排序关键字段不能在整个生命周期中保持静态，不是吗？
我尝试了什么？
您是对的，您无法更新 DynamoDB 表的主键。但是，有一些解决方法：
您可以简单地删除然后放置。但是，您可能会遇到一致性问题（如果失败）。因此，这导致使用您提到的交易。您提到它们消耗了太多的 RCU，但 TransactionWrites 不消耗任何 RCU，仅消耗 WCU（不确定这是否是您的拼写错误）。对于交易，您需要支付双倍的 WCU。因此，如果“删除然后放置”花费您 2 WCU，那么您将通过交易支付 4 WCU。我最喜欢这种方法，因为你可以获得很强的一致性。但出于成本目的，当密钥有大量更新时，它无法很好地扩展。
虽然我总是建议不要使用 LSI，但如果您需要强一致性，它也可以工作。但我们来讨论一下 GSI。您可以将基表主键设置为具有不同的排序键，该排序键仍然对您的访问模式有意义。
您的索引现在将具有基表当前具有的架构。您现在可以更新索引排序键。 DynamoDB 在幕后对索引中的项目执行删除然后放入操作。此操作将花费您 1 WCU 来更新基表，并花费 2 WCU 来进行索引删除然后放入 - 总共 3 WCU（与事务没有太大区别），并且您仍然需要维护索引。
对于这两个选项，它实际上取决于密钥更新的频率。不太频繁的更新将适合事务，而从成本角度来看，索引可以处理更大的吞吐量。