数据库选型决策框架

一句话定义

数据库选型是把「负载形状、一致性要求、规模预算、团队运维能力」四个变量代入一张决策矩阵，为每个数据域匹配引擎——而不是为整个系统挑一个「最好的数据库」。

为什么重要

选型错误的纠错成本极高（数据迁移 + 双写 + 回滚方案），是少数值得花一周论证的架构决策。
Polyglot persistence（多语言持久化）已是常态：一个业务同时用关系库、缓存、搜索、时序并不奢侈，关键是分工依据清晰。
大部分「该不该换数据库」的争论，本质是没把负载形状先写清楚——本框架让讨论有共同的锚点。

前置知识

kp-027（NoSQL 与 NewSQL 图谱）；建议完成 kp-019、kp-024。

核心概念

负载四问：读写比例？单请求访问模式（点查/范围/聚合/多跳）？峰值 QPS 与数据量？增长斜率？
一致性档位：强一致（事务必须）→ 读己之写 → 最终一致（kp-025 谱系）。
决策矩阵维度：数据模型契合、扩展路径、运维成熟度（备份/监控/人才池）、许可与成本、生态（ORM/BI 工具链）。
TCO（总拥有成本）：许可 + 机器 + 人力 + 故障损失，而不是只看License 或机器价。
避险原则：默认成熟引擎（关系库）起步，特化引擎按数据域引入，引入前必须有「为什么现有引擎做不到」的论证。

原理与机制

决策树的第一层是「有没有多行事务与复杂一致性」：有 → 关系库或 NewSQL；没有 → 进入负载形状分支。第二层按访问模式分流：纳秒级点查与热点缓存 → KV（Redis）；文档级整体读、模式异构 → 文档库；海量写 + 范围扫描 → 宽列/时序；多跳关系遍历 → 图库；全文检索 → 倒排引擎；大规模聚合分析 → 列存分析库。第三层做规模与运维修正：数据量 < 单机上限（TB 级）时不要为「未来的分布式」提前付费——分库分表（kp-024）的复杂度只有在真需要时才引入。矩阵打分的陷阱是「维度等权」：一致性要求是淘汰项（gate）而非加分项，资金域不满足强一致的候选直接出局，而不是扣两分继续比。最后以「退化测试」收尾：模拟峰值 3 倍流量与主库宕机，各候选的降级行为差异往往是决策的最后一块砝码。

实例或案例

社交 App 选型实录：用户与关系链（强一致、事务）→ PostgreSQL；动态 feed 投递（海量写 + 时间线范围读）→ 宽列/Redis Timeline；全文搜索 → 倒排引擎；计数与排行榜 → Redis ZSet；审计与风控分析 → 列存数仓。评审记录里每个数据域写清「四问」答案与淘汰理由——半年后新增「附近的人」需求时，按同一框架补一个地理索引引擎，而不是把 PostgreSQL 硬改成 GIS 库。

常见误区

为简历选型：引入团队无人驾驭的新引擎，运维成熟度项直接归零。
用压测数据横比引擎：不同引擎的语义不同（一致性档位、持久化保证），跑分同等条件本身不成立。
忽视退出成本：未验证「数据如何迁出」就签约，等于把架构抵押给供应商。

自测题

为什么一致性要求是「淘汰项」而不是加权项？答：一致性违背（如资金错账）是正确性问题，无法用其他维度优势补偿；先淘汰不及格候选，再对幸存者比性能与成本。
单机容量足够时为什么要警惕「分布式税」？答：分区、共识、跨节点事务带来延迟、运维与心智成本（kp-018/kp-024/kp-026），规模未到时支付这笔税是纯损失。

公式或模型

决策评分：Score = Σ w_i × s_i，但一致性/合规维度作为 gate（0/1），不进加权和。容量预估：磁盘 ≈ 数据量 × (1 + 索引膨胀率 0.3~1) × 副本数 × 安全余量 1.5；QPS 预算 = 单机基准 × 节点数 × 利用率上限 0.6。

图示

选型第一刀：一致性门槛淘汰后，再按访问模式在家族图谱内分流

直观类比

选型像组建球队：先定「规则等级」（一致性门槛，像联赛准入），再看「打法」（访问模式）挑位置球员，最后才比较球员身价（成本）；第一轮就把不合格者请出场，而不是让守门员去跟前锋比进球数。

与其他知识点的关系

kp-027 提供候选池；kp-025/kp-024/kp-026 解释「分布式税」的构成；kp-031/kp-032 是矩阵中「运维成熟度」维度的展开；kp-029 的反模式清理是压测可比的前提。

前置知识点

相关知识点