比较主要数据库类型——关系型、列式、文档、图、向量、键值及更多;包含适用场景、权衡和选择建议,帮助你为特定工作负载挑选合适数据库。

“数据库类型”不仅仅是一个标签——它是对系统如何存储数据、如何查询以及优化什么的一种速记。这个选择直接影响速度(什么快什么慢)、成本(硬件或云开销)和能力(事务、分析、搜索、复制等)。
不同的数据库类型做出了不同的权衡:
这些设计选择会影响:
本文将梳理主要的数据库类型,并对每一种说明:
许多现代产品模糊了界限。一些关系型数据库加入了 JSON 支持,覆盖了 文档数据库 的部分场景。一些搜索和分析平台提供向量索引,具备 向量数据库 的能力。还有一些将流处理与存储结合,带有时序特性。
因此“类型”不是严格的盒子——但作为理解默认强项和适合的工作负载的方式,仍然很有用。
从你的主要工作负载开始:
然后使用“如何选择合适的数据库类型”部分,根据规模、一致性需求和常用查询进一步缩小范围。
当多数人听到“数据库”时,脑海里浮现的往往是关系型数据库。数据被组织成由行(记录)和列(字段)组成的表。模式定义每个表的结构——有哪些列、列的数据类型以及表之间如何关联。
关系型系统通常使用 SQL(结构化查询语言) 进行查询。SQL 可读且表达力强:
WHERE、ORDER BY)。JOIN)。GROUP BY)。大多数报表工具、分析平台和业务应用都支持 SQL,这使得关系型成为需要广泛兼容性的安全默认选择。
关系型数据库以 ACID 事务 著称,这有助于保持数据正确:
当错误代价高(比如重复扣款或丢失库存更新)时,这一点尤其重要。
关系型数据库通常适合结构化、定义明确的数据和以下工作流:
正是结构化让关系型数据库可靠,但也可能带来摩擦:
当你的数据模型不断变化,或你需要极端的横向扩展且访问模式简单时,其他数据库类型可能更合适。
列式数据库按“列”而非“行”存储数据。这一改变对分析工作负载的速度和成本有重大影响。
在传统行存(常见于关系型数据库)中,单条记录的所有值存放在一起,适合频繁获取或更新单条客户/订单记录的场景。
在列存中,同一字段的所有值放在一起——所有的 price、所有的 country、所有的 timestamp 会聚在一起。这使得仅读取报表所需的少数列时无需从磁盘拉取整行数据,非常高效。
分析与 BI 查询通常会:
SUM、AVG、COUNT 的聚合并按维度分组列式存储会读取更少的数据且压缩率高(相似值聚在一起更容易压缩)。许多列式引擎还采用向量化执行和智能索引/分区来加速大规模扫描。
列式系统适合仪表盘与报表类查询:“按周营收”、“按地区前 20 产品”、“按渠道转化率”或“过去 30 天服务错误数”等,这些查询触及大量行但只需少数列。
如果你的工作负载主要是“按 ID 获取一条记录”或“每秒更新单行多次”,列式可能感觉更慢或更昂贵。写入通常为批量优化(追加式摄入)而非频繁的小更新。
列式数据库非常适合:
若你的优先事项是对大量数据进行快速聚合,列式通常是首选评估对象。
文档数据库将数据存为“文档”——类似 JSON 的自包含记录。你通常将相关字段保存在一个对象中(包括嵌套数组和子对象),而不是拆分到许多表中,使其成为应用数据的天然匹配。
一个文档可以表示用户、产品或文章——包含可能互不相同的属性。一个产品可以有 size 和 color,另一个产品有 dimensions 和 materials,而无需强制统一模式。
当需求频繁变化或不同项具有不同字段集时,这种灵活性尤其有用。
为了避免扫描每个文档,文档数据库使用索引来快速定位匹配查询的文档。你可以为常见查找字段(如 email、sku 或 status)建立索引,许多系统也支持为嵌套字段(如 address.city)建立索引。索引会加速读取,但会增加写入开销,因为文档变化时索引需要更新。
文档数据库在面对演进式模式、嵌套数据和 API 友好负载时表现出色。权衡通常在以下场景显现:
适合内容管理、产品目录、用户资料和后端 API 等——任何“一个页面/屏幕/请求一个对象”的数据模型场景。
键值存储是最简单的数据库模型:存储一个 值(从字符串到 JSON blob 均可),并通过 唯一键 检索。核心操作就是“给我这个键对应的值”,因此这些系统可以非常快速。
由于读写以单一主键为中心,键值存储可以针对低延迟和高吞吐进行优化。许多产品设计为将热点数据保存在内存中、最小化复杂的查询规划并支持横向扩展。
这种简单性也会影响数据建模:你通常要设计出能指向确切记录的键(例如 user:1234:profile),而不是让数据库执行复杂的筛选。
键值存储常用作较慢主库(如关系型数据库)前的 缓存。如果应用反复需要同一份数据(产品详情、用户权限、定价规则),按键缓存结果可以避免重复计算或查询。
它们也适合 会话存储(例如 session:<id> -> session data),因为会话常被频繁读写并可设置过期。
大多数键值存储支持 TTL(生存时间),数据可在过期后自动清理——适用于会话、一次性令牌和速率计数器。
当内存受限时,系统通常采用 驱逐策略(如 LRU)来移除旧条目。有些产品以内存为主,有些可持久化到磁盘以保证耐久性。选择内存或磁盘取决于你是优先考虑速度(内存)还是保留/恢复(磁盘)。
键值存储在你已知键时表现出色,但对开放式问题不擅长。与 SQL 数据库相比,其查询模式有限。对二级索引的支持各不相同:部分提供、部分有限、部分鼓励你自己维护查找键。
键值存储适合:
若访问模式是“按 ID 取/更新”且延迟关键,键值存储通常是获得可靠速度的最简单方法。
宽列数据库(有时称为 wide-column stores)将数据组织为 列族。与其把表想成每行都有相同列,不如按相关列分组,并允许同一列族下不同行拥有不同的列集合。
尽管名字相似,但宽列数据库和面向分析的列式数据库并不相同:
宽列系统通常擅长:
常见模式是:
这使得它们非常适合按时间顺序的追加型数据。
宽列数据库通常要求 以查询驱动建模:你会围绕具体查询设计表,这可能意味着为支持不同访问模式而复制数据。
它们也往往在 JOIN 和临时查询方面能力有限。如果应用依赖复杂关系和灵活查询,关系型数据库可能更合适。
宽列数据库常用于 物联网事件、消息与活动流,以及其他需要快速写入和可预测键访问的大规模操作数据场景。
图数据库以更贴近现实系统的方式存储数据:把事物视为相互连接的节点。与其把关系强行塞进表与关联表,不如把连接本身纳入模型。
一个图通常包含:
这使得表示网络、层级和多对多关系更直观,而无需扭曲你的模式。
关系密集的查询在关系型数据库中常常需要很多 JOIN。每增加一个 JOIN,随着数据增长它的成本和复杂性都会上升。
图数据库以遍历为设计核心——从一个节点走到相连节点,再到它们的连接。对于“在 2–6 步内找到关联项”类的问题,遍历往往能保持快速且可读,即使网络规模扩展也不受太大影响。
图数据库适合:
图模型对团队来说可能是一次转变:建模不同,查询语言(通常是 Cypher、Gremlin 或 SPARQL)可能需要学习。为保持模型可维护,应对关系类型与方向性制定明确约定。
如果你的关系很简单、查询主要是过滤/聚合,而且用少量 JOIN 就能覆盖“关联”部分,关系型数据库 仍可能是最直接的选择——尤其当事务和报表已经运行良好时。
向量数据库专注于一种查询:“哪个项与这项最相似?”它不是匹配精确值(如 ID 或关键词),而是比较 embeddings——AI 模型生成的数值化内容表示(文本、图像、音频、产品等)。语义接近的项在多维空间中通常彼此靠近。
常规搜索可能会漏掉措辞不同但含义相近的结果(“laptop sleeve” vs “notebook case”)。使用 embedding,检索基于意义,因此即使关键词不匹配也能返回相关结果。
主要操作是 最近邻搜索:给定查询向量,检索最接近的向量。
在实际应用中,你通常会把相似度与 过滤条件 结合,例如:
这种“过滤 + 相似度”模式使得向量搜索在真实数据集中变得可用。
常见用例包括:
向量搜索依赖专门的索引。构建和更新这些索引可能耗时且占用大量内存。你通常需要在 更高召回率(找到更多真实最佳匹配)和 更低延迟(响应更快)之间权衡。
向量数据库很少替代主数据库。常见做法是:主数据(订单、用户、文档)保存在 关系型或文档数据库,embeddings 与向量索引保存在向量数据库——然后把检索结果联回主存以获取完整记录与权限信息。
时序数据库(TSDB)为持续到达且始终绑定时间戳的数据而设计。比如每 10 秒的 CPU 使用率、每次请求的 API 延迟、每分钟的传感器读数或每秒多次的股票价格。
大多数时序记录由:
这种结构便于回答“按服务显示错误率”或“比较不同地区的延迟”等问题。
由于数据量增长快,TSDB 通常关注:
这些特性让存储与查询成本可控,而无需频繁手动清理。
TSDB 在基于时间的计算上表现优异,如:
典型用例包括 监控、可观测性、IoT/传感器 和 金融行情数据。
权衡是:TSDB 并不适合需要跨多个实体做复杂任意联接的场景(例如“用户 → 团队 → 权限 → 项目”那类深度联接),对于这类需求,关系型或图数据库更合适。
数据仓库与其说是单一的“数据库类型”,不如说是一种工作负载 + 架构:多个团队查询大量历史数据以回答业务问题(营收趋势、流失、库存风险)。你可以把仓库作为托管产品购买,但使其成为仓库的是使用方式——集中式、面向分析且共享。
大多数仓库以两种方式接受数据:
仓库通常通过一些实用技巧为分析优化:
当多个部门依赖相同指标时,你需要访问控制(谁能看到什么)、审计日志(谁查询/更改了数据)和血缘追踪(指标来源与变换过程)。这些通常与查询速度同等重要。
湖仓(lakehouse) 将仓库式分析与数据湖的灵活性结合——当你希望在同一位置既有经策划的表也有原始文件(日志、图像、半结构化事件)而不重复存储时,它很有用。适合数据量大、格式多样且仍需 SQL 友好报表的场景。
在数据库类型之间选择,关键不是“哪个最好”,而是“哪个最合适”:你需要怎样查询、以何种速度、以及当系统部分失效时如何表现。
一个快速经验法则:
关系型数据库通常适合 OLTP;列式系统、仓库与湖仓常用于 OLAP。
当网络分区发生时,通常无法同时满足三者:
许多分布式数据库选择在故障期间保持可用并事后和解(最终一致性)。另一些则优先保证严格正确性,即使这意味着在不健康时拒绝部分请求。
如果很多用户更新相同数据,你需要清晰的规则。事务 把多个步骤打包为“全部或无”。锁与隔离级别 防止冲突,但可能降低吞吐;放宽隔离提高速度但可能允许异常情况发生。
尽早规划 备份、复制 与 灾难恢复。考虑恢复测试的易用性、复制延迟监控和升级操作——这些第 2 天(day-two)的问题往往和查询速度同等重要。
选择主要在于“你要用数据做什么”,不是跟风。一个实用的起点是从查询和工作负载倒推。
把应用或团队必须完成的前 5–10 项写下来:
这比任何功能清单更能快速缩小选项。
快速“形态”清单:
性能目标决定架构。设定粗略目标(p95 延迟、每秒读写数、数据保留)。成本通常来自:
| 主要用例 | 常见最佳匹配 | 原因 |
|---|---|---|
| 事务、发票、用户账户 | 关系型(SQL) | 强约束、连接、一致性 |
| 结构经常演进的应用数据 | 文档 | 模式灵活、天然 JSON |
| 实时缓存/会话状态 | 键值存储 | 基于键的快速读取 |
| 点击流/时间序列指标 | 时序数据库 | 高写入 + 基于时间的查询 |
| 仪表盘、大规模聚合 | 列式数据库 | 快速扫描 + 高压缩 |
| 社交/知识关系 | 图数据库 | 高效关系遍历 |
| 语义搜索、RAG 检索 | 向量数据库 | 基于 embeddings 的相似度检索 |
| 海量操作数据与大规模扩展 | 宽列数据库 | 横向扩展、可预测查询 |
许多团队使用“两个数据库”:一个用于在线操作(例如关系型),另一个用于分析(例如列式/仓库)。“正确”的选择是让你最重要的查询变得最简单、最快且最便宜地可靠运行。
若你在做原型或快速上线新功能,数据库决策常与开发流程绑在一起。像 Koder.ai 这样的低码/生成平台可以让这一切更具体:例如 Koder.ai 的默认后端栈是 Go + PostgreSQL,当你需要事务正确性和广泛的 SQL 工具链时,这是一个很强的起点。
随着产品成长,你仍可以添加专用数据库(例如用于语义搜索的向量库或用于分析的列式仓库),同时把 PostgreSQL 作为事实来源(system of record)。关键是从今天必须支持的工作负载开始,并为“添加第二个存储”留出空间,当查询模式需要时再扩展。
“数据库类型”其实是三个方面的缩写:
选择数据库类型本质上就是为性能、成本和运维复杂度选定一组默认行为。
从你最重要的 前 5–10 个查询和写入模式 开始,然后把它们映射到最匹配的优势:
如果你既要做 OLTP 又做分析,尽早规划“两个系统”:业务数据库 + 分析数据库。
当你需要以下能力时,关系型数据库是一个很好的默认选择:
它们的痛点通常是:频繁的模式迁移或需要在大量分片上做大量连接时的横向扩展困难。
ACID 是对多步变更的可靠性保证:
当错误代价很高(付款、预订、库存更新等)时,ACID 至关重要。
列式数据库在下面的查询模式下更快:
SUM、COUNT、AVG、GROUP BY)原因是列式按列存储、读取更少的数据且压缩率高。它们通常不适合频繁的小更新或“按 ID 取一条记录”的 OLTP 场景,后者传统行存更合适。
当你的应用数据天然是 JSON 式对象且字段经常变化时,文档数据库更加合适:
需要注意的权衡:跨实体复杂连接不是很自然(虽然可以通过应用层或多次查询处理),多文档事务在高负载时可能影响性能,团队有时会为简化读取而复制数据,这需要额外的更新逻辑。
键值存储适合以下访问模式:
注意:开放式查询能力通常较弱。二级索引支持因产品而异,常见做法是设计合适的键或维护额外的查找键。
两者名字相似但面向不同的工作负载:
宽列通常要求以查询为驱动进行建模(为常见查询设计表结构),而不是像传统 SQL 那样灵活进行任意联接。
当核心问题以“关系”为中心时,选择图数据库:
图数据库以遍历为核心,比关系型里多次 JOIN 更高效。但数据建模和查询语言(如 Cypher、Gremlin、SPARQL)可能需要学习成本。如果关系简单且用 JOIN 已能满足需求,关系型仍可能是更简单的选择。
向量数据库解决的是相似度检索问题:给定一个查询的 embedding(来自文本/图像/音频/产品的向量表示),找出与之最相近的向量。
常见用途:
它通常不会替代主数据库:主记录仍放在关系或文档库,向量库存 embeddings 和索引,检索结果再联回主库用于权限检查与完整记录返回。