DynamoDB 自適應容量

DynamoDB 把你的資料表散布到多個分區上，但你的流量很少均勻分散。爆發容量 和 自適應容量 是兩個自動機制，讓一個偏斜的工作負載不致節流——直到它撞上一個硬性上限。

什麼是 DynamoDB 自適應容量？

DynamoDB 自適應容量是一個自動機制，會把未使用的吞吐量挪向熱分區，讓一個偏斜的鍵不致節流、而資料表其餘部分卻閒置。搭配爆發容量，它能免費吸收尖峰與持續的偏斜——但它無法把單一個鍵推過分區上限。

• 爆發容量 借給你最多 5 分鐘（300 秒）未使用的吞吐量，讓你撐過短暫的尖峰。它是一個緩衝，不是你能調的功能。
• 自適應容量 自動為一個「熱」分區提高吞吐量——從你資料表其餘未使用的容量裡抽取——這樣一個偏斜的鍵就不會節流。
• 它甚至會把一個熱項目隔離到它自己的分區上，給單一個鍵最多到分區上限的 3,000 RCU / 1,000 WCU。
• 它不是忽略鍵設計的許可證。 超過每分區上限後，就沒地方再借了——一個真正熱的鍵仍然會節流。

先認識分區上限

每個分區都各自被封頂：每秒 3,000 讀取單位與 1,000 寫入單位。那個限制是實體的，不是預配的——它在預配與隨需資料表上都成立。（AWS，爆發與自適應容量。）

從 SQL 過來，你會就 總 伺服器負載來推理。在 DynamoDB 裡，會節流的單位是單一分區，而一個偏斜的鍵可能在資料表閒置 90% 的同時就熔毀。那正是這兩個機制存在要彌合的落差。

爆發容量吸收短暫尖峰

每當你沒有完全用掉一個分區的吞吐量，DynamoDB 就把剩餘的存起來。最多 300 秒 的那種未使用容量被留作儲備，而一次突然的爆發能比你每秒的速率正常所允許的更快把它抽乾。

它是隱形且自動的。你無法為它定大小，而 DynamoDB 可能會悄悄把其中一些花在自己的背景工作上。把它當成一個給爆發性流量的緩衝墊——絕不要當成你能據以規劃的餘裕。

自適應容量為熱分區增能

爆發容量處理 短暫 尖峰。自適應容量 處理 持續的 偏斜。當一個分區跑得火熱、而它的鄰居們閒置時，DynamoDB 把吞吐量挪向那個熱的——最多到資料表總量與分區上限。

假設你經營一張車隊遙測資料表，鍵是 VEHICLE#<id>（分區）和 TS#<epoch>（排序）。一台在快閃特賣區的貨車送出的 ping 是任何其他車的 10 倍。它的分區很熱；另外 200 台車的分區則幾乎閒置。

自適應容量察覺到並抬升那一個分區的吞吐量，從那些冷分區未使用的容量裡抽取。無需設定、無成本、無暖機——自 2019 年 5 月起，這個增能實際上是即時的。（AWS Database Blog，「How DynamoDB adaptive capacity accommodates uneven access patterns」。）

那台熱貨車的分區需要 150 WCU，但它 100 WCU 的均分份額會節流；自適應容量從冷分區借來閒置的 WCU 來支應它。

隔離：當問題是單一項目時

偏斜不總是每鍵的——有時是 單一個項目 白熱化。如果不停的流量驅動著一個 VEHICLE#HOT 項目，DynamoDB 的熱度分裂（split-for-heat） 會重新平衡分區，讓那個被頻繁存取的項目單獨落腳。

一旦被隔離，那個單一項目的鍵就能拉到完整的分區上限：3,000 RCU 與 1,000 WCU。那是單一個鍵的絕對天花板——在它之上沒有任何機制。（AWS，超過鍵範圍吞吐量。）

一個值得釘住的但書：當資料表有 Local Secondary Index 時，自適應容量不會把一個項目集合分裂到多個分區上。一個 LSI 把集合綁在一個分區上——參見 GSI 與 LSI 了解原因。

當自適應容量救不了你的時候

這就是陷阱。兩個機制都是把吞吐量 挪來挪去；兩者都不會創造出超過一個分區實體所允許的量。

如果單一個鍵正當地需要每秒超過 1,000 次寫入，沒有任何自動機制能救你——你必須把負載分散到更多鍵上。

寫入分片 是常見的修法：附上一個後綴（VEHICLE#HOT#0 … #9），讓寫入扇散到多個分區，再把讀取扇回來。

那個扇回本身就是一個要刻意建模的存取模式，就像你在單一資料表設計裡會規劃一條查詢路徑那樣——自適應容量買到的是時間，不是鍵設計的免費通行證。

在你自己的資料表上看它

自適應容量在設計上就是隱形的，所以你透過一個症狀來推理它：哪些鍵是熱的。當你建構那條分片的寫入路徑時，運算式建構器會為一個帶後綴的鍵產生 PutItem 和 Query 語法。

要觀察一個鍵實際上如何分布在你的資料上，下載 DynoTable 並在你假設自適應容量已經罩住一切之前，先檢查你真實資料表上的分區分散情況。關於偏斜的讀取面，參見 Query 與 Scan。