System Design 101：如何决定使用哪种类型的数据库——从关系型到宽列存储的选型指南

数据库选型是系统设计面试与生产架构中绕不开的决策点。当前市面上有 Oracle、MySQL、MariaDB、SQLite、PostgreSQL、Redis、ClickHouse、MongoDB、S3、Ceph 等成百上千种数据库，如何为你的系统挑选合适的存储架构？本文以 system-design-101 仓库中的 how-do-you-decide-which-type-of-database-to-use.md 为骨架，逐一拆解六类数据库的适用场景，并结合仓库内其他数据库专题（数据库与存储分类）帮助你建立一套可复用的选型判断框架。读完本文，你将能依据数据形态、读写模式与一致性要求，在关系型、内存型、时序型、图、文档与宽列存储之间做出有依据的选择。

选型的前提：先理解数据特征，再匹配存储架构

数据库是大多数现代应用的支柱，它负责存储和管理驱动应用的数据；关系型、NoSQL、内存数据库、键值存储等类型各有优劣，最佳选择取决于应用的具体需求（见 database-and-storage.md）。选型不是"哪个数据库更好"的比拼，而是"哪类数据模型与访问模式更匹配"的匹配过程。

在动手挑选之前，建议先回答几个问题：

• 数据的结构：是强结构化的表格数据，还是 JSON 文档、键值对、时间戳序列、图关系？
• 读写的比例与模式：写密集还是读密集？读是持续稳定还是突发的（spiky）？
• 一致性要求：是否需要强一致性与事务（ACID），还是可以接受最终一致性？
• 数据规模与生命周期：数据是海量不可变的日志/事件，还是需要频繁更新的状态？
• 查询方式：复杂多表 JOIN、全文检索、范围聚合、图遍历，还是简单的点查/批量写？

带着这些问题，下面的六类数据库选型清单就有了落点。

六类数据库选型清单

how-do-you-decide-which-type-of-database-to-use.md 给出了最简练的总结，逐条展开如下。

1. 关系型数据库（Relational Database）：几乎所有问题都能用它兜底

Almost anything could be solved by them.

关系型数据库把数据组织在规整的表中，行（tuple/record）代表记录、列（attribute）代表属性。它们支持通过键与规范化（normalization）保证数据完整性、避免冗余，并以 SQL 作为统一的查询语言，因而能高效处理多对多关系、复杂查询与事务（参见 top-6-database-models.md 中关于 Relational Model 的描述）。

典型代表：Oracle、MySQL、MariaDB、SQLite、PostgreSQL。

适用场景：

• 业务核心数据：用户、订单、账户、库存等强一致、需事务保障的状态数据；
• 需要复杂 JOIN 与灵活的临时查询；
• 数据模型稳定、关系清晰的传统业务系统。

代价：垂直扩展为主、水平扩展（分片）成本较高；在海量高并发写入或超大数据集下，需要借助缓存、读写分离、分库分表等手段（仓库中的 a-cheatsheet-on-database-performance.md、7-must-know-strategies-to-scale-your-database.md 可进一步参考）。

一句话决策：不确定该选什么时，关系型数据库通常是安全起点——它覆盖了绝大多数常规业务需求。

2. 内存型存储（In-Memory Store）：用速度换容量

Their speed and limited data size make them ideal for fast operations.

内存型存储把数据放在 RAM 中，读写延迟远低于磁盘型数据库，但可用数据量受内存容量限制。

典型代表：Redis、Memcached。

适用场景：

• 缓存层：加速热点数据读取（结合缓存淘汰策略，参见 top-8-cache-eviction-strategies.md）；
• 会话（Session）存储、计数器、排行榜、分布式锁等高频小数据操作；
• 需要微秒/毫秒级响应的热路径。

代价：内存成本高、容量有限，通常不作为唯一持久化层；需要考虑持久化与宕机恢复方案（仓库中 how-does-redis-persist-data.md 与 why-is-redis-so-fast.md 提供了深入剖析）。

一句话决策：当"快"是第一诉求、数据规模可控时，内存存储是最直接的选择。

3. 时序数据库（Time-Series Database，TSDB）：专为时间戳数据而生

Store and manage time-stamped data.

时序数据库专门针对随时间不断追加、带有时间戳的数据进行优化。从用户视角看数据形似关系表，但底层往往以 <a href="https://link.gitcode.com/i/46e4c1cbda9bf4fb6627c339132076cf" target="_blank">Measurement, Tag, Field Name] 的形式存储在 Time-Structured Merge Trees（TSM）等结构中，从而可以基于时间和标签（tags）快速聚合分析（见 [time-series-db-tsdb-in-20-lines.md）。

典型代表：ClickHouse、InfluxDB、Prometheus 生态等（仓库选型文档中亦将 ClickHouse 列为候选之一）。

典型使用场景（据 time-series-db-tsdb-in-20-lines.md）：

• 市场行情与交易数据更新；
• 服务器指标（metrics）；
• 应用性能监控（APM）；
• 网络数据；
• 传感器数据；
• 事件流与点击流。

为什么不用关系型数据库做时序？ choose-the-right-database-for-metric-collecting-system.md 给出了明确警告：通用数据库（如 MySQL）理论上能存时序数据，但要达到同等规模需要专家级调优——例如在滚动时间窗口内计算移动平均，需要写出难读的复杂 SQL；要为每个标签（tag）加索引；且在持续高写入负载下表现不佳。这也是时序数据库存在并流行的根本原因。

一句话决策：当数据以时间为轴、写多读少、需要按时间窗口聚合时，直接选择 TSDB。

4. 图数据库（Graph Database）：复杂关系的天然载体

It is suitable for complex relationships between unstructured objects.

图数据库以节点（node）与边（edge）组织数据，专为表达"谁与谁相连"这类复杂关系而生（参见 types-of-databases.md 中 Graph DB 的描述：社交网络中"谁是好友"正是典型场景）。

典型代表：Neo4j、Amazon Neptune 等。

适用场景：

• 社交网络好友/关注关系；
• 推荐引擎中的关联挖掘；
• 权限与依赖关系分析；
• 欺诈检测中的资金流与关系链挖掘。

一句话决策：当查询的核心是"关系本身"且关系多跳遍历频繁时，图数据库远优于关系型数据库的递归 JOIN。

5. 文档存储（Document Store）：适合大规模不可变数据

They are good for large immutable data.

文档数据库以 JSON 等类文档格式存储信息，面向文档而非表格，天然贴合应用层的数据形状（见 types-of-databases.md 中 Document DB 的描述）。

典型代表：MongoDB、CouchDB 等。

适用场景：

• 内容管理、博客、商品目录等半结构化数据；
• 日志、事件等大规模、以追加为主、很少改动的不可变数据；
• 需要灵活 schema、字段随业务演进的场景。

一句话决策：数据结构松散、以文档为读写单元、数据基本只增不改时，文档存储是省心之选。

6. 宽列存储（Wide Column Store）：大数据分析的后盾

They are usually used for big data, analytics, reporting, etc., which needs denormalized data.

宽列存储把数据按列族（column family）组织，擅长存储海量反规范化（denormalized）数据，按列切片式读写非常高效（types-of-databases.md 中 Column DB 的比喻是"像厨师备菜一样切片切丁，高效又快速"）。

典型代表：Cassandra、Bigtable、ScyllaDB 等。

适用场景：

• 大数据分析与报表（OLAP）；
• 海量事件/日志的批量写入与扫描；
• 需要极强水平扩展能力的写密集场景（如 IoT 设备数据、推荐系统特征数据）。

一句话决策：当数据量级巨大、以批量分析与列级聚合为主、愿意接受反规范化的冗余时，宽列存储是正确答案。

一张表看懂：六类数据库的选型速查

数据库类型	典型代表	擅长解决	主要代价
关系型（Relational）	Oracle、MySQL、PostgreSQL、SQLite、MariaDB	事务、强一致、复杂 JOIN	水平扩展难、海量写入吃力
内存型（In-Memory）	Redis、Memcached	高频读写、缓存、低延迟	容量受内存限制、需持久化方案
时序（Time-Series）	ClickHouse、InfluxDB	时间戳数据聚合、监控指标	不适合通用事务与随机更新
图（Graph）	Neo4j	复杂关系遍历、社交/风控	全图扫描与批量分析较弱
文档（Document）	MongoDB	JSON 文档、灵活 schema、不可变大数据	跨文档事务与 JOIN 较弱
宽列（Wide Column）	Cassandra、Bigtable	海量反规范化数据、分析报表	查询灵活性受限、需精心设计 schema

结合仓库专题的进阶选型路线

本仓库围绕数据库选型提供了更细粒度的配套指南，可作为本文六类框架的延伸阅读：

• 从 OLTP/OLAP 等工作负载维度切入的 how-to-choose-the-right-database.md：OLTP 面向需要强一致性的交易系统，OLAP 面向复杂查询与数据分析，另有全文检索、键值存储、向量嵌入与地理空间等专项；
• 更通俗的数据库类型总览 understanding-database-types.md 与 types-of-databases.md；
• 数据模型层面的 top-6-database-models.md，涵盖 Flat、Hierarchical、Relational、Star Schema、Snowflake、Network 六种模型，其中 Star/Snowflake Schema 是数据仓库 OLAP 场景的建模基础；
• 以具体场景为例的 choose-the-right-database-for-metric-collecting-system.md，演示了如何依据"写负载重、读负载突发"的访问模式，排除通用关系库与通用 NoSQL、最终选择专用时序存储的完整推导过程。

结语：把选型变成一道判断题而非选择题

回到最初的问题——在成百上千种数据库中如何挑选存储架构？本文给出的六类清单已经划定了最粗的边界：常规业务找关系型，极致延迟找内存型，时间戳数据找时序型，复杂关系找图型，文档化不可变数据找文档存储，海量分析找宽列存储。

真正的选型高手不会停留在"哪类数据库"，而会进一步追问工作负载（OLTP/OLAP）、访问模式（写重还是读重、是否突发）、一致性需求与扩展方式。沿着 system-design-101 仓库中 数据库与存储 专题的系列文档逐层深入，你就能把本文的六类框架，变成一套在面试与实战中都能自圆其说的完整选型方法论。