#数据库选型与架构权衡

「用什么数据库」是每个系统绕不开的决策。没有最好的数据库，只有最适合当前数据模型、访问模式与团队能力的数据库。本章提供一套可复用的选型框架与架构演进路径。

#选型的五个问题

在对比产品前，先回答：

1. 数据模型：结构化、半结构化还是键值？关系复杂吗？
2. 访问模式：读写比例？点查还是范围扫描？是否需要复杂连接与聚合？
3. 一致性：能接受最终一致吗？还是必须强一致（账务、库存）？
4. 规模与增长：当前数据量、QPS、增长率？是否会超出单机？
5. 团队与运维：团队熟悉什么？能否承担分布式系统的运维成本？

#按数据模型选型

关系型内部的选择：

#OLTP 与 OLAP

HTAP 试图用一套系统兼顾两者（如 TiDB、OceanBase、StarRocks），适合中小规模，但超大规模下 OLTP 与 OLAP 分离（用 CDC 把数据同步到数仓/OLAP）仍是最稳健的架构。

#一致性权衡

工程上并非「一个系统一种一致性」，而是按数据重要性分级：核心交易走强一致，周边数据（缓存、搜索索引、统计）走最终一致。

#架构演进路径

按需逐步演进，不要一步到位：

1. 单机            → 开发、小流量，简单
2. 主从 + 读写分离  → 提升读能力与容灾
3. 加缓存（Redis）  → 扛热点读，降低库压力
4. 索引/归档/分区   → 单库内优化，延缓拆分
5. 分库分表         → 突破单机容量/写入
6. 分布式数据库     → 自动驾驶的弹性扩展（TiDB 等）

每一层都应先测量再升级：加索引解决 80% 的慢查询，缓存解决热点读，只有确证单机瓶颈才考虑分片。

#多语言持久化（Polyglot Persistence）

一个系统用多种数据库各司其职，是常见且合理的做法：

代价是一致性、事务、运维复杂度上升。原则：每种数据只选一个权威来源，跨库用异步同步而非分布式事务。

#决策清单

• 明确了核心数据的一致性要求（强一致 vs 最终一致）？
• 估算过数据量与增长，确认 1~3 年内是否需要分片？
• 选型考虑了团队熟悉度与可运维性？
• 热点读用缓存而非换数据库解决？
• 分析类需求是否应分离到 OLAP，而非拖累主库？
• 每种数据都有唯一权威来源，跨库同步可观测？
• 有回滚/迁移预案，避免被某个产品绑定？

#小结

• 选型从数据模型、访问模式、一致性、规模、团队五个问题出发。
• 关系型仍是多数业务默认；PG 强在复杂查询与扩展，MySQL 强在生态与熟悉度。
• OLTP 与 OLAP 职责分离；HTAP 适合中小规模。
• 架构按「单机 → 主从 → 缓存 → 分区 → 分片 → 分布式」逐步演进，先测量再升级。
• 多语言持久化各司其职，但每类数据只设一个权威来源。