【问题标题】:Are DynamoDB Updates strongly consistent?DynamoDB 更新是否具有强一致性?
【发布时间】:2020-03-10 19:39:46
【问题描述】:

DynamoDB 快速且可扩展的全部原因在于它最终是一致的。但同时,它还为getbatchGetquery 等操作提供了ConsistentRead 选项,可帮助您确保正在读取的数据是最新的。

我的问题是关于update 操作。首先,它没有ConsistentRead 选项(一个原因是,update 不是读取!)。但同时,您可以使用ConditionExpression 以原子方式更新记录,如下所示:

await docClient.update({
    TableName: 'SomeTable',
    Key: {id},
    UpdateExpression: "set #status = :new_status",
    ConditionExpression: '#status = :old_status',
    ExpressionAttributeNames: {
        "#status": "status",
    },
    ExpressionAttributeValues: {
        ":old_status": "available",
        ":new_status": "done",
    },
}).promise()

这将确保在更新时,旧值是available,如果不是,操作将失败并抛出异常。所以,在某种意义上,你可以说update是强一致的。

但我的问题是关于您需要确保记录存在的场景。假设您有一个插入记录的函数。另一个更新相同记录的记录(给定它的id)。我担心的是,如果在执行 update 操作时,由于 DynamoDB 的最终一致性,没有匹配的记录并且更新失败。如前所述,update 操作不附带ConsistentRead 选项以使其强一致。

这是一个有效的担忧吗?有什么我可以做的吗?

【问题讨论】:

  • 您对 DynamoDB 并发模型的担忧是有效的,不知道为什么它在没有给出适当反馈的情况下被其他成员投票否决。
  • 嗨@Mehran,我回答你的问题了吗?

标签: amazon-web-services amazon-dynamodb consistency eventual-consistency


【解决方案1】:

没有强一致性更新;强一致性适用于读取,其中基本上在写入后立即查看的数据对于实体的所有观察者来说都是一致的。

当您的应用程序将数据写入 DynamoDB 表并收到 HTTP 200 响应 (OK) 时,写入已经发生(在至少一个存储位置)并且是持久的。所有存储位置的数据最终一致,通常在一秒或更短的时间内。然后,您可以选择以最终或高度一致性的方式读取这些数据。

应使用乐观并发处理对同一项目的并发写入,您可以使用 DynamoDB 事务库(AWS SDK for Java 中提供)执行条件写入

如果您需要以原子方式更新多个项目,您可以使用 DynamoDB 事务。

DynamoDB 事务为开发人员提供原子性、一致性、 跨一个或多个表的隔离和持久性 (ACID) 单个 AWS 账户和区域。您可以在构建时使用事务 需要协调插入、删除或更新的应用程序 多个项目作为单个逻辑业务操作的一部分。

https://aws.amazon.com/blogs/aws/new-amazon-dynamodb-transactions/

或者,您的用例可能会受益于 DynamoDB 全局表,它在并发写入之间使用“最后写入者获胜”协调。

【讨论】:

    猜你喜欢
    • 1970-01-01
    • 2023-01-18
    • 2015-12-02
    • 2012-11-20
    • 2014-01-19
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多