何時該用 DynamoDB（以及何時不該）
對於它所打造的工作負載，DynamoDB 是一款絕佳的資料庫；對於其餘的，它則令人沮喪。決定性的 問題不是「它能否撐起網路規模？」 — 而是**「我是否事先就知道我的存取模式，而且它們是 以鍵為基礎的嗎？」** 這點搞對，DynamoDB 就能在任何規模下給你個位數毫秒的讀取；搞錯，你就會 永遠跟它缺乏 join 與臨機查詢的限制纏鬥。
何時應該使用 DynamoDB？
當你的存取模式已知、以鍵為基礎且高流量，並且希望在任何規模下都能獲得可預測的個位數毫秒延遲、 無需管理任何伺服器時，請選擇 DynamoDB。若需要臨機查詢、豐富的 join，或對整個資料集做分析， 或者資料量很小且查詢形態持續變動，則應避免使用。
- 在以下情況使用 DynamoDB：你的存取模式已知、以鍵為基礎且高流量 — 而且你想要在任何 規模下都有可預測的延遲，並且不必管理任何伺服器。
- 在以下情況避免它：你需要臨機查詢、豐富的 join，或對整個資料集做分析，或者資料量很小 且查詢形態不斷改變。
- 核心取捨： DynamoDB 逼你事先為查詢做設計；作為回報，它在你成長時絕不變慢。
- 它不是一個換了不同語法的關聯式資料庫 — 把它當成關聯式資料庫來建模，是頭號的痛苦來源。
偏好 DynamoDB 的訊號
當以下大多數條件成立時，DynamoDB 大放異彩：
- 你事先就知道你的存取模式。 你能列出應用程式所做的確切查詢（「依 id 取得一位使用者」、 「列出某使用者的訂單，最新者優先」），而且它們不會說變就變。DynamoDB 正是圍繞那些查詢 來建模的。
- 存取是以鍵為基礎的。 你以已知的 partition key 查找項目，而非為了任意的屬性組合而 掃描。
- 規模與可預測的延遲很重要。 無論表格存有一千個還是十億個項目，DynamoDB 都提供 一致的個位數毫秒效能。
- 你想要零營運負擔。 沒有執行個體、沒有故障轉移、沒有 vacuum — 它是全託管的，並在隨需 模式下可縮減至零。
- 寫入輸送量高且尖峰。 事件記錄、IoT 遙測、工作階段/購物車狀態、排行榜 — 帶有明確鍵的 以附加為主的工作負載。
不利於它的訊號
當以下情況成立時，改用關聯式資料庫（或搜尋/分析引擎）：
- 你的查詢是臨機的。 分析師以任意欄位切分資料，或者需求每週都在變。SQL 的彈性勝出； DynamoDB 會需要為每個模式新增一個 index。
- 你需要跨整個資料集的真正 join 與聚合。 報表、商業智慧、「依地區依月份加總營收」 — 那是 OLAP/關聯式的活。
- 資料集很小且低流量。 一個安靜的管理後台上幾千列資料，從 DynamoDB 的規模中得不到好處， 卻失去了 SQL 的便利。
- 你還無法預測存取模式。 還在摸索形態的早期產品？一個你能自由重新查詢的關聯式 schema， 在模式塵埃落定前更為寬容。
在投入之前先算清成本
DynamoDB 的定價隨讀取、寫入與儲存而定 — 而非執行個體時數 — 因此對尖峰與無伺服器工作負載 很便宜，而對持續的大量掃描則可能昂貴。在投入之前，用 DynamoDB 定價計算機為你真實的讀取/寫入組合建模； 一個技術上看似合適的工作負載，在成本上也應該算得過去。
一旦你判定它合適
工作就轉向建模。DynamoDB 獎勵圍繞你的查詢來設計表格 — 參見如何在 DynamoDB 中建模資料與 單一表格設計 — 以及明確地 何時不該採用單一表格。
陷阱與後續步驟
- 別把 DynamoDB 當成關聯式資料庫來建模 — 正規化的表格、在讀取時做 join，正是它懲罰 最重的反模式。
- 別為了分析而選它 — 把它與一個分析儲存搭配（或匯出到其中）來做報表，而非掃描表格。
- 不確定存取模式嗎？等等再說。 在你還不知道查詢之前就採用 DynamoDB，等於是選了那個 偏偏要求你知道查詢的資料庫。
- 相關： query 與 scan 的比較會告訴你「以鍵為基礎的存取」 實際上換來了什麼。
想在把你的應用押在 DynamoDB 上之前先探索一個 DynamoDB 表格嗎？ 下載 DynoTable，直接連線到你的資料。