数据库全景学习路线 / A Complete Database Learning Path
📅 创建时间：2026-05-08 🏷️ 标签：#Database #学习路线 #入门指南 #选型 📚 前置知识：无（了解 SQL 基本概念更佳） 📚 相关知识：[[08-vector-database]] [[05-redis]]
文档目标
本文档为数据库全景学习提供系统性的知识地图。通过本路线学习，你将：
- 理解各类型数据库的设计哲学与适用场景
- 掌握从 MySQL 到向量数据库的选型决策能力
- 建立"不同数据用不同数据库"的工程直觉
- 为 LLM/Agent 应用中的数据存储需求找到最佳方案
数据库分类图谱
┌─────────────────────────────────────────────────────────────────────────────┐
│ 数据库分类全景图 │
└─────────────────────────────────────────────────────────────────────────────┘
第一层：按数据模型分类
┌─────────────┐ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐
│ 关系型 │ │ 文档型 │ │ KV 键值 │ │ 列式存储 │
│ Relational │ │ Document │ │ Key-Value │ │ Columnar │
└──────┬──────┘ └──────┬──────┘ └──────┬──────┘ └──────┬──────┘
│ │ │ │
↓ ↓ ↓ ↓
MySQL, MongoDB, Redis, ClickHouse,
PostgreSQL, CouchDB etcd, StarRocks,
SQLite RocksDB DuckDB
┌─────────────┐ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐
│ 向量数据库 │ │ 时序数据库 │ │ 图数据库 │ │ NewSQL │
│ Vector DB │ │ Time-Series │ │ Graph │ │ NewSQL │
└─────────────┘ └─────────────┘ └─────────────┘ └─────────────┘
│ │ │ │
↓ ↓ ↓ ↓
Milvus, TimescaleDB, Neo4j, TiDB,
Qdrant, InfluxDB, TigerGraph, CockroachDB,
pgvector TDengine Gremlin OceanBase
第二层：按部署形态分类
┌─────────────┐ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐
│ 服务器型 │ │ 嵌入式 │ │ 云原生 │ │ 分布式 │
│ Server │ │ Embedded │ │ Cloud-Native│ │ Distributed │
└─────────────┘ └─────────────┘ └─────────────┘ └─────────────┘
│ │ │ │
↓ ↓ ↓ ↓
MySQL, SQLite, PlanetScale, TiDB,
PostgreSQL, RocksDB, Neon, CockroachDB,
MongoDB PGlite Supabase OceanBase学习路径总览
┌─────────────────────────────────────────────────────────────────────────────┐
│ 数据库全景学习路线 │
└─────────────────────────────────────────────────────────────────────────────┘
第1阶段：关系型基础（最重要）
┌───────────────────┐ ┌───────────────────┐ ┌───────────────────┐
│ MySQL 实战 │ → │ PostgreSQL 深度 │ → │ SQLite 嵌入式 │
│ 01-mysql │ │ 02-postgresql │ │ 03-sqlite │
└───────────────────┘ └───────────────────┘ └───────────────────┘
第2阶段：NoSQL 家族
┌───────────────────┐ ┌───────────────────┐
│ MongoDB 文档型 │ → │ Redis 全方位 │
│ 04-mongodb │ │ 05-redis │
└───────────────────┘ └─────────┬─────────┘
│
第3阶段：基础设施层 ┌───▼───────────────────┐
┌───────────────────┐ │ 嵌入式 KV 数据库 │
│ 嵌入式 KV │───────────│ 06-kv-embedded │
│ 06-kv-embedded │ └───────────────────────┘
└───────────────────┘
第4阶段：分布式与云原生
┌───────────────────┐ ┌───────────────────┐
│ NewSQL 分布式 │ → │ OLAP 列式分析 │
│ 07-distributed │ │ 09-olap │
└───────────────────┘ └───────────────────┘
第5阶段：AI 时代新物种
┌───────────────────┐ ┌───────────────────┐ ┌───────────────────┐
│ 向量数据库 │ → │ 时序数据库 │ → │ 数据库选型指南 │
│ 08-vector-db │ │ 10-time-series │ │ 11-db-selection │
└───────────────────┘ └───────────────────┘ └───────────────────┘核心概念：CAP 定理与不可能三角
┌─────────────────────────────────────────────────────────────┐
│ CAP 不可能三角 │
├─────────────────────────────────────────────────────────────┤
│ │
│ Consistency (一致性) │
│ ▲ │
│ /│\ │
│ / │ \ │
│ / │ \ │
│ / │ \ │
│ / │ \ │
│ / │ \ │
│ ▼──────┼──────▼ │
│ Availability ◄────┴─────► Partition Tolerance │
│ （可用性） （分区容错） │
│ │
│ 任何分布式系统最多只能同时满足其中两个特性。 │
│ │
│ CA（放弃分区容错）：传统单机 RDBMS │
│ → MySQL、PostgreSQL、SQLite │
│ │
│ CP（放弃可用性）：分布式 KV、NewSQL │
│ → etcd、Zookeeper、CockroachDB（强一致模式） │
│ │
│ AP（放弃一致性）：最终一致系统 │
│ → Cassandra、DynamoDB、MongoDB（副本集默认模式） │
│ │
└─────────────────────────────────────────────────────────────┘常见的误解：很多人以为 CAP 意味着"三选二"。实际上，在正常运行（无分区）时，系统可以同时提供 C 和 A。只有发生网络分区时，才被迫在 C 和 A 之间选择。
SQL vs NoSQL vs NewSQL 核心区别
┌─────────────────────────────────────────────────────────────┐
│ 三类数据库核心对比 │
├─────────────────────────────────────────────────────────────┤
│ │
│ │ 维度 │ SQL (RDBMS) │ NoSQL │ NewSQL │
│ ├──────────────┼───────────────┼────────────────┼─────────┤
│ │ 数据模型 │ 严格的表/行 │ 灵活文档/KV/列 │ 表结构 │
│ │ Schema │ 强 Schema │ Schema-less │ 强 Schema│
│ │ 事务 │ ACID 完整支持 │ 有限或无 │ ACID │
│ │ 查询语言 │ SQL │ 各有 API │ SQL │
│ │ 扩展方式 │ 垂直扩展为主 │ 水平扩展容易 │ 水平扩展│
│ │ 一致性 │ 强一致 │ 最终一致居多 │ 强一致 │
│ │ 典型代表 │ MySQL/PG │ Mongo/Redis │ TiDB │
│ │ 适用场景 │ 核心业务数据 │ 灵活结构/缓存 │ 大规模OLTP│
│ │
└─────────────────────────────────────────────────────────────┘为什么一个项目往往需要多个数据库
┌─────────────────────────────────────────────────────────────┐
│ 典型互联网项目的数据层架构 │
├─────────────────────────────────────────────────────────────┤
│ │
│ 用户请求 │
│ ↓ │
│ ┌─────────────────┐ │
│ │ PostgreSQL │ ← 核心业务数据（订单、用户、账户） │
│ │ (OLTP) │ 强一致、事务支持 │
│ └─────────────────┘ │
│ ↓ │
│ ┌─────────────────┐ ┌─────────────────┐ │
│ │ Redis │ │ ClickHouse │ │
│ │ (缓存层) │ │ (OLAP) │ │
│ │ Session/热点数据 │ │ 用户行为分析 │ │
│ └─────────────────┘ │ 日志聚合查询 │ │
│ ↓ └─────────────────┘ │
│ ┌─────────────────┐ │
│ │ pgvector/Milvus│ ← AI 向量检索（相似商品、语义搜索） │
│ │ (向量数据库) │ │
│ └─────────────────┘ │
│ │
│ 结论：没有"万能数据库"，只有"最适合特定数据的数据库" │
│ │
└─────────────────────────────────────────────────────────────┘各章节快速预览
第1阶段：关系型基础
| 章节 | 数据库 | 核心定位 | 典型场景 |
|---|---|---|---|
| [[01-mysql]] | MySQL | 互联网标配 | Web 应用、Laravel、WordPress |
| [[02-postgresql]] | PostgreSQL | 功能最全 | 复杂查询、GIS、AI 向量、全文本 |
| [[03-sqlite]] | SQLite | 嵌入式零配置 | 移动端、桌面、浏览器、测试 |
第2阶段：NoSQL 家族
| 章节 | 数据库 | 核心定位 | 典型场景 |
|---|---|---|---|
| [[04-mongodb]] | MongoDB | 灵活文档 | 内容管理、UGC、快速迭代 |
| [[05-redis]] | Redis | 全能 KV | 缓存、Session、锁、队列、排行榜 |
第3阶段：基础设施层
| 章节 | 数据库 | 核心定位 | 典型场景 |
|---|---|---|---|
| [[06-kv-embedded]] | etcd/RocksDB | 嵌入式 KV | K8s 配置、元数据、存储引擎 |
第4阶段：分布式与云原生
| 章节 | 数据库 | 核心定位 | 典型场景 |
|---|---|---|---|
| [[07-distributed-sql]] | TiDB/CockroachDB | NewSQL | 规模化 OLTP、金融级可靠 |
| [[09-olap-databases]] | ClickHouse/DuckDB | OLAP 列式 | 数据分析、实时报表 |
第5阶段：AI 时代新物种
| 章节 | 数据库 | 核心定位 | 典型场景 |
|---|---|---|---|
| [[08-vector-database]] | Milvus/pgvector | 向量检索 | RAG、语义搜索、推荐系统 |
| [[10-time-series]] | TimescaleDB/InfluxDB | 时序数据 | 监控指标、IoT、传感器 |
| [[11-db-selection]] | 选型指南 | 决策框架 | 项目数据库选型 |
常见误解澄清
误解1：MySQL 比 PostgreSQL 更快
事实：在简单查询下 MySQL 可能略快，但在复杂查询（窗口函数、CTE、JSONB）、地理空间、全文本搜索等场景下，PostgreSQL 往往更快且功能更完整。
误解2：NoSQL 就不需要 Schema
事实：NoSQL 的"无 Schema"不是"无结构"，而是"写入时定义结构"。灵活意味着数据质量需要靠应用层保证，这反而增加了复杂度。
误解3：分布式数据库就一定比单机好
事实：分布式带来了强一致性，但也带来了延迟（跨节点事务）、运维复杂度（数据均衡）和成本（至少3节点）。对中小规模应用，单机 PostgreSQL 往往是最优解。
误解4：向量数据库会替代传统数据库
事实：向量数据库解决的是"语义相似度检索"这一特定问题。结构化查询、事务、强一致性仍需要传统数据库。它们是互补关系，不是替代关系。
学习状态：🟡 开始学习