DynamoDB 中原子计数器的可靠性

Posted 2023-02-14

【中文标题】DynamoDB 中原子计数器的可靠性

【英文标题】：Reliability of atomic counters in DynamoDB

【发布时间】：2012-03-11 05:11:42

【问题描述】：

我正在考虑在我的应用程序中使用Amazon DynamoDB，但我对其atomic counters 的可靠性有疑问。

我正在构建一个分布式应用程序，该应用程序需要同时和一致递增/递减存储在 Dynamo 属性中的计数器。 我想知道 Dynamo 的原子计数器在重并发环境中的可靠性如何，其中并发级别非常高（假设，例如，平均 20k 并发命中率 - 明白这一点，这将是近 520 亿的增量/每月递减）。

计数器应该是超级可靠的，并且永远不会错过任何命中。有人在如此关键的环境中测试过 DynamoDB 吗？

谢谢

【参考方案1】：

DynamoDB 通过在多个服务器之间拆分密钥来获得它的扩展属性。这类似于 Cassandra 和 HBase 等其他分布式数据库的扩展方式。虽然您可以增加 DynamoDB 上的吞吐量，只需将您的数据移动到多个服务器，现在每个服务器都可以处理总并发连接数/服务器数量。查看at their FAQ 了解如何实现最大吞吐量：

问：我是否总是能够达到我的预置吞吐量水平？

Amazon DynamoDB 假定所有主键的访问模式相对随机。您应该设置您的数据模型，以便您的请求导致跨主键的流量分布相当均匀。如果您的访问模式非常不均匀或有偏差，您可能无法达到您的预置吞吐量水平。

在存储数据时，Amazon DynamoDB 将一个表划分为多个分区，并根据主键的哈希键元素分布数据。与表关联的预置吞吐量也在分区之间分配；每个分区的吞吐量根据分配给它的配额独立管理。没有跨分区共享预配置吞吐量。因此，如果工作负载相当均匀地分布在散列键值上，Amazon DynamoDB 中的表最能满足预置的吞吐量水平。跨哈希键值分布请求会跨分区分布请求，这有助于实现完全预置的吞吐量水平。

如果您的主键工作负载模式不均衡，并且无法达到预置吞吐量水平，您可以通过进一步提高预置吞吐量水平来满足吞吐量需求，这将为每个分区提供更多吞吐量。但是，建议您考虑修改请求模式或数据模型，以实现跨主键的相对随机访问模式。

这意味着拥有一个直接递增的密钥将无法扩展，因为该密钥必须位于一台服务器上。还有其他方法可以处理此问题，例如在内存聚合中使用 DynamoDB 的刷新增量（尽管这可能存在可靠性问题）或分片计数器，其中增量分布在多个键上并通过拉取分片中的所有键来读取计数器 (http://whynosql.com/scaling-distributed-counters/)。

【讨论】：

可悲的是，链接腐烂已经在第二个链接上设置了这个答案

web.archive.org/web/20120621195522/https://whynosql.com/…

【参考方案2】：

除了 gigq 关于可扩展性的回答之外，DynamoDBs 原子增量不是幂等的，因此不可靠：如果在发出UpdateItemADD 请求后连接断开，您无法知道添加是否已提交或不，所以你不知道是否应该重试。

DynamoDB 条件更新解决了这个问题，但代价是系统的可扩展性更低，因为每次同时尝试对属性进行两次更改时，您都必须重试，即使没有出现错误。

【讨论】：

DynamoDB 条件更新解决了这个问题，但不是真的：如果客户端在应用写入时出现网络错误，但在它知道之前，客户端应该怎么做？

文档说它必须重试，因为条件更新是幂等的，但我不同意。例如。客户端读取一个计数器，它的值为 10，必须加 1。它执行第一次调用：如果计数器的值为 10，则将计数器设置为 11。执行更新并断开连接。客户端捕获网络异常并重试：条件为假。然后客户端不知道它是否应该尝试从 11 增加 1：问题是 如果发生网络错误，客户端无法区分他自己的增量和其他人同时进行的增量

如果您使用更新语句中的ReturnValues 会怎样？这样一来，您就可以在更新完成后获得价值。返回值是强一致的。然后你不需要阅读，然后更新。如果您的网络中断，请重试。最坏的情况是你跳过序列中的一个数字。 docs.aws.amazon.com/amazondynamodb/latest/APIReference/…

【参考方案3】：

如果您要编写单个 dynamo db 密钥，您将遇到 热分区 问题。热分区问题从每个索引大约 300 TPS 开始。因此，如果表中有 5 个索引，您可能会看到 300/5 ~ 60 TPS 左右的热分区问题。

否则，dynamo db 可扩展到大约 10-40K TPS，具体取决于您的用例。

【讨论】：

Segment 有一篇很棒的文章，介绍了他们的热分区问题，名为 The Million Dollar Engineering Problem