資料庫技術練習題 (Practice - Database Tech)

1. 資料模型（Data Model）：資料形狀 —— 表格 / 文件 / Key-Value / 寬欄 / 圖 / 向量
2. 工作負載（Workload）：OLTP（高並發點查詢、小量寫入）還是 OLAP（海量歷史聚合分析）

兩者互相獨立。疊在一起，大多數資料庫的定位就清楚了。

• Key-Value（Redis、DynamoDB）：快取、Session、計數器、排行榜
• Document（MongoDB）：CMS、產品目錄、schema 需靈活演進
• Wide-Column（Cassandra）：高寫入吞吐、時序、明確 access pattern
• Graph（Neo4j）：社交網路、推薦、知識圖譜（多跳查詢比多層 JOIN 快幾個數量級）
• Vector（Pinecone、pgvector）：語意搜尋、RAG、以圖搜圖

共同取捨：多數遵循 BASE（最終一致）而非 ACID，換取水平擴展。

OLTP。Cassandra「write anywhere」用最終一致換超高寫入吞吐 + 無單點故障，但它按 row 儲存，適合高並發寫入與明確 primary key 查詢，不適合跨 row 的聚合分析。把它當分析系統是常見誤解。

不該一上來就背「SQL vs NoSQL」比較表 —— 面試官想看你從需求推導選擇的過程。

依序問三個問題：

1. 資料什麼形狀、什麼查詢模式？（固定結構+JOIN → RDBMS；KV+低延遲 → DynamoDB/Redis；非結構化+相似度 → Vector DB…）
2. OLTP 還是 OLAP？（分析需求 → 獨立資料倉儲）
3. 規模與一致性取捨？（強一致+複雜查詢 → RDBMS；輕鬆水平擴展+可接受最終一致 → NoSQL）

選完一定說出理由（選 PG 強調 ACID/JOIN/生態；選 DynamoDB 強調低延遲/托管擴展）。

• MVP / 小型系統 → SQLite 或單一 PostgreSQL
• 單純快取需求 → Redis / Memcached，不要上 MongoDB
• 單純檔案儲存（圖片、影片、大型文件）→ Blob Storage，不要塞進資料庫

重點是避免 over-engineering。

• GIN 索引（全文搜尋 / tsvector）→ 簡單搜尋不必上 Elasticsearch
• JSONB + GIN（靈活 metadata、半結構化）→ 給類 NoSQL 彈性，不必上 MongoDB
• PostGIS（GIST 索引）（地理空間）→ 不必上專用地理 DB（Uber 早期就用它）

但若需更精細的相關性評分、faceted search、超大規模分散式搜尋，才該真的引入 Elasticsearch。原則：架構越簡單越好。

1. 修改記憶體 buffer（標記髒頁）+ 產生 WAL 記錄（都在記憶體）
2. commit 時 WAL 循序寫進磁碟（fsync）→ 交易即持久化（崩潰可重播 WAL 恢復）
3. 背景寫入程序非同步把髒頁刷進資料檔（可批次）
4. 每個索引更新（→ 太多索引大幅拖慢寫入）

瓶頸通常卡在 WAL 的磁碟 I/O。單節點中等硬體約 5,000 簡單 INSERT/核心/秒。

預設 Read Committed 下，兩交易可能都在對方 commit 前讀到相同最高價 → 較低出價被錯誤接受。兩個解法：

1. Row-Level Locking（首選）：SELECT maxBid FROM Auction WHERE id=123 FOR UPDATE 鎖住該行，其他 FOR UPDATE 必須等
2. 更高隔離等級：SET TRANSACTION ISOLATION LEVEL SERIALIZABLE（防所有異常，但衝突需重試）

面試別只說「我們用交易」，要說「交易加上列層級加鎖」。確切知道鎖哪幾行 → 列鎖；複雜到難預知 → Serializable。

SQL 標準的 Repeatable Read 只防 dirty read + non-repeatable read，仍允許 phantom read。PostgreSQL 的實作更強：在交易開始建一致性快照，同時防 phantom read（即使其他交易提交了符合條件的新行，你也看不到）。

實務意義：很多在別的資料庫需要 Serializable 才能處理的情況，在 PostgreSQL 用 Repeatable Read 就夠，並行度更高、開銷更低。

「單純需要擴展」不是好理由 —— 設計得當的 PG 能撐相當大規模。真正該偏離的情況：

• 極端寫入吞吐（每秒數百萬寫）→ WAL + 索引更新 I/O 瓶頸 → Cassandra / Redis
• 全球多區域多寫（active-active） → PG 單主架構只能一個 Region 主寫 → CockroachDB / Cassandra / DynamoDB Global Tables
• 純 Key-Value 存取 → MVCC/WAL/planner 是殺雞用牛刀 → Redis / DynamoDB

面試心法：從 PG 出發，說明為何偏離，比從小眾方案出發再證明它更好有說服力。

• Partition Key：值被 hash → 決定 item 存哪個物理分區（概念類似 consistent hashing，但用中心化分區 metadata 服務，非 P2P ring）
• Sort Key（選填）：同分區鍵下對 item 排序 → 分區內高效範圍查詢（底層用以 sort key 為索引的 B-tree）

兩層架構 = 水平擴展（hash 分區）+ 分區內高效查詢（B-tree）。選 PK 要均勻分散 + 契合最常見查詢。

記憶點：GSI 靈活（不同 PK、隨時建）但犧牲強一致；LSI 共址、可強一致但建表時就要規劃好。

每次寫入（不管多小）至少 1 WCU（無條件進位到 1KB），每分區約 1,000 寫/秒 → 約需 10,000 個分區。預置定價（~$0.00065/WCU-小時）：10M × $0.00065 × 24 ≈ $15.6 萬/天。

架構考量：定價模型直接帶出架構限制 —— 極高寫入量下 DynamoDB 成本可能爆炸，這正是「成本效益」成為不選 DynamoDB 理由的原因。這種估算能快速判斷方案是否合理。

一致性不是表級設定，而是每個讀取請求指定（ConsistentRead）：

• 最終一致（預設）：任一副本服務，最高可用、最低延遲，0.5 RCU/4KB，表現為 AP/BASE
• 強一致：路由到 leader，反映所有先前寫入，1 RCU/4KB（兩倍），延遲稍高

關鍵限制：強一致讀取不支援 GSI（GSI 只有最終一致），只支援基表與 LSI。設計需強一致的存取模式時必須牢記。另外 DAX 不快取強一致讀取。

三原因疊加：

1. I/O 效率：分析通常只需幾個欄位，column 儲存只讀那幾欄，跳過其他；row 儲存必須讀整行 → I/O 可少 90%+
2. 壓縮：同欄位型別相同、值域相近，壓縮率遠高於混合行（status 字典編碼 → 每值 2 bit）
3. 向量化執行：連續同型別資料可用 CPU SIMD 一條指令同時處理幾十個值

選擇心法：分析師接受看昨天資料 → ETL 幾乎永遠更好；確認有即時需求才引入 CDC。

「行程資料寫入 PostgreSQL（OLTP） 供業務使用。透過 CDC 串流到 BigQuery（OLAP），駕駛收入報表、城市供需分析都在 BigQuery 上跑，與線上業務隔離。」

不該走 OLAP 的：需即時監控的指標（例如目前各城市在線司機數）—— 走獨立的 Redis 計數器，因為 OLAP 有分鐘~小時的資料延遲，撐不起即時監控。

HTAP 適合：資料量不大（幾十 TB 內）、對分析即時性要求高（無 ETL 延遲）、工程團隊資源有限（免維護資料管線）。代表：TiDB（TiKV row + TiFlash column）、SingleStore。

代價：同時維護兩種儲存格式 → 資源開銷高、複雜度上升、很難對 OLTP 和 OLAP 都做到完全最佳化。當資料超過幾百 TB、或兩種負載模式差異很大，分開建置的效能與成本優勢就很明顯 —— 對大多數規模的公司分開更穩健。