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

我有2个全球二级价值指数（ValueIndex）和Token（TokenIndex）字段。稍后在内部逻辑的某处，我执行此实体的更新，并通过其中一个索引（ValueIndex或TokenIndex）立即读取此实体，我看到数据未就绪的预期问题（我的意思是尚未更新）。在这种情况下，我无法使用ConsistentRead，因为这是全局二级索引，它不支持此选项。因此，我无法对此逻辑运行负载测试，因为当测试进入10-20-30个线程时，数据尚未就绪。所以我的问题 - 是否有可能在某处解决这个问题？或者我应该重新组织我的表并将其拆分为2-3个不同的表并将值，Token移动到HASH键或SORT键？

Answer 1

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

确保您的GSI保持精益 - 也就是说，只投影您需要的绝对最小属性。要写的数据越少，就越快。
确保您的GSI具有正确的预配置吞吐量。如果它没有，它可能无法跟上表中的活动，因此您将在GSI中保持同步的长时间延迟。
如果更新导致GSI中的密钥更新，则每次更新需要2个吞吐量单位。从本质上讲，DynamoDB将删除该项目，然后插入一个更新密钥的新项目。因此，即使您的表有100个预配置写入，如果每次写入都会导致更新GSI密钥，那么您需要配置200个写入单元。

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

我怀疑一旦你根据自己的情况调整DynamoDB，你就会非常接近你想要的东西。

DynamoDB ConsistentRead for Global Indexes

1 个答案: