DynoTable
中階閱讀時間 1 分鐘

DynamoDB 成本模型：為何 SQL 會隱藏帳單

在 DynamoDB 上跑真正的 SQL 很強大——你能對一個原生完全不提供這些功能的 資料庫使用 JOIN、GROUP BY 和任意的 WHERE 子句。但 SQL 是為具備查詢規劃器、 且每個欄位都有 secondary index 的引擎所設計的，而 DynamoDB 兩者皆無。一個完全 合法的 SELECT 可能會編譯成一次全表 Scan，讀取——並向你收費——表中的 每一個項目。

這就是 SQL 抽象的雙面刃：它讓昂貴的存取模式看起來免費。本指南說明底層的成本 模型，好讓這份便利永遠不會變成一張意外的帳單，並示範 DynoTable 如何在你執行 查詢之前就呈現成本。

為何在 DynamoDB 上跑 SQL 的成本比看起來的高？

關聯式資料庫能有效率地回答 WHERE status = 'active'，因為它會為你查詢的任何 欄位建立索引。DynamoDB 不會。它只在恰好一件事上有效率：partition key （可選擇性地用 sort key 或 global secondary index 收窄）。除此之外 的任何情況都是 Scan。

  • partition key 相等比對就是一次 Query。 DynamoDB 直接跳到該鍵底下的項目， 只讀取那些項目。有界且便宜。
  • 除此之外的任何情況都是 Scan + Filter。 DynamoDB 會讀取表中的每一個項目， 然後把你的 WHERE 當成 FilterExpression 套用——在讀取之後。你要為它 掃描過的所有內容付費，而不是為傳回的那少數幾列。

最後那一點就是陷阱。WHERE 子句看起來像是縮減了工作量。但在非鍵屬性上， 它只縮減了輸出——讀取成本早已花掉。

Query 對 Scan：RCU 計算

DynamoDB 以讀取容量單位（RCU）為讀取計費：

  • 1 RCU = 對最多 4 KB 項目的一次強一致讀取。最終一致讀取花費半個單位。 讀取以每 4 KB 向上進位。
  • 一次 Query 只讀取單一 partition key 底下的項目——成本隨相符的項目而增減， 而非隨整張表。
  • 一次 Scan 會讀取整張表，一次 4 KB。一張 1 GB 的表，單次完整掃描大約是 262,000 個最終一致 RCU——每一次掃描、每一次都是。

FilterExpression 不會減少那個數字。篩選發生在讀取之後，所以帶篩選的 Scan 和不帶篩選的成本完全一樣。用項目大小計算機 和定價計算機算出你資料的真實數字。

哪些 SQL 結構會悄悄變成 Scan？

  • 沒有 partition key 相等比對的 WHERE → 一次全表 Scan，外加讀取後的篩選。
  • JOIN → DynamoDB 沒有伺服器端的 join。每張被連接的表都要分別擷取，再在 用戶端縫合起來——一種 N+1 存取模式，每一個被連接的列都要發一次請求。
  • COUNT、SUM、GROUP BY、聚合 → 不存在伺服器端的聚合，所以每一個相符 的項目都會被讀取。在一次 Scan 上，這代表讀取整張表。
  • 在非鍵屬性上的 ORDER BY 或 DISTINCT → 排序與去重會在用戶端對掃描到 的一切內容進行。

執行這些沒有一個是錯的——有時候一次 Scan 正是你要的。重點在於知道你什麼 時候在跑 Scan。

我該如何讓 SQL 對成本保持誠實？

  • 圍繞你的存取模式來設計索引鍵。 最便宜的查詢就是你的索引鍵結構已經能 回答的那個。用單一表格設計工具和 Query 對 Scan 指南來規劃它。
  • 在 WHERE 裡放一個 partition key 相等比對，就能得到 Query 而非 Scan。
  • 新增一個 GSI 來支援第二種存取模式，而不是掃描再篩選。
  • 在執行前先看成本。 DynoTable 的 Workbench 會把你的 SQL 編譯成實際的 DynamoDB 操作並顯示計畫——Scan 對 Query、它用哪個索引、鍵條件對掃描後的 篩選，以及估計的 RCU 成本——然後就地標示出全表 Scan 與 N+1 join。這就是 DynamoDB 從未推出的那個 EXPLAIN。另見為什麼 Scan 又慢又貴 和隨需對佈建容量。

DynoTable 的 SQL 會讓成本問題更嚴重嗎？

不會——因為它讓成本變得可見。對「在 DynamoDB 上跑 SQL」的批評是公允的： 一個隱藏掃描的抽象，會讓你自己給自己挖坑。DynoTable 的答案不是拿掉 SQL，而是 在它背後放一台成本 X 光機。Workbench 裡的每個查詢都會在執行前預覽它真正的 DynamoDB 樣貌，所以你既保有 SQL 的順手，又保有原生模型帶給你的、對 RCU 與 索引鍵設計的那份誠實。

這些事我需要 AI 代理嗎？

不需要——表格檢視器、SQL Workbench 與成本預覽全都能在沒有它的情況下完整運作。 AI 代理是 DynoTable 的招牌功能之一——一個 DynamoDB 原生的編碼代理，能撰寫理解 schema 的查詢、轉換資料等等——而且你想用的時候它隨時都在。它在你自己的 AWS Bedrock 上執行，所以你直接按成本付費給 AWS（沒有加價），而你的資料絕不會 離開你的帳戶。有幫助時就開啟它；無論如何，核心用戶端本身都是完整的。

我的成果可以帶著走嗎？

可以。DynoTable 說的是標準，而不是封閉花園：標準 SQL、標準的 AWS 憑證與 SSO、 CSV/JSON 匯出、把推斷出的 schema 匯出成 TypeScript、JSON-Schema 或 Zod，以及一個 讓你自己的工具與代理都能連上的 MCP 伺服器。你的查詢、設定與 schema 都能乾淨地 匯出——沒有任何東西被鎖死。

試試看

下載 DynoTable，對你自己的表格開啟 SQL Workbench——成本預覽會在你 執行每個查詢之前，讓你看到它真正的成本。

已更新