数据库选型决策指南——从理论到实践 / A Practical Guide to Database Selection
📅 创建时间：2026-05-08 🏷️ 标签：#数据库选型 #决策框架 #架构设计 #实战案例 📚 前置知识：[[00-db-overview]]（所有数据库分类基础） 📚 相关知识：[[05-redis]] [[08-vector-database]] [[09-olap-databases]]
第1部分：决策矩阵
┌─────────────────────────────────────────────────────────────┐
│ 数据库选型决策矩阵 │
├─────────────────────────────────────────────────────────────┤
│ │
│ 第一维度：数据结构 │
│ │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ 结构化表（强 Schema）→ 关系型 │ │
│ │ ├─ 强事务需求 → MySQL / PostgreSQL │ │
│ │ ├─ 需要水平扩展 → TiDB / CockroachDB │ │
│ │ └─ 地理空间数据 → PostgreSQL + PostGIS │ │
│ │ │ │
│ │ 半结构化（JSON/文档）→ 文档型 │ │
│ │ ├─ 需要事务 → PostgreSQL JSONB │ │
│ │ ├─ Schema 频繁变化 → MongoDB │ │
│ │ └─ 需要向量检索 → pgvector │ │
│ │ │ │
│ │ 无结构/灵活 → KV / 文档型 │ │
│ │ ├─ 需要丰富数据结构 → Redis │ │
│ │ └─ 需要持久化 → MongoDB / etcd │ │
│ │ │ │
│ │ 向量数据 → 向量数据库 │ │
│ │ ├─ <100 万向量 → pgvector │ │
│ │ ├─ 100 万-1 亿向量 → Milvus / Qdrant │ │
│ │ └─ >1 亿向量 → Milvus + DiskANN │ │
│ │ │ │
│ │ 时序数据 → 时序数据库 │ │
│ │ ├─ 已有 PostgreSQL → TimescaleDB │ │
│ │ ├─ 需要采集生态 → InfluxDB │ │
│ │ └─ 超大规模 IoT → TDengine │ │
│ │ │ │
│ │ 分析型数据 → OLAP 列式 │ │
│ │ ├─ 嵌入式/小规模 → DuckDB │ │
│ │ └─ 生产级大规模 → ClickHouse / StarRocks │ │
│ └─────────────────────────────────────────────────────┘ │
│ │
│ 第二维度：一致性需求 │
│ │
│ 强一致（ACID） → PostgreSQL / MySQL / TiDB / CockroachDB│
│ 最终一致 → MongoDB / Cassandra / etcd │
│ 无一致性要求 → Redis / Memcached / SQLite │
│ │
│ 第三维度：数据规模 │
│ │
│ 单机可承载 → MySQL / PostgreSQL / SQLite │
│ 垂直扩展瓶颈 → TiDB / CockroachDB / OceanBase │
│ PB 级分析 → ClickHouse / StarRocks │
│ │
└─────────────────────────────────────────────────────────────┘第2部分：常见场景选型
场景1：电商系统
┌─────────────────────────────────────────────────────────────┐
│ 电商系统数据库选型 │
├─────────────────────────────────────────────────────────────┤
│ │
│ 订单/商品/用户（核心交易数据） │
│ → PostgreSQL / TiDB │
│ 理由：强事务、多表 JOIN、复杂查询（库存扣减、促销计算） │
│ │
│ 缓存（商品信息、会话、热点数据） │
│ → Redis Cluster │
│ 理由：高频读取、高并发、低延迟 │
│ │
│ 商品搜索（全文 + 过滤 + 排序） │
│ → Elasticsearch / OpenSearch │
│ 理由：倒排索引、多条件过滤、分面搜索 │
│ │
│ 商品向量检索（相似商品推荐） │
│ → pgvector / Milvus │
│ 理由：embedding 向量相似度搜索 │
│ │
│ 用户行为日志（点击、浏览、购买漏斗） │
│ → ClickHouse │
│ 理由：海量日志分析、用户行为漏斗、实时 BI │
│ │
│ 搜索推荐系统（Elasticsearch + 向量） │
│ → Elasticsearch + kNN Plugin / Milvus │
│ │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ 常见误区： │ │
│ │ ❌ 所有数据放 MongoDB（事务和 JOIN 是问题） │ │
│ │ ❌ 所有数据放 MySQL（分析查询拖垮 OLTP） │ │
│ │ ✅ 核心交易用 PostgreSQL，读多写多用 Redis 缓存 │ │
│ │ ✅ 分析用 ClickHouse，分析和 OLTP 物理分离 │ │
│ └─────────────────────────────────────────────────────┘ │
│ │
└─────────────────────────────────────────────────────────────┘场景2：社交/内容平台
┌─────────────────────────────────────────────────────────────┐
│ 社交/内容平台数据库选型 │
├─────────────────────────────────────────────────────────────┤
│ │
│ 用户/认证/配置（核心用户数据） │
│ → PostgreSQL / CockroachDB │
│ 理由：强一致、多表关联、复杂权限查询 │
│ │
│ 帖子/评论/动态（灵活字段、频繁变化） │
│ → PostgreSQL JSONB / MongoDB │
│ 理由：不同类型帖子字段差异大，JSONB 兼得灵活和强查询 │
│ │
│ Feed 流（最新动态、时间排序） │
│ → Redis List / Sorted Set │
│ 理由：超高速写入、低延迟读取、按时间排序 │
│ │
│ 好友关系/图数据 │
│ → Neo4j / PostgreSQL + 邻接表 │
│ 理由：好友推荐（二度人脉查询）、图算法 │
│ │
│ 实时消息（聊天） │
│ → Redis Stream + MongoDB / PostgreSQL │
│ 理由：Redis 处理实时消息流，持久化用 PG/MongoDB │
│ │
│ 内容推荐（语义相似） │
│ → Milvus / pgvector │
│ 理由：基于内容的 embedding 推荐 │
│ │
└─────────────────────────────────────────────────────────────┘场景3：LLM / Agent 应用
┌─────────────────────────────────────────────────────────────┐
│ LLM / Agent 应用数据库选型 │
├─────────────────────────────────────────────────────────────┤
│ │
│ 这是 DataBase 系列文档与 Agent 系列文档的交汇点： │
│ │
│ Agent 配置 / 会话元数据 │
│ → PostgreSQL │
│ 理由：Agent 定义（JSONB 灵活配置）、会话持久化、强一致 │
│ 参考：LobeChat 的设计 │
│ │
│ 消息历史（JSONB 消息体） │
│ → PostgreSQL + 分区表（按月分区） │
│ 理由：消息结构统一但数据量大，按月分区便于清理和分析 │
│ 参考：LobeChat messages 表设计 │
│ │
│ RAG 向量检索 │
│ → pgvector（<100万向量） │
│ → Milvus / Qdrant（>100万向量） │
│ 理由：[[08-vector-database]] 中的选型树 │
│ 参考：[[03-rag-basics]] Agent 文档 │
│ │
│ 用户记忆（六维向量系统） │
│ → PostgreSQL + pgvector + JSONB │
│ 理由：用户记忆六维（活动/上下文/经历/身份/偏好/人格） │
│ 参考：LobeChat user_memories_* 表设计 │
│ │
│ Session 缓存 / 流式输出缓冲 │
│ → Redis │
│ 理由：[[05-redis]] 中的语义缓存、流式结果多端同步 │
│ │
│ API 限流 / 分布式锁 │
│ → Redis │
│ 理由：[[05-redis]] 中 Redisson 的限流器和锁 │
│ │
│ 文件元数据 │
│ → PostgreSQL │
│ 理由：文件本体存 S3，元数据（名称/类型/大小）存 PG │
│ │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ LLM/Agent 应用的典型数据库栈： │ │
│ │ │ │
│ │ PostgreSQL + pgvector ←── 主数据库（90% 的数据） │ │
│ │ ├─ 消息（JSONB，分区表） │ │
│ │ ├─ RAG chunks + embeddings │ │
│ │ ├─ Agent 配置（JSONB） │ │
│ │ └─ 用户记忆（六维向量） │ │
│ │ │ │
│ │ Redis ←── 缓存层（10% 的热数据） │ │
│ │ ├─ Session 缓存 │ │
│ │ ├─ LLM 语义缓存（LangCache） │ │
│ │ ├─ Token 限流 │ │
│ │ └─ 流式结果缓冲（Stream） │ │
│ │ │ │
│ │ S3/MinIO ←── 文件存储（本体） │ │
│ └─────────────────────────────────────────────────────┘ │
│ │
└─────────────────────────────────────────────────────────────┘第3部分：决策流程图
┌─────────────────────────────────────────────────────────────┐
│ 数据库选型决策流程 │
├─────────────────────────────────────────────────────────────┤
│ │
│ START: 我需要存什么数据？ │
│ │
│ ┌────────────────┐ │
│ │ 是否需要事务？ │ │
│ └───┬──────────┬─┘ │
│ 否 │ │ 是 │
│ ▼ ▼ │
│ ┌────────┐ ┌────────────────────┐ │
│ │ Redis │ │ 需要水平扩展吗？ │ │
│ │ (缓存) │ └───┬──────────┬───┘ │
│ └────────┘ 否 │ │ 是 │
│ ▼ ▼ │
│ ┌────────┐ ┌────────────────┐ │
│ │ PostgreSQL │ │ SQL 还是 NoSQL？ │ │
│ │ /MySQL │ └───┬──────┬─────┘ │
│ └────────┘ SQL │ │ NoSQL │
│ ▼ ▼ │
│ ┌─────────┐ ┌──────────┐ │
│ │ TiDB / │ │ MongoDB / │ │
│ │Cockroach │ │ Cassandra │ │
│ └─────────┘ └──────────┘ │
│ │
│ 特殊需求： │
│ ├─ 需要向量检索？ → pgvector / Milvus │
│ ├─ 需要全文搜索？ → PostgreSQL FTS / Elasticsearch │
│ ├─ 需要时序分析？ → TimescaleDB / ClickHouse │
│ ├─ 需要地理空间？ → PostgreSQL + PostGIS │
│ ├─ 需要图数据？ → Neo4j / PostgreSQL + 邻接表 │
│ └─ 需要嵌入/单机？ → SQLite / DuckDB │
│ │
└─────────────────────────────────────────────────────────────┘第4部分：多数据库组合策略
┌─────────────────────────────────────────────────────────────┐
│ 多数据库组合使用策略 │
├─────────────────────────────────────────────────────────────┤
│ │
│ 组合原则： │
│ 1. 每个数据库做自己最擅长的事 │
│ 2. 避免过度工程：99% 的项目用 PostgreSQL + Redis 就够了 │
│ 3. 先验证瓶颈，再引入新数据库 │
│ │
│ 组合模式A：经典互联网架构（最常见） │
│ │
│ ┌───────────────┐ │
│ │ PostgreSQL │ ←─ 核心业务数据 │
│ │ (TiDB 可替换) │ ←─ 强事务 │
│ └───────┬───────┘ │
│ │ │
│ ┌───────▼───────┐ │
│ │ Redis │ ←─ 缓存层 │
│ │ (Cluster) │ ←─ Session / 热点数据 / 限流 │
│ └───────────────┘ │
│ │
│ 组合模式B：数据分析型 │
│ │
│ ┌───────────────┐ │
│ │ PostgreSQL │ ←─ OLTP（事务） │
│ └───────┬───────┘ │
│ │ ETL/CDC │
│ ▼ │
│ ┌───────────────┐ │
│ │ ClickHouse │ ←─ OLAP（分析） │
│ │ /StarRocks │ ←─ 实时报表 / 漏斗分析 │
│ └───────────────┘ │
│ │
│ 组合模式C：AI 应用型（LobeChat 方案） │
│ │
│ ┌───────────────────────────────────────────┐ │
│ │ PostgreSQL + PGVector │ │
│ │ ├─ 消息（JSONB，分区） │ │
│ │ ├─ RAG chunks + embeddings │ │
│ │ ├─ 用户记忆（向量 + JSONB） │ │
│ │ └─ Agent / 会话元数据 │ │
│ └───────────────────────┬───────────────────┘ │
│ │ │
│ ┌───────────────────────▼───────────────────┐ │
│ │ Redis │ │
│ │ ├─ Session 缓存 │ │
│ │ ├─ LLM 语义缓存（节省 API 费用） │ │
│ │ ├─ Token 速率限制 │ │
│ │ └─ 流式结果缓冲（Stream） │ │
│ └───────────────────────────────────────────┘ │
│ │
│ 避免的组合： │
│ ❌ MySQL + MongoDB + Redis + PostgreSQL + ClickHouse │
│ → 每加一个数据库，就多一套运维复杂度 │
│ → 团队能维护好的数据库通常不超过 3 种 │
│ │
│ ✅ 优先用 PostgreSQL 的扩展能力（JSONB/向量/全文/地理） │
│ → 一个数据库能搞定的事，不要引入两个 │
│ │
└─────────────────────────────────────────────────────────────┘第5部分：未来趋势
┌─────────────────────────────────────────────────────────────┐
│ 数据库未来趋势（2026） │
├─────────────────────────────────────────────────────────────┤
│ │
│ 1. HTAP（混合事务/分析处理） │
│ • 单数据库同时处理 OLTP + OLAP │
│ • TiDB + TiFlash、SingleStore、Databricks SQL │
│ → 趋势：减少数据复制，一份数据多用途 │
│ │
│ 2. Serverless 数据库 │
│ • Neon（Serverless PostgreSQL，按需扩缩容） │
│ • PlanetScale（MySQL，Serverless 分支） │
│ • Turso（SQLite，Serverless 全球分布） │
│ → 趋势：不用管理服务器，按查询计费 │
│ │
│ 3. AI 原生数据库 │
│ • Vectra、Weaviate、Chroma（纯向量 DB） │
│ • pgvector 生态快速发展 │
│ → 趋势：向量能力将成为所有数据库的标配 │
│ │
│ 4. 边缘数据库 │
│ • Cloudflare D1（Edge SQLite） │
│ • Turso（全球复制的 SQLite） │
│ • PlanetScale（全球分布的 MySQL） │
│ → 趋势：数据离用户更近，延迟更低 │
│ │
│ 5. 统一查询层 │
│ • Presto / Trino（跨数据源统一 SQL 查询） │
│ • Apache Calcite（查询引擎框架） │
│ → 趋势：不用迁移数据，用统一 SQL 查询异构数据源 │
│ │
└─────────────────────────────────────────────────────────────┘学习状态：🟢 已完成 DataBase 系列