DynamoDB vs Amazon Neptune

DynamoDB 與 Amazon Neptune 都是全受管的 AWS 資料庫，但它們以根本不同的方式建模資料。DynamoDB 是你以 key 查詢的鍵值與文件儲存。Neptune 是專為圖形而建的圖形資料庫，儲存節點與邊（或 RDF triple），並以圖形查詢語言直接走訪關係。選擇關鍵在於：關係是否是你主要要查詢的東西。

你該用 DynamoDB 還是 Neptune？

當你需要對大規模的結構化記錄做基於 key 的存取，且關係有限、可用 key 建模時，選 DynamoDB。當連結是你查詢的核心 — 多跳走訪、最短路徑、推薦、詐欺環、知識圖譜 — 亦即圖形模型能用一次查詢表達出在鍵值儲存中需多次往返的事情時，選 Amazon Neptune。你的查詢有多以關係為重心決定了答案。

DynamoDB vs Amazon Neptune 一覽

特性	DynamoDB	Amazon Neptune
資料模型	NoSQL 鍵值與文件；表中型別 item 最大 400 KB	圖形 — property graph（帶屬性的節點/邊）與 RDF（subject-predicate-object triple）
查詢語言 / API	原生 API（`GetItem`、`Query`、`Scan`）加上 PartiQL，一種 SQL 相容語言	property graph 用 Gremlin 與 openCypher；RDF graph 用 SPARQL
主要存取	對 partition/sort key 的基於 key 查找；關係以 key 建模	關係走訪 — 在單一查詢中跨多跳走過邊
關係	無原生走訪；以 adjacency list 或 single-table design 建模	邊是一等公民；多跳與路徑查詢為原生且高效
一致性	預設最終一致；可逐請求使用強一致讀取	讀取在叢集內一致；讀取複本服務擴充讀取
擴充模型	自動分割；無伺服器隨需或佈建容量	佈建 DB 執行個體加讀取複本，或 Neptune Serverless（容量以 NCU 計）自動擴充
交易	在單一 Region 內跨多個 item 的 ACID 交易	針對圖形變更的 ACID 交易
定價 / 營運模式	依請求付費（隨需）或佈建容量加上儲存；無伺服器	執行個體小時（佈建）或 NCU 小時（Serverless），加上儲存與 I/O；僅限 AWS
最適合的工作負載	個人檔案、session、購物車、事件 — 大規模的基於 key 記錄	社交圖譜、推薦、詐欺偵測、知識圖譜、網路/身分圖譜

DynamoDB 較適合的時機

你的存取是基於 key。 get-by-id、query-a-partition 與 filter-within-a-partition 都自然對應到 DynamoDB，並在任何規模下維持快速。
關係淺或有界。 一對多與多對多的連結可用 key 建模 — 用 adjacency list或 single-table design — 不需圖形引擎。
你想要無伺服器的簡潔與依請求付費。 隨需容量沒有東西要調整大小，閒置時可縮到零。
你不做深層走訪。 如果你很少走超過一兩跳，圖形資料庫的優勢就閒置未用。

Neptune 較適合的時機

關係就是查詢。 多跳走訪 — 朋友的朋友、最短路徑、「誰與誰相連」— 在 Gremlin、openCypher 或 SPARQL 中是原生的，而鍵值儲存則需要多次循序讀取。
你需要 property graph 或 RDF。 Neptune 支援兩種模型與它們的標準查詢語言，適合知識圖譜與 linked-data 使用情境。
你的領域是圖形形狀。 詐欺偵測、推薦引擎、社交網路與身分/網路圖譜，都能自然地表達為節點與邊。
走訪模式持續演變。 新的關係問題就是新的圖形查詢，而非重新設計你的 key。

一條有用的經驗法則：DynamoDB 可用 adjacency-list 模式表達關係，當你事先知道走訪且它們維持淺層時，這樣就足夠了。當走訪很深、深度不定或臨時時，Neptune 的圖形引擎正是為此而建，並避免在鍵值儲存中走邊時的多次往返成本。

使用 DynamoDB

如果你的工作負載是基於 key，且你用 adjacency list 建模關係，DynoTable 是一款在 macOS、Windows 與 Linux 上的原生桌面 DynamoDB 用戶端。它會讀取你標準的 AWS 憑證鏈，因此你的資料留在 DynamoDB 中，沒有東西要遷移。它可瀏覽並就地編輯 item、以視覺化方式建立 key condition 與 filter，並加上一個 SQL Workbench，在 DynamoDB 的存取模式規則內表達關聯形狀的查詢，還有一個使用你自己 AWS Bedrock 憑證的 AI 助理。

免費的 DynamoDB Expression Builder會產生 adjacency-list 模型所需的 key condition、filter 與 update expression，並提供 SDK、CLI 與 PartiQL 形式。DynoTable 是一款閉源商業應用程式；本頁描述它做什麼，而非它如何建構。

FAQ

DynamoDB 可以當圖形資料庫用嗎？

部分可以。DynamoDB 沒有原生的圖形走訪，但你可以用 adjacency-list 模式或 single-table design 建模關係，當走訪已知且淺層時運作良好。對於深層、深度不定或臨時的走訪 — 最短路徑、多跳推薦 — 像 Neptune 這種專為圖形而建的資料庫更為合適，因為它以原生方式走邊，而非發出許多分開的讀取。

Neptune 與 DynamoDB 各支援哪些查詢語言？

Neptune 為 property graph 支援 Gremlin 與 openCypher，為 RDF graph 支援 SPARQL。DynamoDB 使用其原生 API（GetItem、Query、Scan 及相關操作）加上 PartiQL，一種 SQL 相容語言。查詢語言沒有任何重疊 — 模型是不同的。

我何時該選 Neptune 而非 DynamoDB？

當連結是你最常查詢的東西時選 Neptune：多跳走訪、路徑尋找，或以關係為中心的領域，如詐欺偵測、推薦與知識圖譜。當存取主要是基於 key，且關係有限到足以用 key 建模時選 DynamoDB。有些架構兩者並用 — 用 DynamoDB 存放營運記錄，用 Neptune 存放其上的連結圖譜。