我一直在閱讀常見問題和其他帖子,試圖瞭解DynamoDB在讀寫容量單位方面的行爲。說我掃描一張桌子,這超過了我的閱讀容量單位。我是否正確地假設DynamoDB將首先調整請求,然後以較慢的方式返回所有結果?請求會在什麼時候失敗,而不是被限制?DynamoDB和預置容量:節流與故障
1
A
回答
2
如果您的請求超出配置容量,您將收到一個ProvisionedThroughputExceededException
錯誤。
的Error Handling documentation說:
您的請求率太高。 DynamoDB的AWS軟件開發工具包會自動重試接收此異常的請求。您的請求最終會成功,除非您的重試隊列太大而無法完成。使用指數回退降低請求的頻率。
此外,請注意DynamoDB提供突發容量。從Guidelines for Working with Tables文檔:
DynamoDB提供了在每個分區可以通過配置一些靈活性。如果沒有充分利用分區的吞吐量,DynamoDB會保留一部分未使用的容量,以便以後的突發吞吐量使用率爲。 DynamoDB目前保留長達五分鐘的(300秒)未使用的讀取和寫入容量。在偶爾爆發讀取或寫入活動期間,這些額外的容量單位可以非常快速地被消耗,甚至比您爲表格定義的每秒供應吞吐量更快。但是,請勿設計您的應用程序,以便它能隨時提供爆發容量:DynamoDB可以並且確實將爆發容量用於後臺維護和其他任務,而無需事先通知。
因此,自動重試加爆發容量的組合意味着它很可能會收到吞吐量異常。如果你這樣做,然後指數退縮並重試。
某些DynamoDB用戶維護用於臨時存儲事務的Amazon SQS隊列。如果超出吞吐量,它們將事務存儲在SQS隊列中。然後,後臺進程從隊列中檢索事務,並在希望獲得更多吞吐量時重試它們。
相關問題
- 1. 節點光纖與流星的故障
- 2. Javascript流量控制故障
- 3. 與其自身的故障預置值CSS變量
- 4. 節點故障
- 5. DynamoDB節流
- 6. C#故障設置變量
- 7. Rsync與Env變量故障
- 8. Couchbase節點故障
- 9. DynamoDB BatchWriteItem - 無節流?
- 10. 與流口水類加載故障
- 11. 常量故障
- 12. 批量故障
- 13. 故障配置TeamCity和dotCover
- 14. 故障與瓶和CSS
- 15. 故障與角
- 16. 故障與Curlpp
- 17. 故障與UITableViewHeaderFooterView
- 18. 故障與UIActivityViewController
- 19. 故障與qfacebookconnect
- 20. 與UIPickerView故障
- 21. 故障與H2
- 22. 故障與PHP
- 23. 流星與DynamoDB
- 24. 對網絡故障流CopyAsync和WriteAsync
- 25. 波段故障中AVX量化代碼與32個字節
- 26. Akka.Net ClusterClientReceptionist多節點故障
- 27. RedShift節點故障切換
- 28. Padrino + MongoMapper /關節故障
- 29. RabbitMQ集羣節點故障
- 30. DynamoDB AutoScaling仍然節流
謝謝,約翰!有道理,因爲我使用iOS SDK。 – sambol