33

我正在考虑在我的应用程序中使用Amazon DynamoDB ，但我对其原子计数器的可靠性有疑问。

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

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

谢谢

4

3 回答 3

21

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

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

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

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

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

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

于 2012-02-23T05:19:54.493 回答
9

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

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

于 2012-02-23T23:06:08.220 回答
3

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

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

于 2018-03-20T23:31:40.543 回答