4. 目标数据库选型策略：关系型 vs NoSQL、云原生数据库（如Aurora/TiDB）、成本与性能权衡
目标数据库的选型是迁移架构中最关键的决策点之一。选型错误将直接导致性能不达标、成本失控或架构重构。本章从数据模型匹配度、扩展范式、运维复杂度和总体拥有成本（TCO）四个维度，系统对比关系型数据库、NoSQL 数据库以及云原生数据库的适用场景。
4.1 选型决策框架：从业务特征到数据库特征
在进入具体产品对比之前，需要建立统一的决策坐标系。以下表格列出了选型时必须评估的六个核心维度：
| 评估维度 | 关键问题 | 影响选型方向 |
|---|---|---|
| 数据模型 | 数据结构是否固定？是否存在多对多关系？ | 关系型 vs 文档型 vs 图数据库 |
| 一致性要求 | 业务能否接受最终一致性？是否需要强事务？ | ACID vs BASE |
| 扩展模式 | 读扩展为主还是写扩展为主？预期增长曲线？ | 垂直扩展 vs 水平扩展 |
| 查询模式 | 是否有多维聚合分析？是否依赖 JOIN？ | SQL 引擎 vs 键值/列族查询 |
| 运维能力 | 团队是否有 DBA 储备？是否接受托管服务？ | 自建 vs 云原生托管 |
| 成本约束 | 预算是否包含许可证、存储、跨区域流量？ | 开源 vs 商业 vs 按量付费 |
实践建议：在大型项目中，建议先按业务域拆解，每个子域独立完成上述评估。例如，订单域强依赖事务，优先考虑关系型；日志域高吞吐、无强关联，优先考虑 NoSQL 或时序数据库。切忌“一刀切”选型。
4.2 关系型 vs NoSQL：核心差异与适用边界
关系型数据库（如 MySQL、PostgreSQL）与 NoSQL 数据库（如 MongoDB、Cassandra）并非替代关系，而是互补关系。以下从架构层面梳理其本质差异：
- 存储结构：关系型采用预定义 Schema 的表结构，适合强一致性、复杂关联查询；NoSQL 采用灵活 Schema（文档、键值、列族、图），适合快速迭代、非结构化数据。
- 扩展方式：传统关系型以垂直扩展（升级硬件）为主，水平扩展需引入分库分表中间件；NoSQL 天然支持水平扩展，通过一致性哈希或 Gossip 协议自动分片。
- 事务支持：关系型提供完整的 ACID 事务；NoSQL 多数只保证最终一致性（BASE），部分产品（如 MongoDB 4.0+）开始支持多文档事务，但性能有损耗。
- 查询能力：关系型拥有成熟的 SQL 标准、JOIN、子查询、窗口函数；NoSQL 查询能力受限，通常依赖 MapReduce 或专用 API，复杂聚合需在应用层实现。
选型红线：如果业务核心流程要求跨多个实体的强一致性（如金融转账、库存扣减），必须选择关系型数据库。NoSQL 不适合作为“万能替代品”直接替换关系型核心库。
以下表格列出典型场景的推荐选型：
| 业务场景 | 推荐数据库类型 | 代表产品 | 选型理由 |
|---|---|---|---|
| ERP/财务系统 | 关系型 | Oracle / PostgreSQL | 强事务、复杂报表、严格一致性 |
| 用户行为日志 | NoSQL（列族） | Cassandra / HBase | 高写入吞吐、无固定 Schema、时间范围扫描 |
| 内容管理系统 | NoSQL（文档） | MongoDB | 灵活 Schema、JSON 存储、快速迭代 |
| 社交关系图谱 | NoSQL（图） | Neo4j | 深度关系遍历、最短路径、推荐算法 |
| 实时排行榜 | NoSQL（键值） | Redis | 内存级读写、有序集合、毫秒级响应 |
4.3 云原生数据库：Aurora 与 TiDB 架构解析
云原生数据库是近年数据库选型的重要方向。它们将计算与存储分离，利用云基础设施实现弹性伸缩、高可用和按需付费。本节以 Aurora（AWS 云原生关系型）和 TiDB（开源分布式 HTAP）为代表，分析其架构优势与适用场景。
4.3.1 Amazon Aurora：计算存储分离的极致实践
Aurora 兼容 MySQL/PostgreSQL 协议，但底层采用自研分布式存储引擎。其核心架构特点包括：
- 存储池化：数据自动分片到 6 个副本，跨 3 个可用区，写入只需多数派确认（4/6），延迟低至个位数毫秒。
- 计算弹性：支持只读副本自动扩展，最多 15 个只读节点，故障切换时间通常小于 30 秒。
- 日志即数据库：仅将 Redo Log 发送到存储层，存储层异步回放生成数据页，大幅减少网络 I/O。
4.3.2 TiDB：分布式 HTAP 的统一架构
TiDB 是开源的新一代分布式数据库，原生支持水平扩展和混合事务/分析处理（HTAP）。其架构分为三层：
- TiDB Server：无状态 SQL 层，负责协议兼容、SQL 解析、分布式执行计划生成。
- TiKV：分布式键值存储引擎，基于 Raft 协议保证强一致性，数据自动分片（Region）。
- TiFlash：列式存储引擎，通过 Raft Learner 实时同步 TiKV 数据，提供秒级分析查询。
迁移风险提示：TiDB 虽然兼容 MySQL 协议，但在分区表语法、自增主键行为、大事务限制（单事务不超过 100MB）等方面存在差异。迁移前必须进行 SQL 兼容性扫描，建议使用 TiDB 官方提供的 SQL 审核工具。
以下 SVG 图展示了 Aurora 与 TiDB 在架构层面的核心差异：
4.4 成本与性能权衡：TCO 模型与关键指标
数据库选型最终要落到成本与性能的平衡上。以下从总体拥有成本（TCO）和性能关键指标两个角度给出量化分析框架。
4.4.1 TCO 构成要素
| 成本项 | 自建关系型 | 自建 NoSQL | 云原生（Aurora/TiDB Cloud） |
|---|---|---|---|
| 许可证 | Oracle：高；MySQL/PostgreSQL：免费 | 多数开源免费 | 按量付费，无前期许可证 |
| 基础设施 | 服务器 + 存储 + 网络 + 机房 | 同左，但通常需要更多节点 | 完全托管，无硬件采购 |
| 运维人力 | DBA 团队（备份、监控、升级、故障恢复） | 需要 NoSQL 专项运维能力 | 运维由云厂商承担，减少 60%-80% 人力 |
| 存储成本 | 本地 SSD/HDD，按容量预购 | 同左，但副本数通常更多 | 按实际使用量计费，支持自动压缩 |
| 数据传输 | 内网免费 | 内网免费 | 跨 AZ/Region 流量按量计费 |
4.4.2 性能权衡矩阵
以下表格对比不同数据库类型在关键性能指标上的表现（评分 1-5，5 为最优）：
| 性能指标 | MySQL/PostgreSQL | MongoDB | Aurora | TiDB |
|---|---|---|---|---|
| 单节点读延迟 | 5 | 4 | 5 | 4 |
| 单节点写延迟 | 4 | 5 | 5 | 3 |
| 水平扩展读 | 2（需中间件） | 5 | 4（只读副本） | 5 |
| 水平扩展写 | 1 | 4 | 2 | 5 |
| 复杂 JOIN 性能 | 5 | 1 | 5 | 4 |
| 高并发点查 | 4 | 5 | 5 | 4 |
成本-性能平衡策略：对于大型项目，推荐采用“混合存储架构”。核心交易数据使用 Aurora 或 PostgreSQL 保证强一致性；非核心、高吞吐的日志/埋点数据使用 NoSQL；需要跨库分析的场景引入 TiDB 作为 HTAP 统一查询层。这种架构虽然增加了初期设计复杂度，但能有效降低 30%-50% 的总体成本。
以下 SVG 图展示了混合存储架构下的数据流转与选型边界：
4.5 选型决策清单与避坑指南
在最终确定目标数据库前，建议团队逐项核对以下清单：
- 数据模型匹配度：业务实体间是否存在超过 3 层的嵌套关系？是否依赖外键约束？
- 扩展性验证：未来 3 年数据量预期是否超过 10TB？写入峰值是否超过 10 万 QPS？
- 生态兼容性：现有中间件、ORM 框架、监控工具是否支持目标数据库？
- 迁移工具链：是否有成熟的在线迁移方案？是否支持增量同步和回滚？
- 团队技能储备：团队是否有目标数据库的运维经验？是否需要引入外部专家？
- 成本上限：按 3 年 TCO 计算，目标数据库是否在预算范围内？
常见选型陷阱：
- “NoSQL 更快”的误解：NoSQL 在简单键值查询上确实快，但一旦引入复杂聚合或跨文档事务，性能可能反而不如关系型。
- “云原生自动解决一切”：云原生数据库虽然降低了运维门槛，但 SQL 兼容性、网络延迟、跨区域成本仍需仔细评估。
- “先迁移再优化”：数据库选型错误在迁移后期发现，回滚成本极高。建议在 POC 阶段用真实业务流量压测。