amazon-web-services - 用于全局索引的 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"`

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

Answer 1

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

1. 确保您的 GSI 保持精简 - 也就是说，只转换您需要的绝对最少属性。要写入的数据越少，速度就越快。
2. 确保您的 GSI 具有正确的配置吞吐量。否则，它可能无法跟上表格中的事件，因此您将在 GSI 保持同步方面遇到长时间延迟。
3. 如果更新导致 GSI 中的 key 被更新，则您需要为每个更新配置 2 个单位的吞吐量。本质上，DynamoDB 将删除该项目，然后插入一个更新了键的新项目。因此，即使您的表有 100 个预置写入，如果每次写入都会导致您的 GSI key 更新，您将需要预置 200 个写入单元。

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

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