amazon-web-services - DynamoDB ConsistentRead用于全局索引

我有下一个表结构:

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"`

我有2个针对Value(ValueIndex)和Token(TokenIndex)字段的全局二级索引。稍后在内部逻辑中的某个地方，我执行该实体的更新，并通过其中一个索引(ValueIndex或TokenIndex)立即读取该实体，并且看到预期的问题，即数据尚未准备就绪(我的意思是尚未更新)。在这种情况下，我不能使用ConsistentRead，因为这是全局二级索引，它不支持此选项。结果，我无法在此逻辑上运行负载测试，因为在10-20-30个线程中进行测试时，数据尚未准备就绪。所以我的问题-是否可以在某个地方解决这个问题？还是应该重新组织我的表并将其拆分为2-3个不同的表，然后将诸如Value，Token的文件移动到HASH密钥或SORT密钥？

最佳答案

GSI从它们正在索引的表中异步更新。 GSI的更新通常发生在一秒钟之内。因此，如果您在插入/更新/删除后立即读取GSI，那么就有可能获取过时的数据。这就是GSI的工作方式-您无能为力。但是，您需要真正注意三件事:

确保您的GSI保持精简-即，仅投影所需的绝对最小属性。更少的数据写入将使其更快。

确保您的GSI具有正确的预配置吞吐量。否则，它可能无法跟上表中的 Activity ，因此，GSI保持同步会导致长时间的延迟。

如果更新导致GSI中的密钥被更新，则每个更新将需要2个单位的吞吐量。本质上，DynamoDB将删除该项目，然后插入具有更新密钥的新项目。因此，即使您的表有100个预配置的写入，但如果每个写入都导致GSI密钥的更新，您将需要预配置200个写入单元。

调整完DynamoDB设置后，您仍然绝对无法处理GSI的短暂延迟，您可能需要使用其他技术。例如，即使您决定将表拆分为多个表，也会产生相同(甚至更糟)的影响。您将更新一个表，然后尝试从另一个表读取数据，但尚未将值插入到另一个表中。

我怀疑一旦针对您的情况调整了DynamoDB，您就会非常接近您想要的东西。

关于amazon-web-services - DynamoDB ConsistentRead用于全局索引，我们在Stack Overflow上找到一个类似的问题：https://stackoverflow.com/questions/47032502/