DynamoDB vs MongoDB

你該用 DynamoDB 還是 MongoDB？

若你想要在 AWS 上有一個全受管、無伺服器的鍵值與文件儲存，具備可預測、以鍵為基礎的存取模式與免動手的擴充，請選擇 DynamoDB。若你想要一個文件資料庫，具備彈性的臨機查詢、豐富的彙總管線，並可選擇自行託管或在任一主要雲端上以受管方式執行，請選擇 MongoDB。決定關鍵在於你的存取模式。

DynamoDB 與 MongoDB 速覽

特性	DynamoDB	MongoDB
資料模型	NoSQL 鍵值與文件；項目分組於表格中，每個項目最大 400 KB	文件資料庫；BSON（類 JSON）文件最大 16 MB，分組於 collection 中
查詢語言 / API	原生 API（`GetItem`、`Query`、`Scan`、`PutItem`…）加上 PartiQL，一種 SQL 相容查詢語言	MongoDB Query API（MQL）加上用於多階段轉換、join（`$lookup`）與分組的彙總管線
主要存取模式	在 partition key（及可選的 sort key）上以鍵為基礎的查找；schema 需事先圍繞已知存取模式設計	對任意欄位的彈性查詢；由索引支援的臨機 filter 與彙總
Secondary index	global secondary index（自有輸送量、任意鍵）與 local secondary index（相同 partition key，每分割上限 10 GB）	對任意欄位的 secondary index，包括複合、multikey、text、地理空間與 wildcard 索引
一致性模型	預設最終一致讀取；可依請求使用強一致讀取（在單一 AWS Region 內）	可調整的 read/write concern；預設從主要節點的讀取為強一致
擴充模型	由 AWS 管理的自動分割；擴充輸送量與儲存而無需佈建伺服器	透過跨叢集分片達成水平擴充；replica set 提供高可用性與容錯移轉
交易	跨多個項目的 ACID 交易，範圍限於單一 AWS Region	多文件 ACID 交易（自 4.0 起），包含跨分片（自 4.2 起）
定價模型	依請求付費（隨需）或佈建容量，加上儲存；無伺服器需執行	Atlas 以叢集為基礎（實例大小／時數）並提供低成本的 Flex 層；自行託管的 Community 版僅需基礎設施成本
受管 / 無伺服器選項	完全無伺服器且全受管；僅限 AWS	在 AWS、Google Cloud 或 Azure 上的 Atlas 受管服務；亦可自行託管。Atlas Serverless 實例已停用，並由 Flex 層取代
最適合的工作負載	需要一致低延遲與最少維運、具可預測鍵存取的高規模應用	具演進中 schema、臨機查詢與豐富彙總，或需要多雲／地端可攜性的應用

何時 DynamoDB 是更好的選擇

你在 AWS 上，且想要零資料庫維運。 DynamoDB 是無伺服器的——沒有實例、叢集或容量需要修補。隨需模式會自動隨流量擴充（容量模式）。
你的存取模式已知且以鍵為基礎。 當你能圍繞讀取資料的方式設計鍵時，DynamoDB 能在幾乎任何規模下提供一致的低延遲查找。這正是單一表格設計發光的地方。
你想要依請求付費的定價。 使用隨需容量，你只需為你所做的讀寫付費，沒有閒置叢集成本。
你需要與 AWS 緊密整合。 與 IAM、Lambda、串流及更廣泛 AWS 生態系的原生連結能減少膠合程式碼。

何時 MongoDB 是更好的選擇

你的查詢是臨機或探索性的。 MongoDB 讓你能對任意欄位進行 filter 與索引，並執行豐富的伺服器端彙總——包括跨 collection 的 join——而無需預先規劃每一種存取模式。
你需要跨雲端或地端的可攜性。 MongoDB 可自行託管，或在 AWS、Google Cloud 與 Azure 上透過 Atlas 執行。DynamoDB 僅限 AWS。
你的文件龐大或深度巢狀。 MongoDB 的 16 MB 文件上限遠大於 DynamoDB 的 400 KB 項目限制（DynamoDB 約束）。
你的 schema 快速演進。 彈性文件加上一流的 secondary indexing 適合快速變動的模型，無需僵化的事前鍵設計。

使用 DynamoDB

一旦你選定了 DynamoDB，你日常仍需要一個快速的方式來瀏覽表格、執行查詢與編輯項目。DynoTable 是一款 DynamoDB 的原生桌面 GUI：瀏覽並就地編輯項目、建構 key condition 與 filter，並以 SQL workbench 與 AI 助手進行查詢。如果你來自 MongoDB 那種「什麼都能查」的思維模式，SQL workbench 能協助你在 DynamoDB 的存取模式規則內表達關聯式形態的查詢。

若要在不離開文件的情況下建構運算式，免費的 DynamoDB Expression Builder 會產生 key-condition、filter 與 update 運算式，並提供可直接貼上的 SDK、CLI 與 PartiQL 輸出。而如果你剛接觸鍵值儲存的建模，如何在 DynamoDB 中建模資料指南會逐步說明如何將實體與存取模式轉譯為鍵。

FAQ

DynamoDB 比 MongoDB 快嗎？

兩者都不是普遍地更快——這取決於工作負載以及資料如何建模。DynamoDB 的設計是為以鍵為基礎的存取，在大規模下提供一致的低延遲效能，而 MongoDB 對於已建索引與臨機的查詢可以非常快。就真實世界的延遲而言，正確的資料模型比引擎更重要。

DynamoDB 能取代 MongoDB 嗎？

有時可以。如果你的存取模式可預測且以鍵為基礎，DynamoDB 可以取代 MongoDB 並消除大部分維運負擔。如果你仰賴跨許多欄位的臨機查詢或伺服器端彙總，遷移就意味著必須先圍繞 DynamoDB 的鍵重新建模你的資料——請參閱如何在 DynamoDB 中建模資料。

DynamoDB 是以 MongoDB 為基礎嗎？

不是。它們是來自不同公司、彼此無關的產品。DynamoDB 是一個 AWS 受管資料庫，其設計淵源可追溯到 Amazon 內部的 Dynamo 研究，而 MongoDB 則是一個獨立、源自開源的文件資料庫。它們共用「NoSQL」這個標籤，但沒有共用任何程式碼庫。