面向有经验的后端/数据/平台工程师。本文不堆术语,只讲清楚三类数据库各自擅长什么、在什么场景下会踩坑,以及真实业务里怎么组合使用。原理部分点到为止,深入链接放在文末。

数据库选型这件事,八成的争论其实源于一个误会:把"存储模型"当成了"产品好坏"来比。行式、列式、向量,本质是三种不同的数据组织方式,各自为一类访问模式做了极致优化。选错的代价不是"慢一点",而是整个架构跑偏。

下面按"它怎么存 → 适合什么 → 什么时候别用 → 真实案例"的结构,逐个拆开。

一、行式数据库:为"一次操作一条记录"而生

它怎么存

行式数据库把一整条记录的所有字段连续存放在磁盘上:

Block 1: [1, 张三, 25, 北京] [2, 李四, 30, 上海]
Block 2: [3, 王五, 28, 广州] [4, 赵六, 35, 深圳]

读一条完整记录,一次磁盘 IO 就能拿全所有字段。

📊 建议配图:行式存储 vs 列式存储的磁盘布局对比图(可搜索 "row vs columnar storage layout")

适合什么场景

行式数据库的统治区是 OLTP(在线事务处理),核心诉求是:

• 高并发的单条/小批量读写:下单、转账、改资料,每次只碰几行
• 强事务保证:ACID、行级锁、MVCC,金融和交易场景的硬需求
• 频繁更新:订单状态流转、库存扣减
• 点查询:按主键或索引精确定位

代表产品:MySQL、PostgreSQL、Oracle、SQL Server。

什么时候别用

当你的查询变成 SELECT AVG(amount) FROM orders WHERE created_at > '2025-01-01',扫描上亿行只为了算几个聚合值时,行式数据库会被迫读入大量你根本不需要的列。这类大规模分析查询,行式库会越跑越吃力。

真实案例

电商订单系统:用户下单、支付、查看"我的订单",全部是单条记录的读写,并发高、要求强一致。PostgreSQL / MySQL 是默认选择。等到要做"近 30 天 GMV 趋势分析"时,数据会被同步到下游的列式数仓——而不是在订单库上硬跑。

二、列式数据库:为"扫一整列做分析"而生

它怎么存

列式数据库把同一个字段的所有值连续存放:

ID:   [1, 2, 3, 4]
姓名: [张三, 李四, 王五, 赵六]
年龄: [25, 30, 28, 35]
城市: [北京, 上海, 广州, 深圳]

算 SUM(年龄)?只读"年龄"这一列就够了,完全不碰其他列。

为什么快(一句话原理)

两个关键优势:只读需要的列(IO 大幅减少)+ 同列数据类型一致、重复度高,压缩率极高(常见 5~10 倍压缩)。再叠加向量化执行(SIMD 批量计算),聚合查询能比行式库快几个数量级。

适合什么场景

列式数据库的主场是 OLAP(在线分析处理):

• 大规模聚合统计:SUM、AVG、COUNT、GROUP BY
• 数据仓库 / BI 报表:多维分析、下钻
• 日志与时序分析:海量数据写入后做查询
• 宽表少列查询:几百列的表,每次只查其中几列

代表产品:ClickHouse、Apache Doris、Apache Druid、Amazon Redshift、Google BigQuery。

💡 前面聊到的 Doris,本质就属于这一类——列式 OLAP 数仓,MPP 架构,主打实时分析。它额外提供了可选的行存格式来支持高并发点查,以及较新版本的向量检索能力,但定位仍是分析型数据库。

什么时候别用

别拿它当业务主库。 列式库对单条记录的更新/删除很不友好——改一行可能要触碰多个列文件。高频 UPDATE、强事务、行级锁这些 OLTP 需求,列式库要么不支持要么很弱。

真实案例

实时数据看板:某 App 要展示"实时在线人数、各渠道转化漏斗、分钟级 PV/UV"。数据量每天数十亿行,查询都是聚合。用 ClickHouse / Doris,亚秒级返回;若用 MySQL,聚合查询直接超时。

三、向量数据库:为"找相似"而生

它怎么存

向量数据库存的不是结构化字段,而是高维向量(embedding)——由模型把文本、图片、音频编码成的一串浮点数:

"如何重置密码"      → [0.12, -0.45, 0.88, ...]   (通常 768 / 1536 维)
"忘记密码怎么办"    → [0.10, -0.43, 0.90, ...]   ← 语义接近,向量也接近
"今天天气不错"      → [-0.88, 0.21, 0.05, ...]   ← 语义无关,向量很远

📊 建议配图:embedding 向量空间中"语义相近 = 距离相近"的示意图(可搜索 "vector embedding similarity space")

为什么不一样(一句话原理)

行式/列式都在做精确匹配(WHERE city = '北京'),而向量数据库做的是相似度搜索:给一个查询向量,找出空间中距离最近的 K 个向量(KNN/ANN)。为了在亿级向量里快速找到近邻,它用 HNSW、IVF 等近似最近邻(ANN)索引,牺牲一点点精度换取巨大的速度提升。

适合什么场景

• 语义搜索:按意思搜,而非按关键词
• RAG(检索增强生成):大模型应用的标配,先检索相关文档再喂给 LLM
• 推荐系统:找"相似商品 / 相似用户"
• 图像 / 音频 / 视频检索:以图搜图、声纹匹配
• 去重与异常检测:找相似内容

代表产品:专用库 Milvus、Pinecone、Weaviate、Qdrant;扩展方案 pgvector(PostgreSQL 插件)、Elasticsearch、Redis。

什么时候别用

• 需要精确查询和事务时:向量库不是用来替代业务库的
• 数据量不大(几万条以内):直接在 PostgreSQL 装 pgvector 就够了,没必要上专用集群
• 需要复杂的结构化过滤 + 强一致:向量库的元数据过滤能力通常较弱

真实案例

企业知识库问答:员工问"报销流程是什么",系统先把问题转成向量,在 Milvus 里检索出最相关的几篇制度文档,再连同问题一起交给 LLM 生成答案。这就是典型的 RAG,向量库是它的检索底座。

四、横向对比表

一句话记忆:行式管事务,列式管分析,向量管相似。

五、选型决策路径

实际选型不是三选一,而是看主导访问模式。给一个可直接套用的判断流程:

你的核心查询是什么?
│
├─ 频繁读写单条记录、要事务保证
│     → 行式数据库(MySQL / PostgreSQL)
│
├─ 海量数据做聚合统计、报表分析
│     → 列式数据库(ClickHouse / Doris)
│
├─ 按"语义/相似度"检索,或在做 RAG/推荐
│     → 向量数据库(Milvus / pgvector)
│
└─ 既要事务又要轻量向量检索,且数据量不大
      → PostgreSQL + pgvector(一个库搞定,降低运维成本)

现实中往往是组合拳

成熟系统几乎不会只用一种。一个典型的"业务 + 分析 + AI"架构长这样:

业务写入  →  MySQL/PostgreSQL(行式,处理交易)
                    │
                    │ CDC / ETL 同步
                    ▼
              ClickHouse/Doris(列式,跑报表分析)

文档/知识  →  Embedding 模型  →  Milvus/pgvector(向量,支撑语义检索与 RAG)

三者各司其职,而不是互相替代。选型的本质,是为每一类访问模式匹配最合适的存储模型。

六、几个容易踩的坑

1. "列式 = 更快" 的误解:列式只在分析型查询上快。拿它做高频点查或更新,性能可能还不如行式。
2. 混淆两种"向量化":列式库里的"向量化执行"指 SIMD 批量计算,和向量数据库的"相似度检索"完全是两回事,别被名字带偏。
3. 过早上专用向量库:数据量不大时,pgvector 能省掉一整套独立集群的运维成本,够用就好。
4. 指望一个库通吃:HTAP(行列混合)、多模数据库确实在发展,但目前在各自专项上仍打不过专用方案。架构上接受"组合使用"通常更务实。

延伸阅读

• 行式 vs 列式存储原理:搜索 "columnar storage internals" / ClickHouse 官方文档的存储引擎章节
• ANN 近邻搜索算法:HNSW 与 IVF 论文,或 Milvus 官方文档的索引选型指南
• RAG 架构实践:LangChain / LlamaIndex 文档
• HTAP 与多模数据库的发展:TiDB、SingleStore 的架构白皮书