我正在使用dynamo db表来保存我的API请求的事务数据。 我正在维护两张桌子 1. schedule - 用SId作为hashkey 2. summary - 将DynamoDBAutoGeneratedKey（UUID）作为hashkey，将SId作为其属性。
计划表为每个请求填充一行，而汇总表每个SId填充10个项目并且唯一的UUID
我们正在对这两个表运行负载测试，并且观察到调度表运行良好，但是汇总表在PutRequests中每次调用10个项目消耗了大量时间。
任何人都可以建议我的汇总dynamodb表进行性能调整吗？ 可以将UUID保留为hashkey，减慢PutItemRequest吗？
非常感谢任何帮助提示。
此外，我们已经激活了这些表上的流，这些表由lambda用于交叉复制。
答案 0 :(得分：0)
很少有事情需要考虑：
1）对于给定的负载测试，您的数据库吞吐量是否足够高？请注意，如果您有多个分区，则吞吐量将在它们之间进行划分，但如果您为每次写入使用随机UUID，则写入时不应出现热分区问题。
2）绝对是数据库变慢或是应用程序吗？可能是您按顺序执行写操作而不是并行执行或者可能使用同步调用而不是异步调用
3）您是否在控制台中查看了dynamoDB指标？您应该能够在那里查看平均放置延迟和限制请求等指标。这可能会为你带来一些启示
答案 1 :(得分：0)
想到的事情很少：
您是否有机会使用扫描？这可以解释性能下降，因为扫描不会利用有关如何在DynamoDB中组织数据的任何知识，而只是一种强力搜索。您应该避免使用扫描，因为它们本身就很慢而且价格昂贵。
你有一个＆＃34;热门分区＆＃34;？你写道：
- schedule - 使用SId作为hashkey 2. summary - 使用DynamoDBAutoGeneratedKey（UUID）作为hashkey，使用SId作为属性 它。
对这些值的访问是否均匀分布？您是否拥有比其他人更频繁访问的项目？如果是这样，这可能是一个问题，如果您的大多数读/写来自一小部分ID，那么这意味着您正在使用请求充斥单个分区（物理机）。我建议也要对此进行调查。
一种解决方案可以是使用缓存并在那里存储经常访问的项目。您可以使用ElasticCache或DAX - Dynamo中的新缓存解决方案。
我正在使用dynamo db表来保存事务数据
如果您这意味着您正在使用DynamoDB交易，则需要阅读how DynamoDB implements transactions。
简而言之，DynamoDB正在存储您在执行交易时更新/删除/添加的所有项目的副本。此外，DynamoDB事务很昂贵，每个事务需要7N + 4次写入，其中N是事务中涉及的项目数。