DynamoDB 請求路由如何運作

你送出的每次讀取或寫入，都先打到一支無狀態的請求路由器艦隊。一個路由器對你的分區鍵做雜湊、把雜湊對應到擁有那個鍵資料的儲存節點，並把請求轉發到那裡。那一跳就是為什麼一次查鍵無論資料表握有一千個項目或十億個都花一樣的成本。

DynamoDB 的請求路由是如何運作的？

DynamoDB 將每個請求透過一支無狀態的請求路由器艦隊進行路由，艦隊對你的分區鍵做雜湊、將雜湊對應到擁有該分區的單一儲存節點，再把讀取或寫入請求轉發到那裡。路由是鍵雜湊的純函式，因此無論資料表持有一千個項目或十億個，一次查詢的成本都相同。

從 SQL 過來，你想像一個查詢規劃器：它讀統計、挑一個索引，也許掃描。成本隨它碰到多少資料而擴張。那個模型不適合一個必須在任何規模下都以個位數毫秒回答的鍵值儲存。

DynamoDB 的答案是把單一項目查找變成一個直接定址，而不是一個搜尋。分區鍵不是你篩選的一欄——它是一個雜湊函式的輸入，這個函式算出 資料實體上住在哪裡。沒有統計、沒有規劃器。

那是你脫離關聯式思考時所接受的交易：你放棄臨時查詢的彈性，換來常數時間的定址。

當一個請求抵達，它不會直接去到儲存。它打到一個請求路由器——一支無狀態、水平擴展、罩住整個服務的艦隊。（AWS re:Invent「DynamoDB Deep Dive」講座描述了這支前端艦隊。）

路由器做三件事，而且自己不持有任何資料：

因為路由器是無狀態的，服務在負載下會增加更多路由器。它們沒有一個是瓶頸、沒有一個是單點故障——這正是 2007 年 Amazon Dynamo 論文圍繞著建造原始系統的同一個性質。

拿一張給無人機隊的遙測資料表。項目由 DroneId（分區鍵）和 ReadingTs（排序鍵）作鍵，屬性像是 BatteryPct 和 AltitudeM。

你要某一台無人機的最新一筆讀數：

PK = "DRONE#A19F"
SK begins_with "2026-06-23"

這是路由器拿它做的事。下方的引言由上到下追蹤這個請求——把它讀成一個向下的流。

路由器對 DRONE#A19F 做雜湊、把它對應到擁有那個鍵的分區，並把讀取轉發到那個分區的主儲存節點，由它回傳項目。

關鍵洞見：雜湊指向資料表所擁有的眾多分區中的一個。路由器從不看其他分區，所以增加無人機——和分區—— 不會讓這次查找變慢。

一個分區是一個儲存與吞吐量的單位。每個都被封頂（大約 10 GB 和一片固定的讀寫容量），而 DynamoDB 在一個分區長過任一上限時分裂它。每個有給定分區鍵的項目都住在 同一個分區上，這就是讓一個跨單一分區鍵的 Query 便宜的原因。

每個分區被複製到散布在多個可用區的三個儲存節點：一個主和兩個從。

節點角色	處理	它能服務的一致性
主	所有寫入；強一致讀取	強（看見它自己最新的寫入）
從	最終一致讀取；故障切換	最終（可能落後主節點）

一次寫入去到主節點，由它在確認耐久性之前複製到從節點。一次 強一致讀取被路由到主節點，這樣它反映最新的寫入。一次 最終一致讀取可能由一個還沒跟上的從節點服務——半價、可能過期。

路由只和你的分區鍵一樣好。雜湊把鍵均勻分散，所以如果你的鍵有高基數和均勻的流量，負載就分散到所有節點。破壞任一性質，你就得到一個熱分區。

假設你把那份遙測改用 Region 而不是 DroneId 作鍵。現在每台在 us-east-1 的無人機都共用一個分區鍵——所以它們每一次讀取和寫入都雜湊到 同一個 節點。路由器把它的工作做得完美；你只是把整支隊伍漏斗到單一分區的容量上。

你沒辦法看著路由器挑節點，但你可以設計路由良好的鍵。當你在運算式建構器裡建立一個鍵條件時，你放在 PK = … 左邊的分區鍵，正是路由器會去雜湊的那個值——讓那個值保持高基數，正是讓讀取待在不同節點上的關鍵。

請求路由是讓單一資料表設計規則不容妥協的那個機制：你圍繞分區鍵建模，因為分區鍵就是那個位址。這也是為什麼一個 Query 勝過一個 Scan—— 一個 Query 透過路由器打到一個分區，而一個 Scan 是依序走遍每個分區。

次要索引拿到它們自己的分區和它們自己的路由：一個 GSI 由它自己的分區鍵路由，獨立於基底資料表的，這就是為什麼一個 GSI 可以在資料表不熱時也變熱。

設計路由到許多節點、而不是一個節點的鍵。在運算式建構器裡勾勒那個 PK = … 條件，看看究竟哪個值被雜湊，然後下載 DynoTable對著你自己的資料表跑那些查詢，並看著哪些分區鍵實際扛著你的流量。