NoSQL 非關係型資料庫核心原理與主流產品對比
隨著 Web 2.0、社交網絡、物聯網等高並發、海量數據場景爆發，傳統關係型資料庫 (RDBMS) 在擴展性、寫入性能、Schema 靈活性上遇到瓶頸。NoSQL (Not Only SQL) 應運而生，以犧牲強一致性 (ACID) 換取高可用、高擴展、高性能 (BASE 理論)。
RDBMS 三大痛點
- 高並發讀寫：單機磁盤 IO 無法支撐萬級 QPS/TPS，尤其寫入瓶頸明顯。
- 海量存儲查詢：億級表 JOIN、分頁、聚合極慢，Schema 變更鎖表久。
- 擴展性受限：垂直擴展成本高、有上限；水平分庫分表對業務透明度差、維護複雜。
NoSQL 四大優勢
- 易擴展：去關係化、無結構依賴，天然適合分片與彈性伸縮。
- 高性能：記錄級細粒度 Cache、順序寫入、LSM Tree 等結構優化寫入吞吐。
- 靈活 Schema：無需預定義列，動態新增字段，適應敏捷迭代。
- 高可用架構簡單：多副本、自動故障轉移 (如 Cassandra、HBase、Redis Sentinel/Cluster)。
三大主流類型與代表產品
| 類型 | 核心結構 | 代表產品 | 典型場景 |
|---|
| 鍵值 (KV) | Hash Map / Redis Object | Redis, Memcached, Riak | 緩存、Session、排行榜、計數器、分佈式鎖 |
| 文檔 | BSON/JSON Document | MongoDB, Couchbase | 內容管理、用戶畫像、日誌、目錄、快速迭代業務 |
| 列族/寬表 | LSM Tree + SSTable | HBase, Cassandra, ScyllaDB | 時序數據、監控、推薦特徵、海量寫入少讀取 |
| 圖 | Node + Edge | Neo4j, JanusGraph | 社交關係、反欺詐、知識圖譜、路徑分析 |
經典比喻 (作者原創)
- MySQL = 菜刀：結構簡單、成熟穩定、生態豐富 (分表、讀寫分離、監控)，能完成 90% 廚房工作。
- MongoDB = 瑞士軍刀：功能豐富 (靈活 Schema、Capped Collection、地理索引、異步寫入)，但穩定性與運維經驗仍在積累。
- HBase = 象兵：依託 Hadoop 生態、擴展性極強，但部署維護重 (需養一頭大象)。
- Redis = 金箍棒：結構極簡 (KV)、單線程高性能、伸縮自如，適合熱點數據加速。
文檔庫建模難點 (以 MongoDB 為例)
- 無 JOIN，需按「應用訪問模式」設計嵌套或引用，Schema 設計比關係模型更難。
- 事務支援弱 (早期單文檔原子，4.0+ 多文檔事務但性能代價大)。
- 不適合複雜 OLAP 分析，需配合數據倉庫。
NoSQL 選型決策樹
- 數據是否有強事務/關聯分析需求？ → 是 → 留在 MySQL/PostgreSQL。
- 訪問模式是否固定、高並發 KV？ → Redis。
- 半結構化、變化快、需豐富查詢？ → MongoDB。
- 海量寫入、時序、掃描聚合？ → HBase/Cassandra。
- 關係圖譜、多跳查詢？ → Neo4j。
NoSQL 不是銀彈，而是工具箱新增的利器。架構演進常見路徑：MySQL → MySQL + Redis 緩存 → 讀寫分離 → 分庫分表 → 引入 MongoDB/HBase 解決特定業務痛點 → 微服務化按業務拆分存儲。
