NoSQL 資料庫選型指南
Redis 與 MongoDB 都常被歸類為 NoSQL 資料庫，但它們解決的核心問題並不相同。Redis 擅長低延遲資料存取與即時資料結構；MongoDB 擅長以文件模型保存及查詢應用資料。選型時不應只問哪一個比較快，而要先確認資料如何被讀寫、查詢與保存。
Redis 與 MongoDB 是什麼？
Redis 是以記憶體為主要存取媒介的資料平台，使用 Key-Value 方式定位資料，並提供 String、Hash、List、Set、Sorted Set、Stream 等資料結構。除了快取，Redis 也可用於工作階段、排行榜、限流、計數器、事件串流與即時特徵存取。
MongoDB 是文件型資料庫，以 BSON 文件保存資料。BSON 是與 JSON 結構相近的二進位格式，能支援更多資料型別。MongoDB 適合保存結構可能持續演進，並且需要依照欄位查詢、聚合或建立索引的應用資料。
Redis vs. MongoDB 核心差異比較
| 比較面向 | Redis | MongoDB |
|---|---|---|
| 核心模型 | 以 Key 存取多種資料結構 | 以 BSON 文件組成 Collection |
| 主要優勢 | 低延遲、原子操作與即時資料處理 | 彈性文件模型、索引、聚合與欄位查詢 |
| 查詢方式 | 依 Key、資料結構操作或搜尋功能查詢 | 依文件欄位、索引與聚合管線查詢 |
| 持久化 | 可使用 RDB、AOF 等機制，需依資料耐久性目標設計 | 資料預設保存於持久儲存，並可搭配複寫與備份 |
| 容量考量 | 常受記憶體容量與成本影響，需要管理資料生命週期 | 適合保存較大量的應用文件資料 |
| 交易與原子性 | 單一命令具有原子性，也支援 Transaction 與 Lua | 單一文件操作具有原子性，也支援跨文件交易 |
| 常見場景 | 快取、Session、限流、排行榜、即時風控、事件串流 | 內容管理、商品目錄、使用者資料與應用後端 |
| 主要風險 | Key、記憶體、淘汰策略與持久化設定不當 | 文件模型、索引與分片設計不符合查詢需求 |
何時適合使用 Redis？
當需求核心是「在極短時間內重複讀寫明確資料」，Redis 通常值得優先評估。
- 資料快取： 降低主要資料庫或外部 API 的重複查詢壓力。
- Session 與權杖： 集中管理登入狀態及具有時效性的資料。
- 限流與計數： 運用原子遞增與 TTL 管理請求次數、交易額度或操作頻率。
- 排行榜與優先佇列： 使用 Sorted Set 依照分數或時間排序。
- 即時事件： 透過 Stream 或 Pub/Sub 支援事件傳遞與即時通知。
- 即時特徵： 讓風控、推薦系統或 AI 應用快速取得近期狀態。
Redis 不應因為「速度快」就直接取代既有的主要資料庫。若資料屬於關鍵交易紀錄，必須先定義最終真實來源、持久化方式、備份機制、復原點目標（RPO）與復原時間目標（RTO）。
何時適合使用 MongoDB？
當資料具有文件結構，而且應用需要依照多個欄位查詢、建立索引或執行聚合時，MongoDB 通常更符合需求。
- 內容與商品資料： 不同文件可以使用不同欄位，適合逐步演進的內容結構。
- 使用者與應用資料： 可將經常一起讀取的資訊嵌入同一份文件。
- 複雜欄位查詢： 適合需要依條件篩選、排序、聚合或搜尋的應用。
- 大量長期資料： 資料需要持久保存，而且不適合全部常駐於記憶體。
- 特殊資料需求： 可依實際版本與部署方案評估地理、時間序列、全文或向量搜尋。
Redis 和 MongoDB 可以一起使用嗎？
可以，而且兩者經常扮演互補角色。常見方式是由 MongoDB 保存需要長期查詢的應用資料，Redis 保存高頻讀取結果、短期狀態或即時計數。
混合架構範例：商品與庫存查詢
- 應用先以商品 ID 查詢 Redis 快取。
- 如果快取命中，直接回傳常用商品資訊。
- 如果快取未命中，再向 MongoDB 查詢完整商品文件。
- 將適合快取的查詢結果寫入 Redis，並設定合理的 TTL。
- 商品更新時，刪除或更新 Redis 快取，避免繼續使用舊資料。
Redis 與 MongoDB 的選型步驟
- 列出資料存取模式： 確認讀寫比例、查詢條件、資料大小、尖峰流量與可接受延遲。
- 定義資料責任： 判斷哪些是短期狀態，哪些是必須長期保存的正式資料。
- 評估一致性需求： 確認是否允許短暫舊資料、是否需要跨文件交易，以及故障時如何復原。
- 估算容量與成本： 將記憶體、磁碟、複寫、備份、網路與維運人力納入評估。
- 使用真實工作負載進行 POC： 測試 P95、P99 延遲、吞吐量、錯誤率、故障切換與資料復原。
- 決定單獨使用或混合部署： 若同時需要低延遲與文件查詢，可以採取分工架構。
若選型結果顯示 Redis 將承接關鍵即時工作負載，可進一步評估 Redis Enterprise 的高可用與部署能力，並依照可用性、復原目標與維運需求設計正式架構。
Redis vs. MongoDB 常見問題
Redis 比 MongoDB 快嗎？
不能脫離工作負載直接下結論。Redis 以記憶體存取與 Key 操作見長，常適合低延遲需求；MongoDB 則提供文件查詢、索引與聚合。應以相同資料、硬體與讀寫模式進行 POC。
Redis 可以當主要資料庫嗎？
可以承接部分主要資料庫工作負載，但必須依資料重要性設計持久化、複寫、備份及復原。對核心帳務等高耐久性資料，不能只依賴預設設定。
MongoDB 是把資料存成 JSON 嗎？
MongoDB 以 BSON 文件保存資料。BSON 與 JSON 結構相近，但採用二進位編碼，並支援更多資料型別。
Redis 和 MongoDB 可以一起使用嗎？
可以。常見架構是 MongoDB 保存完整文件資料，Redis 提供快取、Session、計數器或即時狀態，但必須另外設計快取失效與資料一致性機制。
Redis 與 MongoDB 都算 NoSQL 嗎？
通常都被歸類為 NoSQL，但 Redis 偏向多模型即時資料平台，MongoDB 則是文件型資料庫。NoSQL 只是大分類，不代表兩者用途相同。
選型時最容易忽略什麼？
最容易被忽略的是故障情境、資料復原、容量成本與團隊維運能力。平均延遲表現良好，不代表系統在尖峰或節點故障時仍然符合要求。
