数据库类型：关系型、列式、文档、图与更多

“数据库类型”真正的含义

“数据库类型”不仅仅是一个标签——它是对系统如何存储数据、如何查询以及优化什么的一种速记。这个选择直接影响速度（什么快什么慢）、成本（硬件或云开销）和能力（事务、分析、搜索、复制等）。

为什么“类型”很重要

不同的数据库类型做出了不同的权衡：

• 关系型数据库 当你的数据结构化且需要可靠事务时非常合适。
• 列式数据库 在扫描大量行以回答分析问题时表现优异。
• 文档数据库 在应用数据结构经常变化时能更快迭代。
• 图数据库 为关系密集型数据而生。
• 向量数据库 更关注“相似性”而非精确匹配。

这些设计选择会影响：

• 查询模式：是大量小查找、复杂连接还是大规模分析扫描？
• 扩展模型：是纵向扩展一台大机器，还是横向扩展多台？
• 数据模型：表、文档、键值对、图、向量或时间序列点。

本指南能学到什么

本文将梳理主要的数据库类型，并对每一种说明：

• 它最擅长什么（以及在哪些场景表现不佳）
• 在真实产品中的典型用例
• 影响性能、成本和复杂度的关键权衡

关于“多模型”系统的简短说明

许多现代产品模糊了界限。一些关系型数据库加入了 JSON 支持，覆盖了 文档数据库 的部分场景。一些搜索和分析平台提供向量索引，具备 向量数据库 的能力。还有一些将流处理与存储结合，带有时序特性。

因此“类型”不是严格的盒子——但作为理解默认强项和适合的工作负载的方式，仍然很有用。

如何用本指南排出候选项

从你的主要工作负载开始：

• 如果需要结构化数据和事务，从 关系型数据库 开始考虑。
• 如果做大量报表和仪表盘，考虑 列式数据库 或数据仓库。
• 如果应用数据形状经常变化，考虑 文档数据库。
• 如果需要极快的按键查找，键值存储 是强候选。

然后使用“如何选择合适的数据库类型”部分，根据规模、一致性需求和常用查询进一步缩小范围。

关系型数据库（SQL）：结构化数据的默认选择

当多数人听到“数据库”时，脑海里浮现的往往是关系型数据库。数据被组织成由行（记录）和列（字段）组成的表。模式定义每个表的结构——有哪些列、列的数据类型以及表之间如何关联。

SQL 广泛流行的原因

关系型系统通常使用 SQL（结构化查询语言） 进行查询。SQL 可读且表达力强：

• 你可以过滤和排序数据（WHERE、ORDER BY）。
• 跨表合并数据（JOIN）。
• 汇总结果（GROUP BY）。

大多数报表工具、分析平台和业务应用都支持 SQL，这使得关系型成为需要广泛兼容性的安全默认选择。

用通俗话说的 ACID 事务

关系型数据库以 ACID 事务 著称，这有助于保持数据正确：

• Atomicity（原子性）：多步变更是“全部或无”。
• Consistency（一致性）：规则（如外键）在变更后仍然成立。
• Isolation（隔离性）：并发更新不会相互破坏。
• Durability（持久性）：一旦保存，数据即使在崩溃后也能恢复。

当错误代价高（比如重复扣款或丢失库存更新）时，这一点尤其重要。

适配的工作负载

关系型数据库通常适合结构化、定义明确的数据和以下工作流：

• 业务应用（类似 CRM/ERP）
• 金融、支付、计费
• 库存、订单、预订

常见的陷阱

正是结构化让关系型数据库可靠，但也可能带来摩擦：

• 刚性的模式：数据形状频繁变化会需要迁移。
• 大量连接的扩展问题：跨大表的大量连接在高规模时可能变慢或成本增加，尤其当数据分布在多台机器上时。

当你的数据模型不断变化，或你需要极端的横向扩展且访问模式简单时，其他数据库类型可能更合适。

列式数据库：为分析而生

列式数据库按“列”而非“行”存储数据。这一改变对分析工作负载的速度和成本有重大影响。

行存 vs 列存

在传统行存（常见于关系型数据库）中，单条记录的所有值存放在一起，适合频繁获取或更新单条客户/订单记录的场景。

在列存中，同一字段的所有值放在一起——所有的 price、所有的 country、所有的 timestamp 会聚在一起。这使得仅读取报表所需的少数列时无需从磁盘拉取整行数据，非常高效。

为什么列式对报表很快

分析与 BI 查询通常会：

• 扫描大量记录
• 选择少数列
• 计算诸如 SUM、AVG、COUNT 的聚合并按维度分组

列式存储会读取更少的数据且压缩率高（相似值聚在一起更容易压缩）。许多列式引擎还采用向量化执行和智能索引/分区来加速大规模扫描。

典型查询模式

列式系统适合仪表盘与报表类查询：“按周营收”、“按地区前 20 产品”、“按渠道转化率”或“过去 30 天服务错误数”等，这些查询触及大量行但只需少数列。

权衡：OLTP 风格的更新与点查

如果你的工作负载主要是“按 ID 获取一条记录”或“每秒更新单行多次”，列式可能感觉更慢或更昂贵。写入通常为批量优化（追加式摄入）而非频繁的小更新。

适用场景

列式数据库非常适合：

• BI 与高层仪表盘
• 事件与点击流分析
• 针对日志或交易的大规模报表

若你的优先事项是对大量数据进行快速聚合，列式通常是首选评估对象。

文档数据库：面向应用数据的灵活模式

文档数据库将数据存为“文档”——类似 JSON 的自包含记录。你通常将相关字段保存在一个对象中（包括嵌套数组和子对象），而不是拆分到许多表中，使其成为应用数据的天然匹配。

文档模型（类似 JSON 的记录）

一个文档可以表示用户、产品或文章——包含可能互不相同的属性。一个产品可以有 size 和 color，另一个产品有 dimensions 和 materials，而无需强制统一模式。

当需求频繁变化或不同项具有不同字段集时，这种灵活性尤其有用。

大致的索引机制

为了避免扫描每个文档，文档数据库使用索引来快速定位匹配查询的文档。你可以为常见查找字段（如 email、sku 或 status）建立索引，许多系统也支持为嵌套字段（如 address.city）建立索引。索引会加速读取，但会增加写入开销，因为文档变化时索引需要更新。

优势与权衡

文档数据库在面对演进式模式、嵌套数据和 API 友好负载时表现出色。权衡通常在以下场景显现：

• 复杂的跨实体连接（不如关系型自然）
• 大规模的多文档事务（许多产品支持，但可能影响性能）
• 严格的范式化需求（团队有时为简化读取会复制数据，这就需要谨慎的更新逻辑）

常见用例

适合内容管理、产品目录、用户资料和后端 API 等——任何“一个页面/屏幕/请求一个对象”的数据模型场景。

键值存储：简单且极快的查找

键值存储是最简单的数据库模型：存储一个 值（从字符串到 JSON blob 均可），并通过 唯一键 检索。核心操作就是“给我这个键对应的值”，因此这些系统可以非常快速。

键值模型（以及为何很快）

由于读写以单一主键为中心，键值存储可以针对低延迟和高吞吐进行优化。许多产品设计为将热点数据保存在内存中、最小化复杂的查询规划并支持横向扩展。

这种简单性也会影响数据建模：你通常要设计出能指向确切记录的键（例如 user:1234:profile），而不是让数据库执行复杂的筛选。

为什么适合作为缓存与会话存储

键值存储常用作较慢主库（如关系型数据库）前的 缓存。如果应用反复需要同一份数据（产品详情、用户权限、定价规则），按键缓存结果可以避免重复计算或查询。

它们也适合 会话存储（例如 session:<id> -> session data），因为会话常被频繁读写并可设置过期。

TTL、驱逐与内存 vs 磁盘

大多数键值存储支持 TTL（生存时间），数据可在过期后自动清理——适用于会话、一次性令牌和速率计数器。

当内存受限时，系统通常采用 驱逐策略（如 LRU）来移除旧条目。有些产品以内存为主，有些可持久化到磁盘以保证耐久性。选择内存或磁盘取决于你是优先考虑速度（内存）还是保留/恢复（磁盘）。

需要提前知道的权衡

键值存储在你已知键时表现出色，但对开放式问题不擅长。与 SQL 数据库相比，其查询模式有限。对二级索引的支持各不相同：部分提供、部分有限、部分鼓励你自己维护查找键。

常见用例

键值存储适合：

• 速率限制：以用户/IP 为键的计数器（带 TTL 窗口）
• 特性开关：快速读取决定用户或分组行为
• 购物车：以用户/会话为键快速更新购物车对象

若访问模式是“按 ID 取/更新”且延迟关键，键值存储通常是获得可靠速度的最简单方法。

宽列数据库：面向大规模的可扩展在线存储

宽列数据库（有时称为 wide-column stores）将数据组织为 列族。与其把表想成每行都有相同列，不如按相关列分组，并允许同一列族下不同行拥有不同的列集合。

宽列 vs 列式分析数据库

尽管名字相似，但宽列数据库和面向分析的列式数据库并不相同：

• 列式数据库：为分析而构建，按列存储以高效扫描大数据集。
• 宽列数据库：为大规模的在线操作负载而建，侧重写入吞吐、横向扩展和按键的低延迟读取。

它们的长处

宽列系统通常擅长：

• 高写入吞吐（每秒摄入大量事件）
• 横向扩展（通过增加节点处理更多流量和数据）
• 在按正确键查询时提供可预测的低延迟读取

典型访问模式

常见模式是：

• 你知道 分区键（决定数据存放的位置），且
• 通常在该分区内读取一个 范围（例如“设备 X 在 10:00–10:05 间的所有事件”）。

这使得它们非常适合按时间顺序的追加型数据。

需要理解的权衡

宽列数据库通常要求 以查询驱动建模：你会围绕具体查询设计表，这可能意味着为支持不同访问模式而复制数据。

它们也往往在 JOIN 和临时查询方面能力有限。如果应用依赖复杂关系和灵活查询，关系型数据库可能更合适。

常见用例

宽列数据库常用于 物联网事件、消息与活动流，以及其他需要快速写入和可预测键访问的大规模操作数据场景。

图数据库：将关系作为一等公民

图数据库以更贴近现实系统的方式存储数据：把事物视为相互连接的节点。与其把关系强行塞进表与关联表，不如把连接本身纳入模型。

图模型：节点、边与属性

一个图通常包含：

• 节点：实体（人、账户、设备、产品）
• 边：它们之间的关系（“关注”、“付款”、“属于”、“发货至”）
• 属性：节点或边上的键值属性（时间戳、金额、标签）

这使得表示网络、层级和多对多关系更直观，而无需扭曲你的模式。

为什么遍历胜过 JOIN

关系密集的查询在关系型数据库中常常需要很多 JOIN。每增加一个 JOIN，随着数据增长它的成本和复杂性都会上升。

图数据库以遍历为设计核心——从一个节点走到相连节点，再到它们的连接。对于“在 2–6 步内找到关联项”类的问题，遍历往往能保持快速且可读，即使网络规模扩展也不受太大影响。

图特别适合回答的问题

图数据库适合：

• 路径与分隔度（最短路径、可达性）
• 推荐（“购买 X 的人也买了 Y”、“朋友的朋友”）
• 欺诈团伙与异常模式识别（共用设备、地址、支付方式）

需要规划的权衡

图模型对团队来说可能是一次转变：建模不同，查询语言（通常是 Cypher、Gremlin 或 SPARQL）可能需要学习。为保持模型可维护，应对关系类型与方向性制定明确约定。

什么时候关系型就够了

如果你的关系很简单、查询主要是过滤/聚合，而且用少量 JOIN 就能覆盖“关联”部分，关系型数据库 仍可能是最直接的选择——尤其当事务和报表已经运行良好时。

向量数据库：面向 AI 应用的相似度检索

向量数据库专注于一种查询：“哪个项与这项最相似？”它不是匹配精确值（如 ID 或关键词），而是比较 embeddings——AI 模型生成的数值化内容表示（文本、图像、音频、产品等）。语义接近的项在多维空间中通常彼此靠近。

向量如何解锁语义搜索

常规搜索可能会漏掉措辞不同但含义相近的结果（“laptop sleeve” vs “notebook case”）。使用 embedding，检索基于意义，因此即使关键词不匹配也能返回相关结果。

核心操作：相似度 + 过滤

主要操作是 最近邻搜索：给定查询向量，检索最接近的向量。

在实际应用中，你通常会把相似度与 过滤条件 结合，例如：

• 仅显示某个客户的文档
• 限制到某一产品类别或语言
• 排除归档或低质量条目

这种“过滤 + 相似度”模式使得向量搜索在真实数据集中变得可用。

向量数据库适合的场景

常见用例包括：

• RAG（检索增强生成）：在 LLM 回答前检索最相关的段落
• 语义搜索：查询知识库、工单或内部文档
• 推荐：基于内容相似的“用户也浏览/购买”

需要注意的权衡

向量搜索依赖专门的索引。构建和更新这些索引可能耗时且占用大量内存。你通常需要在 更高召回率（找到更多真实最佳匹配）和 更低延迟（响应更快）之间权衡。

与关系型或文档存储的搭配

向量数据库很少替代主数据库。常见做法是：主数据（订单、用户、文档）保存在 关系型或文档数据库，embeddings 与向量索引保存在向量数据库——然后把检索结果联回主存以获取完整记录与权限信息。

时序数据库：为时间序列指标优化

时序数据库（TSDB）为持续到达且始终绑定时间戳的数据而设计。比如每 10 秒的 CPU 使用率、每次请求的 API 延迟、每分钟的传感器读数或每秒多次的股票价格。

时序数据的样子

大多数时序记录由：

• 时间戳：测量发生的时间
• 指标/值：你跟踪的数值（延迟、温度、价格）
• 标签/元数据：用于筛选与分组（host=web-01、region=us-east、service=checkout）

这种结构便于回答“按服务显示错误率”或“比较不同地区的延迟”等问题。

TSDB 的性能特性

由于数据量增长快，TSDB 通常关注：

• 压缩：高效存储长时间序列的数值
• 保留策略：自动过期旧数据（例如保留原始数据 7 天，聚合数据 90 天）
• 下采样：将细粒度汇总为摘要（秒级 → 分钟级 → 小时级）

这些特性让存储与查询成本可控，而无需频繁手动清理。

常见查询模式

TSDB 在基于时间的计算上表现优异，如：

• 滚动平均（例如 5 分钟移动平均）
• 百分位数（p95/p99 延迟）
• 变化率（请求/秒）
• 基于阈值或异常的告警

适用与不适用的场景

典型用例包括 监控、可观测性、IoT/传感器 和 金融行情数据。

权衡是：TSDB 并不适合需要跨多个实体做复杂任意联接的场景（例如“用户 → 团队 → 权限 → 项目”那类深度联接），对于这类需求，关系型或图数据库更合适。

仓库与湖仓：组织级别的分析能力

数据仓库与其说是单一的“数据库类型”，不如说是一种工作负载 + 架构：多个团队查询大量历史数据以回答业务问题（营收趋势、流失、库存风险）。你可以把仓库作为托管产品购买，但使其成为仓库的是使用方式——集中式、面向分析且共享。

批量摄入 vs 流式摄入（简化说法）

大多数仓库以两种方式接受数据：

• 批量摄入：数据每小时/每天落地（例如从应用数据库夜间导出），更便宜、更简单，但不是实时的。
• 流式摄入：事件持续到达（点击、付款、IoT），能看到更实时的数字，但需要更复杂的管道与监控。

为什么它们快：列式存储、分区、物化视图

仓库通常通过一些实用技巧为分析优化：

• 列式存储：只读取报表所需的列（适合聚合）
• 分区：按时间或地域拆分大表以减少扫描量
• 物化视图：保存预计算结果（如“按日/国家的销售额”）以加速仪表盘

在规模化下治理不可或缺

当多个部门依赖相同指标时，你需要访问控制（谁能看到什么）、审计日志（谁查询/更改了数据）和血缘追踪（指标来源与变换过程）。这些通常与查询速度同等重要。

何时选择湖仓

湖仓（lakehouse） 将仓库式分析与数据湖的灵活性结合——当你希望在同一位置既有经策划的表也有原始文件（日志、图像、半结构化事件）而不重复存储时，它很有用。适合数据量大、格式多样且仍需 SQL 友好报表的场景。

关键权衡：一致性、扩展与查询模式

在数据库类型之间选择，关键不是“哪个最好”，而是“哪个最合适”：你需要怎样查询、以何种速度、以及当系统部分失效时如何表现。

OLTP vs OLAP（匹配工作负载）

一个快速经验法则：

• OLTP（联机事务处理）：大量小读写（结账、登录、订单更新）。优先：低延迟、正确更新、高并发。
• OLAP（联机分析处理）：较少但更重的查询扫描大量行（仪表盘、趋势分析）。优先：快速聚合、列式存储、计算与存储分离。

关系型数据库通常适合 OLTP；列式系统、仓库与湖仓常用于 OLAP。

用通俗话说的 CAP

当网络分区发生时，通常无法同时满足三者：

• 一致性：所有人立即看到相同数据。
• 可用性：系统持续响应请求。
• 分区容忍性：在网络分裂时系统仍能工作。

许多分布式数据库选择在故障期间保持可用并事后和解（最终一致性）。另一些则优先保证严格正确性，即使这意味着在不健康时拒绝部分请求。

扩展方式：纵向、横向与分片

• 纵向扩展：一台更大的机器——简单，但有上限。
• 横向扩展：更多机器——更多容量，但需要协调。
• 分片：按某个键把数据拆到不同节点（常按客户 ID）。能提升扩展性，但跨分片的查询与事务会变复杂。

事务与并发基础

如果很多用户更新相同数据，你需要清晰的规则。事务 把多个步骤打包为“全部或无”。锁与隔离级别 防止冲突，但可能降低吞吐；放宽隔离提高速度但可能允许异常情况发生。

运维方面的考量（别忽视）

尽早规划 备份、复制 与 灾难恢复。考虑恢复测试的易用性、复制延迟监控和升级操作——这些第 2 天（day-two）的问题往往和查询速度同等重要。

如何选择合适的数据库类型（实用步骤）

选择主要在于“你要用数据做什么”，不是跟风。一个实用的起点是从查询和工作负载倒推。

1）从查询出发（而不是从数据）

把应用或团队必须完成的前 5–10 项写下来：

• 你最常读取什么（单条记录查找、筛选、连接、聚合、相似度搜索）？
• 你最常写入什么（单行插入、事件流、更新、批量导入）？
• 结果需要多新鲜（毫秒、秒、分钟）？

这比任何功能清单更能快速缩小选项。

2）把数据库与数据形态匹配

快速“形态”清单：

• 结构化且一致的字段 → 关系型数据库
• 半结构化 JSON 且经常变化 → 文档数据库
• 要深度遍历的多对多关系 → 图数据库
• embeddings 与最近邻搜索 → 向量数据库
• 带时间戳的事件/指标与汇总 → 时序数据库
• 可预测访问模式下的大规模横向表 → 宽列数据库
• 非常简单的按键取/设 → 键值存储
• 重度分析扫描与聚合 → 列式数据库（或数据仓库）

3）提前明确延迟、吞吐与成本驱动因素

性能目标决定架构。设定粗略目标（p95 延迟、每秒读写数、数据保留）。成本通常来自：

• 存储（原始数据 + 副本）
• 计算（查询、ETL/ELT、后台任务）
• 复制（多区/高可用）
• 索引（更快的查询，更高的写入开销）

4）一个简化决策表

许多团队使用“两个数据库”：一个用于在线操作（例如关系型），另一个用于分析（例如列式/仓库）。“正确”的选择是让你最重要的查询变得最简单、最快且最便宜地可靠运行。

如果你需要快速构建产品的实用建议

若你在做原型或快速上线新功能，数据库决策常与开发流程绑在一起。像 Koder.ai 这样的低码/生成平台可以让这一切更具体：例如 Koder.ai 的默认后端栈是 Go + PostgreSQL，当你需要事务正确性和广泛的 SQL 工具链时，这是一个很强的起点。

随着产品成长，你仍可以添加专用数据库（例如用于语义搜索的向量库或用于分析的列式仓库），同时把 PostgreSQL 作为事实来源（system of record）。关键是从今天必须支持的工作负载开始，并为“添加第二个存储”留出空间，当查询模式需要时再扩展。