DynamoDB 隨需輸送量：實測結果
一張全新的 DynamoDB 隨需表能得到多少輸送量？
一張全新的表能提供大約每秒 4,130 次寫入——AWS 文件記載的數字是 4,000——以及至少每秒 12,700 次最終一致讀取。我們在 2026-08-27 對一張幾分鐘前才建立的表做了兩項實測：在我們提供的每一個超過基準線的負載下，寫入都穩定在 4,130 ±2/s，而讀取在我們自己的負載產生器耗盡餘量之前，完全沒有被限流過。
這兩個數字，以及本頁其他所有內容，都來自對即時服務的真實請求計數——而不是照抄文件。方法、原始資料，以及三次失敗的嘗試，都寫在這篇基準測試紀實裡；本頁則是這些數字所依附的參考頁。
全新表的寫入上限
在一張從未見過流量的表上，以 30 秒為一個視窗逐步加大提供的負載。每個請求都攜帶一個約 1 KB 的項目，鍵是均勻隨機的——不涉及：
| 提供負載（寫入/秒） | 實際達成 | 被限流的請求 |
|---|---|---|
| 1,000 | 1,000 | 0 |
| 2,000 | 2,000 | 0 |
| 3,000 | 3,000 | 0 |
| 4,000 | 4,000 | 0 |
| 5,000 | 4,132 | 25,992 |
| 6,000 | 4,131 | 55,966 |
| 8,000 | 4,134 | 115,922 |
文件記載的 4,000 寫入/秒基準線成立，上面還有約 3% 的餘量。這個上限相當平坦：在提供 5,000、6,000 和 8,000 時，實際達成的分別是每秒 4,132、4,131、4,134。跨過這個上限時延遲並不會變差——在每一個視窗中，區域內的 p50 寫入延遲都維持在 4–5 毫秒。服務不會變慢；它會拒絕。
限流實際回傳的內容
第一次拒絕出現在每個超過基準線的視窗開始後 0.9–3.8 秒（提供的速率越高，出現得越快）。原文如下：
ThrottlingException: Throughput exceeds the current capacity of your table or index. DynamoDB is automatically scaling your table or index so please try again shortly. If exceptions persist, check if you have a hot key: https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/bp-partition-key-design.html有兩件事值得預先規劃。它是一個 HTTP 400，而不是 5xx——只監看 5xx 的重試策略或告警會完全漏掉隨需限流（各 SDK 預設確實會重試它；參見）。而熱鍵提示只是一個預設建議，不是診斷結果——我們的鍵是均勻隨機的，所以在小規模下，這段訊息的第一嫌疑人是表級別的上限，而不是你的鍵結構。四種不同的限流成因，有它們自己的指南。
讀取上限
讀取是對另一張全新的表發出的，該表已預先寫入 1,000 個項目，以的 GetItem 進行（約 1 KB，每次 0.5 個讀取單位）：
| 提供負載（讀取/秒） | 實際達成 | 被限流的請求 |
|---|---|---|
| 4,000 | 4,000 | 0 |
| 8,000 | 7,941 | 0 |
| 12,000 | 11,119 | 0 |
| 16,000 | 12,762 | 0 |
在每一個速率下都是零限流。文件記載的 12,000 讀取/秒基準線成立，而我們找不到它真正的邊界：在提供 16,000/秒時，我們八個執行器裡有五個先在客戶端達到飽和，所以 12,762/秒是我們的執行器叢集所能達到的上限——而不是 DynamoDB 本身的上限。讀取在區域內的 p50 為 2–4 毫秒。
上限如何隨持續負載成長
AWS 文件記載，隨需容量會成長到最多容納先前峰值的兩倍，而在 30 分鐘內超過先前峰值兩倍以上可能觸發限流。我們對一張表持續施加每秒 8,000 次寫入的提供負載，共 34 分鐘（四個 8 分鐘的波次，波次之間暫停不到一分鐘），並逐分鐘觀察這個上限的變化：
| 波次 | 開始時間 | 每分鐘實際達成的寫入/秒 |
|---|---|---|
| 1 | 06:06 UTC | 4,019 → 4,001 → 4,001 → 3,999 → 3,998 → 4,000 → 4,000 → 4,000 |
| 2 | 06:15 UTC | 5,046 → 5,000 → 4,996 → 4,990 → 4,991 → 4,998 → 4,992 → 4,993 |
| 3 | 06:24 UTC | 5,046 → 4,973 → 4,991 → 4,981 → 4,983 → 4,989 → 4,993 → 5,978 |
| 4 | 06:32 UTC | 7,006 → 6,991 → 6,979 → 6,996 → 6,991 → 6,988 → 7,002 → 6,990 |
解讀這條時間線：
- 第一個上限很黏。 在整個頭 8 分鐘裡，這張表都維持在約 4,000/秒的基準線——在那個視窗內，持續的超額需求並沒有移動它。
- 成長是以約 1,000/秒為一步跳躍的，而不是漸進爬升。 上限在第 9 分鐘左右躍升到約 5,000/秒，在第 26 分鐘左右躍升到約 6,000/秒，一分鐘後又躍升到約 7,000/秒，然後一路平穩維持在 7,000/秒直到結束。每一步都是在一分鐘與下一分鐘之間陡然發生的。三步中有兩步落在我們波次的邊界附近，所以不到一分鐘的暫停可能與這個成長機制有交互作用——我們如實回報觀察到的時間點。
- 半小時的持續需求並未讓上限翻倍。 在以 8,000/秒的提供負載持續 34 分鐘之後，這張表提供了 7,000/秒——是其起始上限的 1.75 倍，仍未達到提供的速率，也未達到乾淨的翻倍。隨著容量成長，被限流的請求逐波次下降（1,900,000 → 500,000）。
如果你的上線日流量會在一張新表上超過約每秒 4,000 次寫入，請預先熱身：要嘛在活動之前先驅動合成負載，要嘛明確設定該表的隨需最大輸送量，讓 AWS 為它預先佈建。隨需對佈建指南說明了各模式分別在什麼情況下勝出，而自動擴縮則是你在這裡看到自動發生的成長機制，在佈建模式下的對應版本。
兩個讓我們意外的數字
- 建立到 ACTIVE 的時間有 3 倍的差距。 同一個區域、同一個 schema，一張全新的隨需表在一次執行中 7.4 秒就到達
ACTIVE，而另外兩次執行則花了 22 秒。在任何「每租戶一張表」或「每次測試一張表」的設計裡，都要為較慢的情況預留餘量。 - 整場基準測試只花了 $0.97。 計費的寫入為 672,116 次，讀取為 1,080,000 次。那趟 34 分鐘的持續成長測試多花了 $12.67。親自測量這個服務，比做出一個錯誤的容量決策要便宜得多——而且你可以用DynamoDB 定價計算器提前為這樣的工作負載估價。
範圍與方法，誠實地說
以上所有內容都是每個階段一張表、一天、一個區域（us-east-1）、約 1 KB 的項目、均勻隨機的鍵。每個分割區的限制（每秒 3,000 個讀取單位／1,000 個寫入單位）低於這裡測得的表級別行為，並有它們自己的失敗模式。帳戶級別的配額與硬性服務限制在 DynamoDB 限制參考裡，以相同的方法測得。而如果你每天都要和 DynamoDB 打交道，DynoTable 就是我們為它打造的桌面用戶端——由同一個團隊打造，帶著同樣的習慣：在覆述任何說法之前，先對照即時服務核實一遍。