資料庫總覽與選型 (Database Overview & Selection)
一句話定位
資料庫選型不是背 feature list，而是建一張地圖。看清兩個正交維度——資料模型（形狀）與工作負載（OLTP/OLAP）——大多數資料庫的定位就清楚了。
面試心法：從需求推導選擇，不要一上來就比較「SQL vs NoSQL」。
兩個正交維度
理解資料庫，兩個維度最重要，而且互相獨立：
| 維度 | 問題 | 取值 |
|---|---|---|
| 資料模型（Data Model） | 資料長什麼形狀？ | 表格 / 文件 / Key-Value / 寬欄 / 圖 / 向量 |
| 工作負載（Workload） | 是交易型還是分析型查詢？ | OLTP（高並發點查詢）/ OLAP（海量聚合） |
面試先跑這兩問
「資料是什麼形狀？」「這是交易型還是分析型？」答案通常就指向正確方向。
關聯式資料庫（RDBMS）
資料以表格存在，row 是記錄、column 是屬性，表格間用 Foreign Key 關聯，用 SQL 查詢。最成熟、最廣泛使用。
ACID 是核心承諾
| 屬性 | 含義 |
|---|---|
| Atomicity（原子性） | 「扣庫存+建訂單+記付款」要麼全成功要麼全回滾 |
| Consistency（一致） | 事務前後所有 constraint（外鍵、唯一鍵）都滿足 |
| Isolation（隔離） | 並發事務互不干擾，看不到彼此中間狀態 |
| Durability（持久） | commit 後即使崩潰也不遺失 |
任何涉及錢、庫存、狀態轉換的操作，出錯要能乾淨回滾 —— 這正是 ACID 解決的問題。
強大的查詢能力 + 限制
- ✅ SQL 表達力強：JOIN、聚合、子查詢、視窗函數，複雜關係幾行搞定（換 NoSQL 要在應用層寫一堆程式碼）
- ⚠️ Schema 是雙面刃：結構整齊可靠，但大資料量下改 schema 成本高
- ⚠️ 水平擴展困難：天生適合垂直擴展；水平擴展需 Sharding，跨節點事務/JOIN 複雜度暴增，且多數 RDBMS 沒有原生 sharding
NoSQL：五種資料模型
NoSQL（Not Only SQL）不是單一東西，而是「放棄/弱化關聯模型換取擴展性或彈性」的一系列資料庫統稱。
| 類型 | 模型 | 擅長 | 代表 |
|---|---|---|---|
| Key-Value | key → value，只有 get/set/del | 快取、Session、計數器、排行榜 | Redis、DynamoDB |
| Document | JSON 文件，可巢狀、無固定欄位 | 設定檔、CMS、產品目錄、快速迭代 | MongoDB |
| Wide-Column | Column Family，按 column 排放 | 高寫入吞吐、時序、明確 access pattern | Cassandra |
| Graph | 節點 + 邊，關係是一等公民 | 社交網路、推薦、知識圖譜（多跳） | Neo4j（Cypher） |
| Vector | 高維 embedding + ANN 搜尋 | 語意搜尋、RAG、以圖搜圖、推薦 | Pinecone、pgvector |
BASE：NoSQL 的共同取捨
NoSQL 通常遵循 BASE 而非 ACID：
- Basically Available：允許部分節點故障
- Soft state：狀態可能隨時間改變
- Eventual consistency：最終收斂，不保證任何時刻一致
放鬆一致性 → 資料可分散到多節點、各自獨立處理請求、不需跨節點協調 → 換得 RDBMS 難做到的水平擴展。
Cassandra 是 OLTP，不是分析系統
Cassandra「write anywhere」用最終一致換超高寫入吞吐 + 無單點故障。它按 row 儲存，適合高並發寫入與明確 primary key 查詢，不適合跨 row 聚合分析。
OLTP vs OLAP（與資料模型正交）
這是另一個獨立分類維度，和 RDBMS vs NoSQL 正交。
| 維度 | OLTP（交易型） | OLAP（分析型） |
|---|---|---|
| 設計目標 | 高並發點查詢 + 小量寫入、毫秒延遲 | 海量歷史資料聚合，幾秒~幾分 |
| 儲存 | Row-oriented | Column-oriented |
| 代表 | PostgreSQL、DynamoDB、Cassandra | BigQuery、Redshift、ClickHouse、Snowflake |
實際架構：業務資料先進 OLTP，再透過 ETL / CDC 搬到 OLAP，讓分析查詢完全不影響線上業務效能。詳見 06-Database-Tech/04-OLTP-vs-OLAP。
Vector Database
ML / LLM 興起的特殊類別。傳統 DB 做精確查詢（user_id = 123）；向量 DB 做相似度搜尋（「和這段文字語意最接近的 10 筆」）。
用戶輸入：「適合長距離跑步的鞋」
↓ Embedding 模型
向量：[0.23, -0.71, 0.45, ...]（1536 維）
↓ ANN（Approximate Nearest Neighbor）搜尋
結果：慢跑鞋 A、路跑鞋 B、馬拉松鞋 C
- 應用：語意搜尋、RAG、以圖搜圖、推薦系統
- 獨立向量 DB：Pinecone、Weaviate、Milvus
- 整合現有 DB：pgvector、Redis VSS、Elasticsearch
- 詳見 08-Search-and-AI/04-Vector-Database
面試選型：依序問三個問題
不要背比較表，要展示推導過程
第一：資料什麼形狀、什麼查詢模式？
| 需求 | 選擇 |
|---|---|
| 固定結構、需複雜 JOIN | RDBMS（PostgreSQL） |
| Key-Value 存取、超低延遲 | Key-Value（DynamoDB、Redis） |
| 文件型、schema 需靈活演進 | Document（MongoDB） |
| 高度連結的關係資料 | Graph（Neo4j） |
| 非結構化 + 相似度搜尋 | Vector DB |
第二：OLTP 還是 OLAP？
- 業務交易、高並發、需 ACID → OLTP
- 歷史資料分析、聚合查詢 → OLAP（考慮獨立資料倉儲）
第三：規模與一致性取捨？
- 強一致 + 複雜查詢 → RDBMS
- 需輕鬆水平擴展、可接受最終一致 → NoSQL
說出你的理由
| 選擇 | 強調的理由 |
|---|---|
| PostgreSQL | ACID 事務、複雜 JOIN、成熟生態 |
| DynamoDB | 低延遲、大規模水平擴展、managed 降運維 |
| Cassandra | 極高寫入吞吐、多地區部署、寫入不怕單點故障 |
| BigQuery / Redshift | 和 OLTP 分離、column-oriented 讓分析快幾個數量級 |
什麼時候不需要複雜資料庫
避免 over-engineering
- MVP / 小型系統：SQLite 或單一 PostgreSQL 就夠
- 單純快取：Redis / Memcached，不要上 MongoDB
- 單純檔案儲存：圖片/影片/大型文件用 Blob Storage（見 07-Caching-Storage/02-Blob-Storage），不要塞進資料庫
自我測驗重點
| 問題 | 重點 |
|---|---|
| 兩個正交維度 | 資料模型（形狀）× 工作負載（OLTP/OLAP） |
| NoSQL 五類 | KV / Document / Wide-Column / Graph / Vector |
| ACID vs BASE | RDBMS 強一致 vs NoSQL 最終一致換水平擴展 |
| Cassandra 屬於哪類 | OLTP（高寫入），不是分析系統 |
| 選型三問順序 | 形狀/查詢 → OLTP/OLAP → 規模/一致性 |
| 二進位大檔放哪 | Blob Storage，不放 DB |
Related Notes
- 06-Database-Tech/02-PostgreSQL — RDBMS 代表，ACID + 豐富索引
- 06-Database-Tech/03-DynamoDB — KV NoSQL 代表，托管水平擴展
- 06-Database-Tech/04-OLTP-vs-OLAP — 工作負載維度的深入展開
- 08-Search-and-AI/04-Vector-Database — 相似度搜尋專用資料庫
- 05-Database-Advanced/01-Transactions — ACID 與隔離等級
- 02-Distributed-Systems/02-CAP-Theorem — 一致性 vs 可用性取捨
- 07-Caching-Storage/02-Blob-Storage — 二進位資料的歸宿
- 06-Database-Tech/Practice-Database-Tech