18.1 用工作负载与不变量做数据系统选型

技术选型不是给 PostgreSQL、Redis、Kafka、ClickHouse 排名，而是把业务承诺翻译成可以验证的存储约束。没有工作负载、故障模型和团队能力的“全景对比表”，很快就会过时。

第一层：数据的权威事实是什么

先标出 system of record：哪个系统中的状态可以裁决争议、重建派生视图，并接受审计。

订单数据库       -> 权威交易事实
Outbox/事件日志   -> 已提交变化的传播记录
搜索索引          -> 可重建查询投影
Redis 缓存        -> 可丢失加速层
分析仓库          -> 批量/流式生成的分析副本

若所有系统都被称为“主库”，冲突时就没有裁判。缓存、搜索和分析系统可以非常重要，但通常不应在没有明确协议时反向覆盖交易事实。

第二层：写出不变量与事务边界

把抽象的“一致性很重要”改成具体句子：

• 同一优惠券最多成功核销一次；
• 余额不能因为并发扣款小于零；
• 创建订单与写入待发布的 OrderCreated outbox 记录必须原子；对外发送可在提交后重试；
• 搜索结果允许落后权威库 30 秒；
• 推荐统计可重算，允许重复事件但不能永久丢失。

然后标出每条不变量涉及单行、单分区、多行还是跨系统。数据模型应让最高价值不变量尽量落在数据库原生原子边界内。

第三层：描述工作负载分布，不写虚假的“典型数字”

至少收集：

维度	要测什么
读写比例	平均、峰值和突发持续时间
访问范围	点查、范围、全表扫描、多跳图遍历
数据分布	key 基数、热点、租户偏斜、时间局部性
事务	每次读写行数、跨分区比例、冲突率
延迟	p50/p95/p99 与超时预算，不只平均值
增长	原始数据、索引、版本、日志与副本放大
恢复	RPO、RTO、全量恢复时间与回放速度

“OLTP 每次几十行”“OLAP 必然扫描十亿行”可以做直觉，却不能作为容量结论。选型输入应来自生产 trace、代表性样本或明确假设。

OLTP、OLAP 与流处理是不同执行目标

OLTP

短事务、选择性点查和小范围更新，优先关注约束、隔离、锁冲突、日志提交和索引维护。行式存储与 B+ 树常适合这类访问，但不是唯一实现。

OLAP

大范围扫描、投影、过滤、连接和聚合，优先关注列裁剪、分区 pruning、压缩、向量化、并行度和 spill。查询可能读取权威库快照、分析副本、湖中表或本地文件。

流处理

持续消费无界事件，根据 event time、watermark 和 state 更新结果。关键问题是乱序、迟到数据、checkpoint、状态恢复和 sink 幂等，不应仅归类成“更实时的 OLAP”。

HTAP

HTAP 希望在较短时效内同时服务交易和分析，但实现可能是同引擎双布局、列式副本、日志驱动投影或资源隔离。它不意味着同一份物理数据、同一资源池上所有查询都互不影响。

用能力矩阵，而不是品牌矩阵

需求	首选能力	常见补充
强约束与跨实体事务	关系/事务数据库	Outbox、只读副本
主键低延迟与简单原子操作	KV / 内存数据结构	权威库、持久化与热键治理
任意全文检索与相关性	倒排索引系统	CDC 同步、重建流程
大规模分析扫描	列式分析系统/湖仓	ETL/ELT、数据质量
多跳路径	图数据库或图计算	权威关系数据投影
可重放事件传播	持久日志	Schema registry、幂等 sink

先选能力，再评估产品。产品评估还要固定版本、许可、托管方式、区域可用性和团队经验。

一套最小可行选型流程

1. 写 SLO、不变量、RPO/RTO 和合规边界；
2. 画读写路径与权威数据流；
3. 找当前系统的可证瓶颈，先排除查询/索引/容量配置问题；
4. 选两到三个候选，构造代表性数据与热点；
5. 在目标可靠性配置下压测，注入慢节点、重启和网络故障；
6. 测备份恢复、扩容、升级和数据导出，不只测 steady-state TPS；
7. 写 ADR，记录为什么选、哪些假设成立、何时重新评估。

例如一次假设的评估要求：同一优惠券不可重复核销，p99 小于 80 ms，已确认写入的 RPO 为 0。候选 A 平均 5 ms，却允许确认后丢写；候选 B 平均 12 ms，但通过所需故障模型下的持久化和并发检查。A 应先因硬约束出局，不能用更高的性能分把数据丢失平均掉。随后再对 B 的 p99、超时和恢复时间做验收，这些是假设门槛而非产品测评结果。

测试还应把失败与重试计入请求总体，固定数据规模、热点分布、并发和确认配置；只统计成功且命中缓存的请求，会得到一张很漂亮但不能指导容量的曲线。

选型失败的常见信号

• 为了一条报表引入新数据库，却没有数据同步负责人；
• 基准只测空表和均匀随机 key，生产却有大租户热点；
• 声称 exactly-once，但外部副作用没有幂等键；
• 只算机器价格，不算备份、跨区流量、值班和迁移；
• 没有退出方案，数据只能通过私有 API 慢慢导出；
• 选择“未来规模”系统，却没有当前规模下的复杂度预算。

本节检查点

• 能标出权威状态与所有可重建派生状态。
• 能把业务正确性写成明确不变量和原子边界。
• 能用分布、尾延迟和故障恢复评价系统，而不是品牌印象。

下一节把选型落实为可演进架构：缓存、搜索、分析副本怎样围绕权威数据库构建，又怎样安全迁移和退出。