我正在使用Dynamo數據庫表格來保存我的API請求的事務數據。 我維護兩張表 1.計劃 - 以SId作爲hashkey 2.摘要 - 使用DynamoDBAutoGeneratedKey（UUID）作爲hashkey和SId作爲屬性。如何調整DynamoDBAutoGeneratedKey作爲散列鍵的Dynamo數據庫中的表格，因爲PutRequest每次插入的速度越慢
調度表填充每個請求的單個行，而彙總表填充每個SID 10項和
我們在這兩個表中運行的負載測試唯一的UUID和觀察到調度表被表現良好，但彙總表在PutRequests中爲每個呼叫的10個項目消耗了大量時間。
任何人可以建議在我的摘要dynamodb表的性能調整？ 可以保持UUID爲hashkey，減慢PutItemRequest？
任何幫助指針非常感謝。
此外，我們已經激活了這些表中的流，這些流由lambda用於交叉複製。
，想到幾個事情：
是否使用任何機會掃描？這可以解釋性能下降，因爲掃描不會利用有關DynamoDB中數據組織方式的任何知識，而只是一種蠻力搜索。你應該避免使用掃描，因爲它們本質上很慢並且很昂貴。
你有「熱分區」嗎？您寫道：
- 時間表 - 希德作爲hashkey 2.概述 - DynamoDBAutoGeneratedKey（UUID）爲hashkey和SID作爲屬性 它。
訪問這些值是否均勻分佈？你有沒有比其他人更頻繁訪問的項目？如果是這樣，如果您的大部分讀/寫操作都涉及到一小部分ids，則這可能是一個問題，而這意味着您正在使用請求氾濫一個分區（物理機）。我也會建議調查一下。
一個解決方案可以是使用緩存並在那裏存儲經常訪問的項目。您可以使用ElasticCache或DAX - Dynamo中的新緩存解決方案。
我使用發電機數據庫表中保存的交易數據
如果這你的意思是你正在使用DynamoDB交易，你需要閱讀how DynamoDB implements transactions。
長話短說，DynamoDB正在存儲您在執行事務時更新/刪除/添加的所有項目的副本。此外，DynamoDB事務處理非常昂貴，每個事務需要7N + 4次寫入，其中N是涉及事務的多個項目。
彙總表上沒有掃描。沒有熱分區只是UUID作爲hashkey。 –
幾件事情要考慮：
1）是數據庫的吞吐量足夠高的給定負載測試？請注意，如果您有多個分區，則吞吐量將在它們之間分配，但如果每次寫入時使用隨機UUID，則在寫入時不應出現熱分區問題。
2）它肯定是數據庫變慢或者它是應用程序？難道你是按順序執行寫操作，而不是並行執行，或者可能使用同步調用代替異步調用
3）您是否在控制檯中查看了dynamoDB度量標準？您應該能夠看到諸如平均放置延遲和受限制請求等指標。這有可能提供一些線索爲您
早些時候我使用了10個WCU進行負載測試。對於負載測試，將WCU更改爲50以減少響應時間。負載使用3個用戶1小時完成。這一次我分析了該表格的基準，並且Put延遲和掃描延遲出現了上升，但沒有觀察到Throttled寫入請求 –
使用UUID作爲分區鍵不會減慢放置請求的速度。實際上，將UUID作爲分區鍵是一種最佳做法。但是，您是否在同一個請求中爲UUID插入了10個項目？它可能會降低寫入速度，因爲它會轉到同一個分區。你有沒有嘗試增加寫入容量單位？ – notionquest
「交易數據」是什麼意思？ –