为什么要对数据库进行细分：从 RDBMS 到 12 类专用数据库的全景图

本文是「PostgreSQL 系列」的视角篇 · 三。配套源码版本：PostgreSQL 18 dev（~/cwork/postgresql）。同系列前文：

• 当我们在说”数据库”的时候，我们到底在说什么 —— 从用户的视角拆解 PostgreSQL 的能力与接口
• 选数据库的时候，我们究竟在选什么 —— 当基础能力都满足时，哪些维度让数据库”脱颖而出”

上一篇我们说：所有数据库都能给”基础能力”——CRUD、事务、索引、复制。那为什么我们还需要时序数据库、图数据库、文档数据库、向量数据库这一大堆”专用数据库”？

答案藏在一个朴素的观察里：

所有数据库都”能做”基础能力，但不是所有数据库都”做得好”特定场景。

本文系统梳理当下 12 类数据库全景图：每一类为什么存在、典型代表是谁、什么场景该选、什么场景不该选。看完全文，你会有一张完整的”数据库地图”——未来遇到任何业务场景，都能在这张图上快速定位。

一、先想清楚：为什么数据库要细分

1.1 “一个数据库搞定一切”的失败史

1990 年代，对象关系型数据库（Object-Relational DB）曾经是”主流”——把面向对象和关系模型合二为一。但全部失败了（Oracle Objects、IBM DB2 UDB、Informix Universal Server…）。原因是：

• 对象模型 + 关系模型两套范式互相干扰
• 性能比纯 RDBMS 差，比纯 OODB 也差
• 用户不会同时写两套

教训：所有”统一一切”的尝试都失败了。真正成功的是专用化：每个数据库把一类问题做到极致。

1.2 细分的 3 个根本原因

原因 1：业务多样化

每个业务有自己的”灵魂数据结构”：

原因 2：数据模型多样化

关系模型不是唯一真理——它只是被关系代数（Edgar Codd, 1970）建立得很好的一种模型。但其他模型在特定场景下更自然：

原因 3：物理模型与访问模式多样化

反例：PG 用 BTree 索引 + Heap 文件 + 行存 = OLTP 通杀。但拿这个组合去跑 OLAP / 时序 / 向量检索，都不是最优——所以出现专用数据库。

二、12 类数据库全景图

数据库类型到底有多少种？按数据模型 + 物理模型划分，目前有 12 大类：

下面逐类详解——为什么存在、典型代表、什么场景该选。

三、RDBMS：关系型数据库 —— 一切的基础

3.1 为什么存在

1970 年 Edgar Codd 提出关系模型，奠定了 SQL/ACID/事务三大基石。**这是数据库的”母语”**——所有其他数据库在某种程度上都在和 RDBMS 兼容或竞争。

3.2 典型代表

3.3 核心能力

3.4 何时该选

• 强事务需求：订单、库存、金融
• 复杂业务逻辑：多表关联、嵌套查询
• 强数据一致性：不能容忍脏读 / 幻读
• 标准 SQL 兼容：BI 工具、ORM 友好

3.5 何时不该选

• TB 级分析扫描（选列存）
• 图遍历（选图数据库）
• 时序高频写入（选 TSDB）
• 灵活 schema（选文档数据库）

四、TSDB：时序数据库 —— 设备监控与指标的世界

4.1 为什么存在

时序数据有独特的特征：

• 每条数据都有时间戳
• 写入是追加为主，很少更新
• 查询通常是”某段时间范围内某指标”
• 数据冷热分明：最新数据查询多，老数据几乎不查
• 数据量极大：单设备 1 Hz 采样 = 31M 行 / 年

RDBMS 应对这些特征非常糟糕：

• BTree 索引膨胀（每条数据一个索引项）
• 写入吞吐受限
• 旧数据清理靠 DELETE，锁表 + 碎片

TSDB 的针对性优化：

4.2 典型代表

4.3 TimescaleDB 与 InfluxDB 的对比

选择规则：

• 团队熟 PG、需要 JOIN → TimescaleDB
• 数据量极大、纯时序 → InfluxDB / TDengine
• K8s 监控 → Prometheus

4.4 何时该选

• 设备 / 服务器监控
• 金融行情、K 线
• IoT 传感器数据
• 应用指标（APM）

4.5 何时不该选

• 数据之间强关联（应该用 RDBMS）
• 业务事务复杂（应该用 RDBMS）
• 数据非时间序列（用错了）

五、Graph：图数据库 —— 关系的世界

5.1 为什么存在

图数据无处不在：

6 度分隔理论：地球上任何两个人，最多通过 6 个人就能联系上。这种关系链查询用 RDBMS 是噩梦：

-- "你好友的好友关注的人" 在 PG 里要 5-6 层 JOIN
WITH RECURSIVE ...

每跳一次都是 N² 数据量。社交网络几跳就崩。

图数据库的核心：遍历（traversal）操作复杂度只跟邻居数相关，不跟全图规模相关。

5.2 典型代表

5.3 图数据库的两大模型

属性图更适合 90% 业务图场景。RDF 更适合知识图谱、语义搜索。

5.4 何时该选

• 社交网络、好友推荐
• 知识图谱、实体关系
• 欺诈检测（识别循环转账）
• 供应链关系
• 网络安全（攻击路径分析）

5.5 何时不该选

• 简单 CRUD（用 RDBMS）
• 数据是表格形状（用 RDBMS）
• 主要是聚合统计（用 OLAP）

六、Document：文档数据库 —— 灵活 schema 的世界

6.1 为什么存在

业务需求变化快，schema 经常改：

{
  "user_id": 12345,
  "name": "Alice",
  "email": "alice@example.com",
  "preferences": {
    "theme": "dark",
    "language": "zh-CN",
    "notifications": {
      "email": true,
      "sms": false,
      "push": true
    }
  },
  "tags": ["vip", "early-adopter"],
  "login_history": [
    {"ip": "1.2.3.4", "ts": "2026-08-15T10:30:00Z"},
    {"ip": "5.6.7.8", "ts": "2026-08-16T14:20:00Z"}
  ]
}

这种嵌套、半结构化数据用 RDBMS 要么塞 JSON 字段（查询难）、要么拆 5 张表（应用代码复杂）。

文档数据库就是为这种数据而生——一个 JSON 文档就是一行。

6.2 典型代表

6.3 文档数据库的两大误区

6.4 何时该选

• 半结构化数据（用户资料、产品目录、内容管理）
• schema 经常变化（创业初期）
• 文档级事务够用（不需要跨文档）
• 团队熟悉 JSON / JS

6.5 何时不该选

• 强事务、跨文档（订单、金融）→ RDBMS
• 复杂聚合（BI 报表）→ OLAP
• 图关系 → 图数据库

七、KV：键值数据库 —— 极简的极致

7.1 为什么存在

键值（Key-Value）是最简单、最快的数据模型：

复杂度只有 3 个操作：GET / SET / DEL。其他都是花活。

7.2 典型代表

7.3 Redis 的数据结构不只是 KV

**Redis 是”KV 外壳，多结构内核”**——表面是 KV，实质是多结构内存数据库。

7.4 何时该选

• 缓存（任何 RDBMS 都该有一个 Redis 配合）
• 会话存储（session）
• 消息队列（list / stream）
• 限流 / 计数器（INCR）
• 分布式锁（SET NX）
• 配置中心（etcd）

7.5 何时不该选

• 需要事务 → RDBMS
• 需要范围查询（KV 不擅长）→ RDBMS / 时序
• 需要持久化（Redis 是内存的）→ RDBMS（虽然 Redis 也支持 RDB / AOF）

八、Column：列存数据库 —— 扫描的极致

8.1 为什么存在

RDBMS 用行存（Row Store）：每行的所有列存在一起。适合 OLTP（取整行）。

但 OLAP 经常只关心少数几列——“过去 7 天所有订单的金额总和” 只关心 amount 一列。

真实性能差异：扫描 1 亿行 10 列但只读 1 列，列存比行存快 100-1000 倍。

8.2 典型代表

8.3 列存的 4 个核心优化

8.4 何时该选

• 日志分析（Kafka → ClickHouse）
• 用户行为分析
• 报表 BI
• 实时大屏（分钟级数据更新）
• 数据科学本地分析（DuckDB）

8.5 何时不该选

• 点查 / 单行 UPDATE → RDBMS
• 强事务 → RDBMS
• 小数据量（GB 级） → RDBMS 完全够

九、Search Engine：搜索引擎 —— 全文检索的极致

9.1 为什么存在

全文搜索有独特的需求：

RDBMS 全文搜索很弱（MySQL FULLTEXT、PG to_tsvector），搜索引擎专为这些场景设计。

9.2 典型代表

9.3 ES 为什么会成为”日志分析”的事实标准

ELK / EFK 栈（Elasticsearch + Logstash/Filebeat + Kibana）几乎是云原生日志的事实标准——因为：

• ES 写入快（近实时索引）
• 全文搜索 + 聚合查询都强
• Kibana 可视化开箱即用

9.4 何时该选

• 应用内搜索（电商、内容）
• 日志聚合分析
• 监控系统（Prometheus + ES）
• 任何需要全文检索 + 模糊搜索

9.5 何时不该选

• 结构化数据 + 强事务 → RDBMS
• TB 级离线分析 → 列存 OLAP
• 极简场景（搜几百条记录）→ PG 全文检索够用

十、Vector：向量数据库 —— AI 时代的入场券

10.1 为什么存在

AI / 大模型时代的特征：

• 文本 / 图片 / 视频都被编码成高维向量（512 / 1024 / 1536 维）
• 查询不是”精确匹配”，而是”找最相似的 K 个“（KNN）

RDBMS 不能做 KNN：100 万向量两两算距离 = 10^12 次浮点运算，CPU 跑几年。

向量数据库的解法：HNSW（Hierarchical Navigable Small World）图索引，把搜索从 O(N) 降到 O(log N)。

10.2 典型代表

10.3 pgvector 与 Milvus 的对比

选择规则：

• 数据规模 < 1000 万向量 → pgvector（与 PG 一起用，省事）
• 数据规模 > 1 亿向量 → Milvus / Qdrant
• 想 SaaS → Pinecone

10.4 何时该选

• RAG（检索增强生成）
• 图像检索
• 推荐系统
• 语义搜索
• 重复图片检测

10.5 何时不该选

• 传统精确查询（按 ID / 状态）→ RDBMS
• 全表扫描 → 列存 OLAP
• 数据规模太小（几千条） → 直接遍历

十一、Embedded：嵌入式数据库 —— 装进 App 的数据库

11.1 为什么存在

**不是每个应用都需要”数据库服务器”**：

11.2 典型代表

11.3 SQLite 的”统治力”

SQLite 是部署量最大的数据库——超过所有其他数据库之和：

• Android / iOS 系统自带
• 浏览器、操作系统内置
• 几乎所有桌面 App
• 单文件零配置，10 MB 内存就能跑

11.4 何时该选

• 移动 App（必选 SQLite）
• 桌面应用、本地工具
• 嵌入式设备
• 单文件数据分析（DuckDB）
• 测试环境替代真 PG

11.5 何时不该选

• 多客户端（嵌入式 = 单进程）→ 真正的服务器 DB
• 高并发写（SQLite 写是串行）→ RDBMS
• TB 级数据 → 服务器 DB

十二、Multi-model：多模数据库 —— 一个 DB 多接口

12.1 为什么存在

现实业务往往有多种数据：

多模数据库想”一个 DB 处理所有”——文档 + 图 + KV + 关系。

12.2 典型代表

12.3 多模的”诱惑 vs 现实”

12.4 何时该选

• 业务数据真的多模（且不想维护多套 DB）
• 用 Azure / Fauna 等托管服务（运维省心）
• 中等规模（性能要求不极致）

12.5 何时不该选

• 单一数据模型为主（用专用 DB）
• 极致性能（专用 DB 永远更快）
• 想避免厂商锁定（开源 PG + 专用 DB 更好）

十三、GIS：地理信息数据库 —— 地图与位置的世界

13.1 为什么存在

地理数据有自己的特点：

13.2 典型代表

13.3 PostGIS 为什么是事实标准

13.4 何时该选

• LBS 应用（外卖、地图、导航）
• 物流调度、配送路径
• 物联网设备位置
• 城市规划、交通分析

13.5 何时不该选

• 简单”省市区”字典（用普通表）
• 海量 GPS 轨迹 + 时序特征（用 TSDB）

十四、Data Warehouse：数据仓库 —— 决策的底层

14.1 为什么存在

数据仓库和 OLTP 是两种完全不同的存在：

14.2 典型代表

14.3 云数仓的 3 个创新

14.4 何时该选

• 企业级 BI 报表（高管驾驶舱）
• 历史数据分析（> 1 年）
• 跨业务数据整合（财务 + 销售 + 运营）
• 大模型训练数据准备

14.5 何时不该选

• 实时 OLTP（用 RDBMS）
• 小数据量（用 RDBMS / DuckDB）
• 强烈定制 ETL（自己写 pipeline）

十五、12 类数据库横向对比矩阵

把所有维度放在一张表里：

十六、选型决策树：从业务到数据库

十七、3 个真实场景的数据库组合

17.1 场景 1：电商 SaaS

5 个数据库，每个专攻一个领域。这是真实生产架构。

17.2 场景 2：AI 应用（RAG）

Milvus + PG 是 RAG 标配——向量检索 + 元数据管理。

17.3 场景 3：物联网监控

TDengine 单 DB 搞定——专为 IoT 设计。

十八、12 类数据库的”哲学图谱”

每类数据库背后都是一种工程哲学：

• RDBMS：通用 + 强一致 = 业务流程的中流砥柱
• TSDB：时间维度做到极致 = 让监控/IoT 便宜 100x
• Graph：关系维度做到极致 = 让社交/推荐跑得起来
• Column：扫描维度做到极致 = 让 PB 级分析分钟出结果
• Vector：相似度做到极致 = 打开 AI 应用的大门

十九、回到标题：为什么要对数据库进行细分

回答标题：数据库细分是必然——因为：

1. 业务多样化 → 没有一种数据库能满足所有场景
2. 数据模型多样化 → 不同数据有不同灵魂结构
3. 物理模型多样化 → 不同访问模式需要不同存储引擎

未来 5 年趋势：

• AI 时代会催生更多专用数据库（向量、图、RAG）
• 多模融合会继续（pgvector、PostGIS 都是 PG 在扩张边界）
• 云原生会重新定义”专用”（Snowflake、Pinecone 都是托管服务）

二十、3 条经验法则

20.1 法则 1：先 PG + Redis，看性能瓶颈再加专用

80% 的业务：

再加专用 DB 的信号：

20.2 法则 2：避免数据库”宗教战争”

正解：用业务需求反推技术选型，不是反过来。

20.3 法则 3：组合胜于万能

5 数据库搞定一切 > 1 数据库搞定一切。

二十一、参考资料

同系列前文

• 当我们在说”数据库”的时候，我们到底在说什么 —— 从用户的视角拆解 PostgreSQL 的能力与接口
• 选数据库的时候，我们究竟在选什么 —— 当基础能力都满足时，哪些维度让数据库”脱颖而出”

推荐阅读

• DB-Engines Ranking：https://db-engines.com/en/ranking（数据库流行度排行）
• “One Size Fits All” 论文：Stonebraker et al., 2005（数据库细分的经典论证）
• **”The End of an Architectural Era”**：Stonebraker et al., 2007（行存 vs 列存）
• PostgreSQL 生态：https://www.postgresql.org/docs/

各类型代表数据库官方资源

• RDBMS：postgresql.org / mysql.com
• TSDB：docs.influxdata.com / docs.timescale.com
• Graph：neo4j.com / nebula-graph.io
• Document：mongodb.com / ferretdb.com
• KV：redis.io / etcd.io
• Column：clickhouse.com / duckdb.org
• Search：elastic.co / opensearch.org
• Vector：milvus.io / github.com/pgvector/pgvector
• Embedded：sqlite.org / duckdb.org
• Multi-model：arangodb.com / surrealDB.com
• GIS：postgis.net
• Data Warehouse：snowflake.com / cloud.google.com/bigquery