DynamoDB vs Redshift
DynamoDB 與 Amazon Redshift 很少是互斥選項。DynamoDB 是營運資料庫 — 對已知鍵做個位數毫秒的讀寫，服務即時應用程式流量。Redshift 是 "a fully managed, petabyte-scale data warehouse service in the cloud," 為掃描與彙總大型資料集而打造，供報表與分析使用。同時運行兩者的團隊才是常態，而 AWS 提供受管整合，在兩者之間單向搬移資料。
你該用 DynamoDB 還是 Redshift？
把 DynamoDB 用於應用程式的即時資料：正在下單、正在讀取的 session、以鍵取出的記錄。當有人需要對整個資料集提問 — 依區域與月份的營收、cohort 留存、串接多個來源的儀表板 — 就用 Redshift。「選哪一個」通常會收斂成「寫入路徑用 DynamoDB、分析師用 Redshift」，中間由 zero-ETL 整合銜接。
DynamoDB vs Redshift 一覽
| 特性 | DynamoDB | Redshift |
|---|---|---|
| 工作負載 | 營運型（OLTP 風格）— 以鍵做大量讀寫 | 分析型 — 對大型資料集掃描與彙總 |
| 資料模型 | 無 schema 的 NoSQL 項目最大 400 KB；各項目屬性可不同 | 具宣告欄位、distribution key 與 sort key 的關聯式資料表 |
| 查詢語言 | 原生 API（GetItem、Query、Scan、…）加上 PartiQL | 完整 SQL，以及隨之而來的 BI 與 SQL 工具鏈 |
| Join 與彙總 | 無伺服器端 join；彙總不是伺服器端操作 | join、視窗函式、GROUP BY 與其餘分析型 SQL |
| 存取模式 | 圍繞已知鍵設計；Scan 是昂貴的例外 | 為掃描而設計 — 讀取大量列是常態 |
| 延遲 | 每次請求個位數毫秒 | 每次分析查詢數秒到數分鐘，但資料量遠大 |
| 擴充 | 無伺服器；分割區由 AWS 管理 | 無伺服器 workgroup 或佈建叢集；容量依查詢工作負載調整 |
| 新鮮度 | 依需求讀你所寫 | 取決於載入方式 — zero-ETL 整合每 15–30 分鐘落地更新 |
| 定價模型 | 依請求或佈建容量，加上儲存 | 運算容量加上儲存；閒置的無伺服器資料倉儲不計算運算費用 |
何時 DynamoDB 是較佳選擇
- 即時應用程式流量。 對已知鍵做可預測的個位數毫秒讀寫，任何請求率皆可。
- 各項目 schema 不同。 同一資料表中異質項目是 DynamoDB 常態；資料倉儲需要宣告欄位。
- 無伺服器維運。 無叢集要調整大小、修補或暫停。
- 寫入密集路徑。 DynamoDB 以吸收大量寫入為本職；資料倉儲則為大量載入與讀取而最佳化。
何時 Redshift 是較佳選擇
- 跨整張表的問題。 彙總一整年訂單本質上是掃描，正是 DynamoDB 要你避開、而 Redshift 為之設計的存取模式。
- 跨多個來源的 join。 資料倉儲會 join。DynamoDB 沒有伺服器端 join。
- BI 工具鏈。 Redshift 透過 JDBC/ODBC 說 SQL，因此能接入既有儀表板與 "the same SQL-based tools and business intelligence applications that you use today."
- 分析不得干擾正式環境。 對複本跑分析，可把負載從服務使用者的資料表移開。
搭配使用
標準模式是單向：DynamoDB 服務應用程式，一份複本落地 Redshift，分析師在複本上工作。AWS 支援兩條路 — 較舊的 COPY 指令，可直接 "from Amazon S3 or Amazon DynamoDB into Amazon Redshift" 載入，以及受管的 zero-ETL 整合，自行維持複本為最新。
zero-ETL 整合實際做了什麼
「Zero-ETL」聽起來像即時檢視。它不是，而在你圍繞它設計儀表板之前，細節很重要。
它是定時複製管線。 AWS 說得很精確："On activation, the integration exports the full DynamoDB table to populate the Amazon Redshift database." 接著 "the zero-ETL integration then incrementally replicates updates from DynamoDB to Amazon Redshift every 15-30 minutes using DynamoDB incremental exports." 因此 Redshift 中的資料可能落後半小時。對每日報表沒問題，對使用者預期能反映其上一個動作的畫面則不對。
必須啟用 point-in-time recovery — 原因現在很明顯。 先決條件寫得很直白："A zero-ETL integration between Amazon DynamoDB and Amazon Redshift requires your source DynamoDB table to have Point-in-time recovery (PITR) enabled." AWS 在一處記載要求、在另一處記載機制，卻沒有把它們連起來，但你必須附加的資源型政策會露餡 — 它授予 redshift.amazonaws.com 執行 dynamodb:ExportTableToPointInTime。整合建立在 DynamoDB 匯出至 S3 的機制上，而該機制從連續備份讀取。沒有 PITR，就沒有匯出，也沒有整合。
這有預算後果，人們往往很晚才碰到：在大型資料表上啟用 PITR 是依資料表大小持續計費，為分析管線而非為復原而付。請把整合定價成「Redshift 加上 PITR」，而非 Redshift 單獨 — 免費的 DynamoDB 定價計算機 能在你承諾前估算儲存這一側。
兩項限制會擋住既有資料表。 兩者都是文件記載的限制，事後修正都很尷尬：
- "The DynamoDB table and Amazon Redshift cluster need to be in the same Region." 整合多個區域的資料倉儲無法透過這條路全部拉進來。
- "The source DynamoDB table must be encrypted with either an Amazon-owned or Customer-managed AWS KMS key. Amazon managed encryption is not supported for the source DynamoDB table." 以 AWS 受管加密建立的資料表，必須先變更加密設定才能建立整合。
資料形狀會咬你。 DynamoDB 項目依設計就是異質的；資料倉儲資料表有欄位。在單一 partition key 慣例下承載多種實體型別的 single-table design，複製後不會自動變成乾淨的星狀 schema。資料落地後要在 Redshift 規劃建模工作 — 整合拿掉了管線，拿不掉 schema 設計。
何時你還不需要資料倉儲
不是每個彙總都是分析問題。相當大比例的「我們該把這放進 Redshift」起於一個問題 — 有多少項目處於某狀態、某客戶的總計是多少、哪些 partition key 占主導 — 偶爾由工程師對單一資料表提出。
DynoTable 的 SQL Workbench 可直接對 DynamoDB 依需求回答這類問題：真正的 SQL，含 COUNT、SUM、AVG、MIN、MAX、GROUP BY、HAVING 與 DISTINCT，以及 INNER/LEFT JOIN。定位刻意狹窄 — 在 DynamoDB 存取模式規則之內的 SQL。它是單一 SELECT；沒有 CTE、沒有 UNION、沒有視窗函式，也沒有純量子查詢；join 目標必須是 partition key 或 GSI partition key。結果會以部分徽章串流，查詢跑完後才變精確，而讀取資料仍要付讀取成本。
這不能取代資料倉儲，上述限制就是誠實邊界。但它比複製管線、PITR 費用與 schema 設計更快給答案 — 也能在你動工建資料倉儲之前，告訴你這個問題是否值得。執行 Workbench 查詢是付費功能；編輯器與自動完成免費。DynoTable 是一款閉源的商業應用程式；本頁描述它做什麼，而非它如何建構。
FAQ
Redshift 能取代 DynamoDB 嗎？
對應用程式流量不行。Redshift 是為掃描與彙總而建的資料倉儲；它不是為高流量、個位數毫秒鍵查詢而設計。兩者並行，DynamoDB 服務應用程式，Redshift 中的複本服務分析。
Redshift 中的 DynamoDB 資料有多新？
使用 zero-ETL 整合時，最多約落後 30 分鐘。AWS 記載初始完整匯出後，它 "incrementally replicates updates from DynamoDB to Amazon Redshift every 15-30 minutes using DynamoDB incremental exports." 請當成近即時報表，而非即時檢視。
為什麼 zero-ETL 整合需要 PITR？
因為它建立在 DynamoDB 的 point-in-time 匯出上。整合所需的資源型政策授予 Amazon Redshift dynamodb:ExportTableToPointInTime 動作，而該匯出從 PITR 維護的連續備份讀取。因此啟用 PITR 是整合真實、持續的成本。
相關內容
- 學習何時使用 DynamoDB，以及為何 Scan 很昂貴。
- 比較營運型關聯式問題的 DynamoDB 與 PostgreSQL。
- 事先以single-table design建模存取模式。
- 用免費的 DynamoDB 定價計算機估算儲存與容量。
- 下載 DynoTable 以直接查詢與彙總你的 DynamoDB 資料表。
參考資料
- What is Amazon Redshift?
- DynamoDB zero-ETL integration with Amazon Redshift
- Zero-ETL integrations — Amazon Redshift Management Guide
- Point-in-time recovery for DynamoDB
- What is Amazon DynamoDB?
最後驗證於 2026-08-02，比對官方 AWS Redshift Management Guide 與 DynamoDB Developer Guide。