0

我正在使用 dynamo db 表来保存我的 API 请求的事务数据。我正在维护两个表 1. 计划 - 将 SId 作为哈希键 2. 摘要 - 将 DynamoDBAutoGeneratedKey (UUID) 作为哈希键，将 SId 作为属性。

调度表为每个请求填充一行，而汇总表为每个 SId 和唯一 UUID 填充 10 个项目

我们正在对这两个表进行负载测试，观察到调度表运行良好，但汇总表在 PutRequests 中为每次调用的 10 个项目消耗了大量时间。

有人可以对我的摘要 dynamodb 表的性能调整提出建议吗？可以将 UUID 保留为 hashkey，减慢 PutItemRequest 的速度吗？

非常感谢任何帮助指针。

此外，我们已经激活了这些表上的流，这些流被 lambda 用于交叉复制。

4

2 回答 2

0

有几点需要考虑：

1) 对于给定的负载测试，您的数据库吞吐量是否足够高？请注意，如果您有多个分区，则吞吐量将在它们之间分配，尽管如果您为每次写入使用随机 UUID，那么您在写入时不应该出现热分区问题。

2）肯定是数据库变慢了还是应用程序变慢了？可能是您正在按顺序而不是并行执行写入，或者可能使用同步调用而不是异步调用

3) 您是否查看过控制台中的 dynamoDB 指标？您应该能够在那里看到诸如平均放置延迟和限制请求等指标。这可能会为您提供一些启示

于 2017-07-21T21:30:33.653 回答
0

想到的几件事：

  • 您是否有机会使用扫描？这可以解释性能下降的原因，因为扫描没有利用任何有关数据在 DynamoDB 中的组织方式的知识，而只是一种蛮力搜索。您应该避免使用扫描，因为它们本质上是缓慢且昂贵的。

  • 你有“热分区”吗？你写了：

  1. schedule - 使用 SId 作为 hashkey 2. 摘要 - 使用 DynamoDBAutoGeneratedKey (UUID) 作为 hashkey 和 SId 作为它的属性。

对这些值的访问是否均匀分布？您是否有比其他人更频繁地访问的项目？如果是这样，这可能是一个问题，如果您的大部分读/写都涉及到一小部分 id，那么这意味着您正在用请求淹没单个分区（物理机）。我也建议对此进行调查。

一种解决方案是使用缓存并在那里存储经常访问的项目。您可以使用 ElasticCache 或DAX - Dynamo 中的一种新缓存解决方案。

您可以在此处和此处找到有关热分区的更多信息。

  • 你在使用交易吗？你写了：

我正在使用 dynamo db 表来保存事务数据

如果您的意思是您正在使用 DynamoDB 事务，则需要阅读DynamoDB 如何实现事务。

长话短说，DynamoDB 正在存储您在执行事务时更新/删除/添加的所有项目的副本。此外，DynamoDB 事务的成本很高，每个事务需要 7N+4 次写入，其中 N 是事务中涉及的项目数。

于 2017-07-24T10:49:04.473 回答