全球指数的DynamoDB ConsistentRead

Question

我的下一张桌子是：

ID              string    `dynamodbav:"id,omitempty"`
Type            string    `dynamodbav:"type,omitempty"`
Value           string    `dynamodbav:"value,omitempty"`
Token           string    `dynamodbav:"token,omitempty"`
Status          int       `dynamodbav:"status,omitempty"`
ActionID        string    `dynamodbav:"action_id,omitempty"`
CreatedAt       time.Time `dynamodbav:"created_at,omitempty"`
UpdatedAt       time.Time `dynamodbav:"updated_at,omitempty"`
ValidationToken string    `dynamodbav:"validation_token,omitempty"`

我有两个全球二级价值指数(ValueIndex)字段和令牌(TokenIndex)字段。稍后，在内部逻辑的某个地方，我执行该实体的更新，并通过其中一个索引(ValueIndex或TokenIndex)立即读取该实体，我看到了数据尚未准备好的预期问题(我指的是尚未更新的数据)。我不能在这种情况下使用ConsistentRead，因为这是全局二级索引，它不支持这个选项。因此，我无法在这个逻辑上运行负载测试，因为当测试在10-20到30个线程中进行时，数据还没有准备好。所以我的问题--在某个地方能解决这个问题吗？或者我应该重新组织我的表并将它拆分到2-3个不同的表中，然后像值一样移动字段、标记到散列键或排序键？

Answer 1

GSIs是从索引的表异步更新的。对GSI的更新通常发生在秒以下。因此，如果您在insert / update / delete之后立即阅读GSI，那么就有可能得到陈旧的数据。这就是GSI的工作原理-你对此无能为力。但是，您需要真正注意以下三件事：

1. 确保您保持GSI的精益-也就是说，只投影您所需的绝对最小属性。更少的数据写入将使它更快。
2. 确保GSI具有正确的供应吞吐量。如果不这样做，它可能无法跟上表中的活动，因此您将得到GSI的长期延迟保持同步。
3. 如果更新导致GSI中的密钥被更新，那么每次更新都需要提供两个单元的吞吐量。本质上，DynamoDB将删除该项，然后插入一个更新键的新项。因此，即使您的表有100个准备好的写操作，如果每个写都会导致对GSI键的更新，那么您将需要提供200个写单元。

一旦您调优了DynamoDB设置，并且仍然无法处理GSI中的短暂延迟，您可能需要使用不同的技术。例如，即使您决定将表拆分成多个表，它也会产生相同的影响(如果不是更糟的话)。您将更新一个表，然后尝试从另一个表读取数据，但尚未将这些值插入到另一个表中。

我怀疑一旦你根据你的情况调好了DynamoDB，你就会得到你想要的东西。