数据库选型的真实取舍
关系型数据库提供强事务、约束校验与灵活的即席查询，缺点是单机写扩展有上限；NoSQL 以水平扩展、模型灵活和高写入吞吐见长，代价通常是放弃跨记录的强事务与部分查询能力。选择取决于三件事：一致性要求有多强、数据模型是否稳定、访问模式是否收敛到主键。很多系统最终采用多模型组合，而不是二选一。
基本信息
| 优先 SQL | 事务与一致性要求高、查询模式多变、数据规模在单实例加副本可覆盖的范围内 |
|---|---|
| 优先 NoSQL | 写入规模大、模式易变、访问以主键或有限范围为主 |
| 组合 | 核心交易用关系型，会话、检索、时序与日志用专用存储 |
| 代价口径 | NoSQL 通常要自己承担一致性校验、二级索引与迁移工具的建设 |
典型使用场景
- 账务与订单：强事务与约束校验是刚需，关系型优先
- 会话与购物车：按主键访问、写入量大、可容忍弱一致，键值存储合适
- 全文检索与日志分析：倒排索引或列式存储在聚合查询上更有优势
- 内容与商品目录：模式易变、读多写少，文档型存储可减少迁移成本
- 时序与指标：按时间写入、按时间窗口聚合，专用时序存储在压缩与降采样上更有优势
场景对照
| 场景 | 倾向 | 理由 |
|---|---|---|
| 资金交易与账务 | 关系型 | 强事务与约束校验 |
| 会话与购物车 | 键值存储 | 按主键访问、写入量大 |
| 检索与日志分析 | 检索引擎/宽列存储 | 倒排或列族访问高效 |
| 混合负载 | 多模型组合 | 各取所长，核心数据保持关系型 |
取舍判断顺序
取舍判断顺序
1. 先问一致性：是否需要多记录/多表原子提交？
→ 需要则优先关系型
2. 再问访问模式：是否 90% 以上按键访问？
→ 是则可考虑键值或宽列
3. 再问查询灵活度：业务是否会提出新的即席查询？
→ 会则关系型或检索引擎更稳
4. 最后算规模：单实例 + 分区 + 只读副本能撑多久？
→ 够用就不要提前引入分布式复杂度使用要点
- 先用关系型验证分区、只读副本与连接池能覆盖到什么规模，再考虑换存储
- 选 NoSQL 前明确访问模式与一致性要求，写清它不支持哪类查询
- 多模型组合要指定唯一权威数据源，避免两套存储各自为政
- 把一致性校验放进常态流程：跨存储的同步要有对账任务与差异处理预案
关系型数据库的扩展手段（分区、只读副本、连接池、读写分离）常被低估；先验证这些手段是否够用，再考虑引入分布式存储。
为“未来可能的规模”提前引入 NoSQL 是常见返工来源：事务能力不足时，业务逻辑要在应用层补齐补偿与对账，复杂度往往超过当初想省下的扩展成本。