ExtendDB：在你自己的資料庫上執行 DynamoDB API

假設有一套醫院病歷系統必須留在院內 — 病患資料絕不能離開地端網路、稽核員會審查每一個相依套件，而開發筆電完全沒有網路。團隊已經把應用程式寫在 DynamoDB API 之上，而且很喜歡它：個位數毫秒的鍵查詢、乾淨的項目模型、不需照看的 schema 遷移。但託管的 DynamoDB 是一項雲端服務，而「把資料送到 AWS」在這裡完全不可行。

ExtendDB 正是為這個落差而打造的。它說的是 DynamoDB 線路協定，但把資料儲存在你所執行的資料庫裡。

ExtendDB 是什麼

ExtendDB 是 AWS 推出的一套開源轉接器 — 由 AWS DynamoDB 工程師撰寫，並 在 AWS Database Blog 上發布 — 它以 Rust 實作了 DynamoDB JSON 線路協定。因為它回應與託管服務相同的 HTTP API，你既有的 AWS SDK 與 AWS CLI 都能原封不動運作。唯一變動的只有 endpoint URL — 不需重寫程式碼、不需新的用戶端函式庫。

有趣的部分在於那個 API 背後的東西。ExtendDB 有可插拔的儲存後端：PostgreSQL 是參考實作，而 Cassandra 則被列為另一個可能的後端。新的後端是在不修改核心的情況下實作的，所以 DynamoDB 相容層與儲存層各自獨立演進。

於是一次請求的流動像這樣：

它支援什麼 — 又不支援什麼

根據入門文件與該公告，ExtendDB（v0.1）涵蓋了大多數應用程式實際會呼叫的操作：

• 表格 — Create、Delete、Describe、List、Update。
• 項目 — Put、Get、Delete、Update（包含 SET / REMOVE / ADD / DELETE 更新動作）。
• Query 與 Scan — 鍵條件、filter 表達式、投影、分頁與 secondary index。
• 批次 — BatchGetItem 與 BatchWriteItem。
• 交易 — TransactGetItems 與 TransactWriteItems。
• Streams、TTL、Import/Export 與 Tags。

它刻意不實作的，是那組DynamoDB 特有的託管功能 — 最顯著的是 Global Tables 與跨區域複寫。那些是託管服務全球基礎設施的性質，而非 API 介面的性質，所以它們不會移轉到一個你自行託管的轉接器上。

與 DynamoDB Local 的比較

你可能已經用 DynamoDB Local 來做離線開發。那是一個單一的 JAR（或 amazon/dynamodb-local Docker 映像檔），用於在單一機器上做單元測試。ExtendDB 的目標比那個單一程序的工具更廣：本機開發、地端部署、邊緣與氣隙環境，以及你想要 DynamoDB API、但資料存放在你所掌控的基礎設施中的混合／多雲設定。

與託管 DynamoDB 的比較

這是 AWS 明確劃下的界線，而且很重要：

ExtendDB 不是 DynamoDB。它是一個相容的實作，而非託管服務的替代品。效能特性、擴展行為與維運性質都有所不同。

具體而言，當你執行 ExtendDB 時：

• 資料庫的可用性與備份由你負責。 沒有託管的多 AZ 耐久性或時間點復原替你完成 — 那是你與你的 PostgreSQL 維運的責任。
• endpoint 上的 TLS 是強制的。
• 憑證是類 IAM 但與 AWS IAM 分離的 — ExtendDB 有自己的憑證模型；它不會對你的 AWS 帳戶進行驗證。

它是 v0.1，並以 Apache 2.0 授權。請把它當成早期軟體：對上述環境很棒，但不是正式環境規模的託管 DynamoDB 的即插即用替代品。

設定

ExtendDB 在 Linux 與 macOS 上執行，需要 Rust 1.85+ 與 PostgreSQL 14+。流程是兩個指令：

extenddb init
extenddb serve

init 會在你的 PostgreSQL 資料庫中佈建 schema；serve 會啟動線路協定伺服器，它會監聽一個像 https://127.0.0.1:8000 的 endpoint（TLS 是必要的，因此用 https）。

把 AWS SDK 指向它的方式，就跟你對任何自訂 endpoint 一樣 — 只有 URL 與憑證會變：

import {DynamoDBClient} from '@aws-sdk/client-dynamodb';

const client = new DynamoDBClient({
  endpoint: 'https://127.0.0.1:8000',
  region: 'local',
  credentials: {accessKeyId: '<extenddb-key>', secretAccessKey: '<extenddb-secret>'}
});

用戶端組態之後的一切 — PutItem、Query、TransactWriteItems — 都與你針對託管 DynamoDB 所寫的程式碼完全相同。單一表格的項目佈局運作起來，就跟在雲端裡一模一樣：

在 DynoTable 中實作

因為 ExtendDB 說的是 DynamoDB 線路協定，你不需要為它另外準備一個管理工具 — 把 DynoTable 指向 ExtendDB 的 endpoint，方式就跟你連接 DynamoDB Local 一樣：用 ExtendDB 的連接埠與用過即丟的憑證建立一個離線（本機）設定檔，DynoTable 就會瀏覽、查詢並編輯這些項目 — 只是現在它們是由你自己磁碟上的 PostgreSQL 支撐，而不是某個 JAR 的記憶體內儲存。

這就是線路協定相容性的回報：SQL Workbench、視覺化查詢建構器與項目編輯全都能原封不動地針對 ExtendDB 運作，所以你不必寫 scan 指令碼，就能在你自行託管的資料上獲得一個真正的 GUI。

有一個需要事先規劃的注意事項：ExtendDB 的 endpoint 是僅 HTTPS 的，而 DynoTable 的離線設定檔（如同大多數 DynamoDB-Local 設定）瞄準的是一個回送 host:port。若你的用戶端或工具需要一個明文的回送監聽器，請在 ExtendDB 前面終結 TLS（或執行一個本機反向代理），並把 GUI 指向它 — 不論如何，線路上的協定仍然是 DynamoDB JSON。

陷阱

• 別把 v0.1 當成正式環境的 DynamoDB。 擴展性、延遲與耐久性是你 PostgreSQL 的，不是 AWS 的。在你仰賴它之前，先針對你的工作負載做基準測試。
• 沒有 Global Tables／跨區域複寫。 若你的設計仰賴多區域主動-主動，ExtendDB 不是這條路 — 那是託管服務的功能。
• 自行備份底層資料庫。 沒有託管的 PITR；一個遭刪除的 PostgreSQL 磁碟區就此消失。請像對待任何其他 PostgreSQL 一樣，接上 pg_dump / WAL 封存。
• 憑證是 ExtendDB 自己的，不是 AWS IAM。 別指望用 IAM 政策、角色或條件鍵來治理存取 — 那套授權模型並不會移轉過來。

後續步驟

• 先為你的存取模式建模 — 不論後端是 DynamoDB 還是經由 ExtendDB 的 PostgreSQL，同一套單一表格設計紀律都適用。
• 用 DynamoDB 表達式建構器 建構並檢視你的讀寫，再用 DynamoDB-JSON 轉換器 在純 JSON 與線路格式之間轉換你的測試資料。
• 當你準備好戳戳一個實際的 ExtendDB 執行個體時，連接 DynoTable 並像瀏覽任何其他表格一樣瀏覽它。