根据访问模式而非行业趋势选择数据库

从工作负载开始，而不是从炒作开始

因为某个数据库“流行”就去选它，像是因为大家都在谈论一款车就去买——却不去考虑你到底需要踏板车、皮卡还是大巴。潮流反映的是别的产品、团队规模、预算和风险承受力下的成功。你的数据库必须契合你的工作负载：你的应用每天实际上在做什么。

我们所说的“工作负载”是什么

工作负载是系统在生产中的真实行为：

• 数据如何写入： 频繁的小更新、大批量插入、追加式事件，还是偶尔的编辑。
• 数据如何读取： 单条记录查找、“最新 N 条”订阅、全文搜索，或大范围扫描。
• 如何被查询： 简单的基于键的读取、多字段过滤、联表、聚合、按时间窗口的报表或地理空间查询。
• 随时间如何变化： 峰值流量、季节性激增、回填以及数据量增长。

这些行为就是你的访问模式——应用触及数据的可重复方式。如果你能清晰描述访问模式，数据库选择就不会那么神秘了。

及早设定正确预期

没有一种方案能通吃。很多成功系统采用混合策略：一个数据库负责事务，另一个负责分析，有时还会单独使用搜索引擎或缓存。这并不是“为了复杂而复杂”——而是承认不同的访问模式受益于不同的存储与查询引擎。

在比较“SQL vs NoSQL”或追逐时髦之前，把你排名前 5–10 的读写写下来。从那里开始，其他都是细节。

“访问模式”到底意味着什么

访问模式是对应用每天如何触及数据的实用描述：它读什么、写什么、多频繁、速度如何以及以何种形态查询。它更关心你用数据做什么（“每分钟按 ID 查 10,000 次订单”或“扫描上个月所有订单来生成报告”），而不是数据本身是什么（“订单”或“用户”）。

读取：三种常见形态

大多数读取流量落在几类可识别的桶里：

• 点查（Point lookups）： “展示订单 #12345” 或 “加载某用户资料”。如果数据库能用上索引或键，这类通常很快。
• 复杂查询： “找出在区域 Y 买过 X 且退货 > 2 次的客户。”这类依赖联表、过滤、排序和良好的查询规划。
• 扫描 / 范围读取： “获取过去 24 小时的所有日志” 或 “列出最近 50 笔交易”。即使只展示了小片段，也可能需要读取大量行/文档。

社交 feed 是混合读取形态的好例子：可能对资料做点查，对“最新帖子”做范围读，对计数做聚合。

写入：插入、摄取与更新

写入模式同样重要：

• 单行插入： 创建订单、添加评论、注册用户。
• 高吞吐量摄取： 连续收集点击事件或应用日志。
• 更新： 更改库存计数、更新订单状态、编辑帖文。

日志常常是“写多、几乎不改”的（大量插入、很少更新）。订单通常是“先写入再更新”（创建后状态变更）。

混合工作负载（以及为何棘手）

许多产品想把所有需求都放在一个系统里：为应用提供快速点查、为客服提供复杂查询、为分析提供大规模扫描。一个数据库可以处理某些混合场景，但某些组合会相互冲突——例如，重度分析扫描会拖慢驱动结账或 feed 的低延迟小查询。

当你能清楚命名访问模式时，就能根据真实行为而不是流行度评估数据库。

需要提前识别的常见工作负载类型

在对比数据库品牌前，先明确你实际服务的工作负载。大多数产品并非“单一工作负载”——而是几个共存（有时互相竞争）的不同工作负载。早期把分类做对，可以避免把数据库强行放到它不擅长的岗位上。

OLTP（联机事务处理）

OLTP 是大多数应用的日常节奏：许多小型读写、并发用户众多、请求需要快速完成。

想象场景：“更新购物车”、“创建订单”、“更改地址”、“检查库存”。这些操作短小、有针对性，并且对正确性敏感。如果一次支付被记录却又消失，或两个用户拿到同一座位，后果严重。

OLTP 通常倾向于能很好处理高并发并提供事务与数据完整性保证的系统。

分析 / OLAP（报表与聚合）

分析改变了工作的形态：查询更少，但每次触及的数据更多。

想象场景：“上季度各地区营收”、“渠道转化”、“每类热销产品”、“日活趋势”。这些查询常常扫描大量行、group、聚合并排序。延迟期望可以更宽松（几秒可能没问题），但重度扫描的成本会显著——尤其当仪表盘全天运行时。

如果尝试在驱动结账的同一系统上运行 OLAP 风格扫描，通常会导致其中一个受影响。

时序与日志

时序与日志通常是追加为主：新事件不断到达，查询通常按时间范围进行。

想象场景：指标、点击流、设备遥测、审计日志。常见需求包括保留策略（删除/过期旧数据）、汇总（保留原始事件 7 天、聚合 12 个月）以及在峰值时的快速写入。

这个工作负载更关注高效摄取大量带时间戳的记录，并随时间使存储可预测，而不是复杂联表。

搜索工作负载

搜索不仅仅是“找行”。它是文本匹配、相关度排序、部分匹配与用户友好过滤。

想象场景：按关键词搜索商品、按短语查找工单、按分面（品牌、价格范围、颜色）过滤并按“最佳匹配”排序。这些通常需要专门的索引与查询能力，通用数据库可以近似但很少卓越。

如果搜索是核心产品功能，就应从一开始把它视为独立的工作负载，而不是“以后再加”的细节。

性能需求：延迟、吞吐量与突发流量

性能不是一个数字。两种都被称为“快”的数据库，用户与运维体验可能截然不同。要做出正确选择，请把人感知的东西（延迟）和系统必须持续承受的压力（吞吐量）区分开，然后用突发流量来检验假设。

延迟 vs 吞吐量：用户感觉到的 vs 系统能处理的

延迟 是单次请求的耗时——“点了按钮，得到结果”。用户直接感知延迟。

吞吐量 是每秒能处理多少请求——系统能承受的流量总量。

有的数据库通过批处理高效完成工作以获得高吞吐，但单次请求可能有明显延迟；另一种优化点读很快，但当大量写入同时到达时会吃力。

为什么最慢的 1% 很重要（P99）

平均延迟会掩盖痛点。如果 99 次请求在 50 ms 完成，而 1 次花 2 秒，平均 看起来不错——但那 1% 会成为“这个应用很慢”的时刻。

这就是 P99 延迟 的意义：最慢 1% 请求所需时间。对面向用户的关键功能（结账、登录、搜索结果），P99 往往决定数据库设计是否让人感到可靠。

峰值 vs 平均负载：为突发流量设计

大多数系统不是在平均流量下失败，而是在峰值时失败：营销邮件、突发新闻、发薪日、月末报表等。

突发流量会改变数据库的讨论：

• 在 200 writes/sec 下还行的索引，在 2,000 writes/sec 下可能成为瓶颈。
• 后台工作（压缩、vacuum、复制）会与用户查询竞争，恰好在你最不能承受的时候发生。

缓存如何改变读取形态

缓存可以让读多的工作负载看起来更小——直到发生未命中或缓存清空。

如果大多数读取命中缓存，你的数据库可能主要负责写入与偶发昂贵读取。这会倾向于不同的选择，而不是所有读取都落库的场景。要为“冷缓存”事件和未命中尾延迟做计划，而不是只看理想路径。

正确性、可用性与地域约束

选择数据库不仅关乎速度，还关乎哪些可以出错、能容忍多少停机，以及用户分布在何处。

正确性：哪些数据绝对不能错

先明确哪些数据必须每次都正确。支付、账户余额、库存计数是典型例子。如果顾客被重复扣款或出现超卖，代价不仅是性能问题——还会带来退款、支持工单和信任损失。

对于这些关键数据，通常希望强一致性：写入被确认后才视为完成，读者不应看到半成品更新。代价是更少的灵活性：某些扩展策略更难，跨区写入可能更慢。

可用性：停机成本是多少

接着，决定如果数据库不可用 5 分钟会发生什么。

如果停机会导致“订单停止、收入中断”，你需要更高的可用性：自动故障转移、良好备份和无需下线的维护计划。如果停机会只影响“内部仪表盘延迟”，你可以接受更简单的方案。

更高的可用性通常提高成本与运维复杂度（更多副本、更密集的监控、更小心的升级）。关键是把投入与业务影响匹配起来。

地域：单区 vs 多区用户

如果用户主要集中在一个区域，把数据放在一个地方通常更便宜且更快。如果用户分布在全球或有数据驻留合规要求，你可能需要多区域复制。

多区域设计提升用户体验与弹性，但也会带来艰难选择：允许略微陈旧的读取，还是接受更慢的写入以保持同步？正确答案取决于你的工作负载能容忍多少陈旧性。

数据模型与查询形态：隐藏的决定因素

大多数“数据库争论”其实是围绕查询形态。如果你知道应用必须提出哪些问题——联表、聚合、过滤、时间窗——通常能很快缩小数据库选项。

查询形态驱动数据模型

当你需要跨多个实体灵活过滤与联表（客户 → 订单 → 商品），且需求会演进时，关系模型很有优势。若产品需要临时报表（“显示同时买过 X 且退过 Y 的客户”），SQL 与联表在长期会更简单。

如果你的查询可预测且主要按主键读取（“按 user_id 获取资料”），文档或键值模型通常表现良好——通过把常读数据聚在一起。但代价是可能需要复制数据以避免联表，这会把复杂性转移到写入和更新上。

索引：真正的性能契约

索引就是你告诉数据库“这些是我的访问模式”的方式。一个在 mockup 看起来不错的查询，如果在非索引字段上过滤或排序，就会变慢。

一个实用规则：每个频繁的过滤、排序或联表键都应该有索引计划。但索引不是免费的：它们占用存储并增加写入负担。

写放大：当“快速写入”变慢时

“快速写入”的宣称常常忽略写放大——由二级索引、压缩、复制或去重数据更新引起的额外工作。为了优化读取而增加索引或复制文档的设计可能悄无声息地把高写入工作负载变成瓶颈。

模式灵活性 vs 可维护性

无模式并不等于无结构。灵活模式加速早期迭代，但如果没有约定，会产生字段不一致、难以调试的查询和昂贵的迁移。当你预计会有多个团队、众多功能或长期保留时，更严格的模式与清晰约束往往能降低总体成本——即便一开始看起来较慢。

运维与成本：潮流忽略的部分

因为某个数据库流行而选择它，常常会在运营和账单的灰色地带付出代价：维持运行、保证安全、每月付款。两种数据库可能满足相同功能，但在运维工作量和总成本上差别巨大。

运维工作量本身就是一个特性

早点问清楚谁会在凌晨 2 点操作这个系统。备份、时间点恢复、升级、打补丁、演练故障恢复与监控不是“以后再说”的任务——它们决定了风险与人员配置。

托管服务可以减少重复劳动，但不会完全消除。一些系统需要定期压缩、精细调优或深厚专业知识才能避免性能下降。另一些让模式变更困难，或需要专门的迁移流程。如果团队小，一个易于运维的数据库可能比纸面上“完美”的选择更好。

明白究竟什么驱动成本

数据库成本通常来自：

• 存储（尤其当你保留多个副本、索引或长时间保留数据时）
• 计算（基础负载 + 峰值预留）
• I/O（随机读写、日志量、压缩）
• 网络出站（跨区复制、分析导出、备份）

对写密集且带二级索引的访问模式，即使数据集小也可能放大 I/O 与存储成本。

锁定、可移植性与风险

专有查询语言、独特一致性特性或无服务器“魔法”可以加快交付，但也可能限制未来迁移。考虑是否能导出数据、在本地做测试或在不改写应用的前提下更换提供商。

安全与合规基础

至少确认传输/静态加密、密钥管理、审计、访问控制与保留策略。合规需求常常决定某方案是“可行”还是“不可接受”，无论它有多么时髦。

将模式匹配到数据库家族

一旦描述清楚访问模式（你读什么、写什么、多频繁、在何种突发下），“正确”的数据库家族通常会变得清晰。目标不是挑最流行的工具——而是选择在你的工作负载下保持正确性的最简单系统。

关系型（SQL）数据库：最简单且正确的选择

当你需要强一致性、明确关系与可靠事务时（订单、支付、库存、权限、调度），选择关系型数据库。如果你经常需要跨实体查询（“在 30 天内有未结发票的客户”）或强制约束（唯一邮箱、外键），SQL 往往能减少应用端复杂度。

一个常用启发式：如果团队准备在代码里重写联表、约束与事务，通常应选择关系型数据库。

文档型数据库：结构灵活，减少联表

当你大多读写整个可变结构的对象（用户资料、内容页面、带可选字段的产品目录或设置）时，文档数据库最合适。如果典型查询是“按 user_id 获取资料”并局部更新，文档能把常用数据放在一起。

当查询变得高度关系化（跨文档多实体查询）或需要多实体事务保证时要小心。

键值存储：极低延迟的查找与短期数据

键值系统适合缓存、会话、速率限制、特性开关与短期状态，访问模式是“按键 get/set”且延迟关键。它们通常作为辅助组件，而非主记录存储。

如果用于持久化业务数据，要考虑驱逐、重启或复制延迟时会发生什么。

列式仓库：重度聚合与商业智能

对于分析——仪表盘、留存、营收汇总、需要对大量历史做 group-by 的查询——列式/仓库系统胜出，因为它们针对扫描与聚合做了优化。

实用拆分：把 OLTP 写入保留在主库，定期把数据送入仓库做报表。这样可以避免 BI 工作负载拖慢面向客户的查询。

真实案例：一个产品使用多个数据库

许多成功产品并不是“选一个数据库”。它们把每个主要访问模式映射到最简单的存储上，即便这意味着并行使用两到三个数据库。

示例 1：电商 — 订单、商品搜索与分析

在线商店常见三类截然不同的工作负载：

• 订单与支付（OLTP）： 大量小读写、严格正确性、事务更新（库存、订单状态）。关系型数据库常见于此。
• 目录搜索与过滤： 用户期望快速文本搜索、分面、容错与相关度排序。通常用搜索引擎比把 SQL 强行当搜索引擎用更合适。
• 业务分析： “活动后转化如何变化？”需要跨时间的大量扫描与聚合。列式仓库或分析数据库可用于此，避免影响结账性能。

产品感觉是统一的，但存储按访问模式专业化。

示例 2：SaaS 应用 — 多租户、报表与审计日志

B2B SaaS 工具可能把核心实体（项目、发票、工单）放在事务数据库，但仍需处理：

• 面向租户的查询： 每租户索引与可预测查询形态以保持性能一致性。
• 报表： 长时间运行、聚合密集查询不应与交互请求竞争，常被外包到副本、仓库或单独的报表存储。
• 审计日志： 追加为主、高吞吐且有保留规则。日志优化存储（或对象存储 + 查询层）往往比把主 OLTP 数据库撑大更便宜、更容易。

示例 3：物联网/日志 — 摄取、保留与仪表盘

IoT 平台摄取突发遥测，然后按时间窗口在仪表盘中读取。

常见拆分：近期数据用快速摄取存储，长期用更便宜的长期存储保留，聚合用分析引擎。

要点：当访问模式分歧时，不同组件可以（也应当）使用不同数据库。

你选错数据库的红旗

数据库不匹配通常会表现为一堆看似“小”的补救措施。如果团队更多时间在和数据库“搏斗”而不是构建产品功能，要注意——这通常是访问模式的问题，而不是调优问题。

表明你在用补丁代替适配的症状

常见警告信号包括：

• 应用层有太多变通（把一切都缓存、写多个版本的同一查询、为性能而去范式化）
• 持续重建索引或索引频繁变动，因为新查询不断到来，旧查询就崩溃
• 看起来简单的查询性能忽然大幅波动，且难以解释
• 常规事件导致故障——部署、批处理、回填或月末峰值

如果数据库需要英雄式的努力来支撑日常业务，说明工作负载与数据库家族可能不匹配。

基于潮流的选择会在稍后付出高昂代价

因为流行而选库，代价常常在后期到来：

• 你不得不自己实现缺失的特性（联表、约束、迁移、审计、报表），这些自制代码难以拆解
• 因为迁移风险大，迁移被一再推迟，“临时”方案变成永久
• 数据形态为了适应工具而漂移，使未来分析、合规与集成变难

账单会在规模上升或需求变化时到来，而唯一现实的修复往往是痛苦的重构。

早期预警指标

你不需要完美的可观测性，但需要几个信号：

• 查询延迟分位数（p95/p99），而不仅仅是平均值
• 锁竞争 / 死锁（或等价的并发冲突）
• 连接池饱和与超时
• 复制延迟与读后写可见性问题
• 存储增长率与索引占比

记录什么以免重蹈覆辙

写下顶级访问模式（读/写、关键查询、峰值速率）、数据量假设与“不可谈判项”（一致性、可用性、地域约束）。附上仪表盘链接和最差查询示例。这个简短记录让未来决策更快，也能清楚指出何时数据库已不再匹配现实。

可复用的实际决策清单

把选数据库当成需求收集而非流行竞赛，用这个清单把“需要可扩展”模糊表述转成具体对比输入。

1) 用高杠杆问题明确工作负载

先用白话回答，再尽量填入数字：

• 主要查询： 应用必须完成的前 3–5 件事（例如，“按邮箱拿用户”、“列出最近 50 个订单”、“按关键字搜索”、“按日聚合营收”）？
• 写入速率： 当前和峰值每秒写入多少？写入是小且频繁还是批量大？
• 数据大小与增长： 当前数据集大小、每月增长、保留规则（永久、90 天、归档？）
• SLA： 目标 p95/p99 延迟、可用性、恢复期望（RTO/RPO），以及数据略微陈旧可接受的程度。

2) 用简单打分矩阵比较候选项

做一页纸的表格，左侧列出标准，顶部列出候选数据库。把每个标准标为 必须 或 可选，然后给每个数据库打分（例如 0–2）。

至少要包含：查询匹配度、扩展方式、一致性需求、运维工作量、生态/工具链与成本可预测性。

3) 做小规模 PoC

用代表性数据和真实查询来测试，而不是玩具示例。重现“前 5 个查询”和现实的写入模式（包括峰值）。

如果你需要快速验证产品想法，像 Koder.ai 这样的 vibe-coding 环境能帮你快速搭出工作应用并尽早验证访问模式：生成 React 前端和 Go + PostgreSQL 后端，建模几个真实端点，并在承诺长期架构前测量“前 5 个查询”的表现。能导出源码并控制模式与迁移也能帮助避免把自己套死。

4) 在测试前定义成功标准

事先写明“通过”意味着什么：延迟目标、可接受的错误率、所需运维步骤（备份、模式变更）以及预估在预期使用下的月成本。如果候选项在 PoC 中达不到必须项，就尽早淘汰并继续下一候选。

如何在不搞过度工程的情况下面向未来

面向未来不是在第一天就选最“可扩展”的数据库，而是做出让你在访问模式变化时仍保持灵活的明智选择。

从满足今日需求的最简单系统开始

如果工作负载主要是事务性读写且查询直白，关系型数据库通常是最快上手并可靠的路径。目标是有信心发布：可预测性能、清晰的正确性保证和团队已熟悉的工具链。

这里的“面向未来”是避免早期做出不可逆的承诺——比如在未证明需要前就采用专门化存储并承担其权衡。

为变化而设计：边界、模块化访问与迁移

构建明确的数据访问层（或服务边界），使应用其余部分不依赖数据库特有的怪癖。把查询逻辑集中、定义契约（输入/输出），并把模式变更视作常规开发的一部分。

一些实用习惯帮助未来迁移：

• 优先使用可增量的模式变更（新列/表）而不是危险的大改写
• 分批回填，使变更在部署期间兼容新旧代码
• 记录并衡量查询模式，以便早期发现漂移

当访问模式分歧时拆分工作负载

许多产品最终需要两条路径：面向日常事务的 OLTP 与面向报表/实验的分析平台。当分析查询开始影响生产延迟，或需要不同的保留/分区策略时就应拆分。

为保持一致，标准化事件/数据定义、自动化管道，并在系统间对账（日汇总等）以防“真相”碎片化。

如果你想要具体的下一步，搭建一个轻量的迁移计划模板供团队复用：/blog/database-migration-checklist.