# PostgreSQL 迁移到 MongoDB 评估会议报告 ## 会议主题 评估从 PostgreSQL 迁移到 MongoDB 的方案 ## 结论摘要 **不建议将 PostgreSQL 整体全量替换为 MongoDB。** 本次评估一致认为，更合理的方向是： - **采用混合架构，而非全量替换** - **按业务域渐进迁移，而非一次性迁移** - **将强事务核心域继续保留在 PostgreSQL** - **将文档型、聚合读取为主、结构变化快的业务域迁往 MongoDB** - **通过 Outbox / CDC / 事件总线完成跨库同步** - **分析与报表仍应进入数仓 / Lakehouse / BI 体系，而不是依赖 MongoDB 替代** 换句话说，这不是一个单纯的“数据库升级”项目，而是一个涉及： - 业务域重划分 - 数据模型重构 - 一致性边界重定义 - 平台能力扩展 - 运维与治理体系升级 的系统工程。 --- ## 一、为什么不建议全量迁移 ### 1. PostgreSQL 与 MongoDB 适用问题不同 PostgreSQL 更适合： - 强事务一致性 - 多表关联 - 复杂约束 - 核心交易链路 - SQL 报表与审计 MongoDB 更适合： - 文档型聚合对象 - 结构变化快的数据 - 单对象整体读写 - 弱事务或单聚合事务 - 快速迭代和灵活 schema 演进 因此两者不是简单替代关系，而是**分工关系**。 ### 2. 全量迁移风险过于集中 全量迁移会同时带来： - 应用层改造 - 数据模型重建 - 查询逻辑重写 - 报表链路重做 - 运维体系更新 - 数据同步与双跑复杂度增加 - 回滚难度显著上升 ### 3. 很多问题不一定是 PostgreSQL 本身导致 团队需要先验证当前痛点是否确实由数据库选型导致，而不是： - 领域建模不合理 - SQL/索引设计欠佳 - 缓存策略不当 - 服务边界不清晰 - 报表与在线库职责混淆 如果根因不是数据库，迁移不会解决问题，反而会放大问题。 --- ## 二、推荐的总体方向：混合架构 + 渐进迁移 ### 推荐架构分工 #### 保留在 PostgreSQL 的业务域 适合保留在 PostgreSQL： - 订单核心链路 - 支付 - 库存扣减 - 账务/清结算/总账 - 审计主链路 - 强主数据治理场景 - 监管报送源数据 这些场景的共同特点： - 强一致 - 高并发事务 - 复杂约束 - 审计和可追溯性要求高 #### 优先考虑迁往 MongoDB 的业务域 适合优先迁移到 MongoDB： - 用户画像 / Customer 360 - 商品目录 / CMS / 内容对象 - 配置中心 / 规则引擎 / 动态表单 - 工单 / Case / 协作对象 - IoT 设备状态快照 / 数字孪生视图 这些场景的共同特点： - 以单个业务对象整体读取为主 - 结构变化频繁 - 属性差异较大 - 聚合型文档模型更自然 ### 推荐集成方式 跨 PostgreSQL 与 MongoDB 的同步，不建议业务应用直接双写，推荐： - **Outbox 模式**：核心事务域优先 - **CDC**：非核心同步或平台统一同步能力 - **消息总线（如 Kafka）**：实现事件驱动的异步投影 ### 推荐分析链路 - MongoDB 负责在线对象主存 - PostgreSQL 继续承担强事务核心 - 报表与 BI 分析统一进入数仓 / Lakehouse / OLAP 体系 --- ## 三、业务价值判断 迁移只有在满足以下前提时才可能有明显 ROI： ### 高价值迁移信号 - 数据模型变化频繁 - 不同客户/品类/国家/设备类型字段差异大 - 一个对象需跨多张表拼装 - PostgreSQL 中已经大量使用 JSONB 作为“逃逸阀” - 产品迭代速度比关系约束更重要 - 多区域部署/水平扩展是明确业务目标 - 当前 PostgreSQL 已成为研发效率或扩展能力瓶颈 ### 不宜迁移的信号 - 核心系统高度依赖强事务 - 多表 Join、约束、SQL 报表是核心能力 - 财务/监管/审计要求高 - BI 团队高度依赖 SQL 自助分析 - 当前问题其实可通过 PostgreSQL 优化解决 ### 业务上最现实的结论 本次会议认为，**最具可行性的商业方案通常不是“全量迁移”，而是“局部迁移 / 混合架构”。** --- ## 四、架构设计要点 ### 1. 按聚合根建模，而不是照搬关系模型 MongoDB 建模应围绕“业务对象整体读写”展开，而不是把关系表直接翻译成多个集合。 原则： - 经常一起读取、生命周期一致的数据适合嵌入 - 无限增长或独立查询频繁的明细应拆分到子集合 - 保留摘要在主文档，明细异步归并 ### 2. 核心是聚合边界划分 会议明确指出，迁移成功与否不取决于搬迁工具，而取决于： - 聚合边界是否划分正确 - 哪些字段嵌入 - 哪些明细拆分 - 一致性在哪一层保证 - 分片键是否合理 ### 3. Schema 灵活不等于无需治理 MongoDB 仍需建立： - `schemaVersion` - JSON Schema / validator - 字段命名规范 - 版本迁移策略 - 数据字典与字段 owner - 索引生命周期管理 否则会造成长期数据结构漂移和治理失控。 --- ## 五、一致性与事务边界 ### MongoDB 适用的一致性模式 适合 MongoDB 的场景通常满足： - 单文档原子更新足够 - 单个聚合对象内可以封装一致性需求 - 跨聚合可接受最终一致 - 可通过事件驱动、补偿、重试来解决 ### 应保留在 PostgreSQL 的一致性场景 以下场景更应继续使用 PostgreSQL： - 订单创建 + 扣库存 + 支付确认 - 用户余额变更 + 流水审计 - 优惠核销 + 对账 - 强隔离、强并发控制场景 ### 本次会议一致意见 **MongoDB 可以支持事务，但不应把“支持多文档事务”作为主设计策略。** 最佳做法是： - 强一致核心放 PostgreSQL - 聚合内原子更新放 MongoDB - 跨系统同步走事件驱动 --- ## 六、运维与平台实施结论 从 DevOps 角度，本项目不是简单数据库切换，而是平台能力升级。 ### 需要新增的平台能力 - MongoDB 标准化部署能力 - 高可用与故障切换 runbook - 备份恢复与恢复演练 - 迁移与回填工具链 - CDC / Outbox 基础设施 - 双跑期监控与差异比对 - MongoDB 指标体系与告警体系 - 数据库变更 CI/CD 流程（索引、validator、集合、分片配置） ### 运维风险重点 - 双库并存时期故障面扩大 - 故障定位链路变长 - 分片键选错后难以修正 - 索引膨胀与写放大 - 回填与切流影响线上稳定性 - 恢复方案若未演练，生产风险极高 ### DevOps 核心判断 如果团队目前尚不具备成熟 MongoDB 平台能力，**不适合直接大规模生产迁移**，应先补齐平台能力，再做小范围试点。 --- ## 七、实施路线建议 ### Phase 1：补齐评估与平台基础能力 先完成： - 业务域拆分 - 一致性清单 - 查询画像与索引设计 - 候选文档模型设计 - 备份恢复方案 - 监控告警方案 - 安全与合规方案 - CDC / Outbox 能力准备 - CI/CD 数据库变更能力 ### Phase 2：选择单一低风险业务域做 PoC 优先候选： 1. 配置中心 2. CMS / 内容对象 3. 商品目录 4. 用户画像 PoC 要验证： - 文档模型是否真正降低复杂度 - 性能是否优于现状 - schema 演进是否更顺畅 - 运维、备份、监控、恢复是否可控 ### Phase 3：生产灰度迁移 推荐步骤： 1. 全量回填 2. 增量 CDC / Outbox 同步 3. 双读比对 4. 按租户/业务域/区域灰度切流 5. 实时监控差异率与延迟 6. 完成回滚演练 ### Phase 4：扩大迁移范围 仅在以下条件满足后推进下一个业务域： - 差异率受控 - P95/P99 达标 - 备份恢复已演练 - 回滚路径可执行 - 运维人力和平台能力可承载 --- ## 八、迁移前必须补齐的关键数据 会议认为，在做最终决策前，必须量化以下指标： ### 1. PostgreSQL 当前瓶颈基线 - P95/P99 延迟 - CPU / IOPS / 存储增长趋势 - 慢查询占比 - 扩容频率与成本 - 高峰期稳定性 ### 2. 研发效率基线 - 过去 12 个月 schema 变更次数 - 每次变更 lead time - 因模型变更造成的延期次数 - 相关人天成本 ### 3. 业务增长预测 - 数据对象增长率 - 字段增长率 - 新品类/新租户/新国家扩张速度 - 峰值流量预测 ### 4. 一致性分级清单 - 哪些流程必须强一致 - 哪些流程允许最终一致 - 一致性失败的业务损失金额 ### 5. 报表与合规改造成本 - 依赖 PostgreSQL 的报表数量 - BI/ETL 改造工作量 - 合规、审计、删除权影响评估 ### 6. 迁移 TCO - 一次性改造成本 - 双跑期成本 - 培训成本 - 平台建设成本 - 故障与回滚风险准备金 --- ## 九、成功标准建议 建议在迁移前定义清晰的成功指标，并建立基线值。 ### 业务结果指标 - 新功能交付周期缩短 X% - 新品类/新客户定制上线时间缩短 X% - 海外访问延迟下降 X% - 峰值承载能力提升 X% ### 技术运营指标 - P95/P99 响应下降 X% - Schema 变更工单下降 X% - 扩容时间从 X 天降至 Y 小时 - 单位吞吐成本变化 ### 风险控制指标 - 双跑期数据一致性达到目标阈值 - 零重大数据丢失 - 回滚演练成功 - 核心链路零资金差错 ### 组织效率指标 - 开发建模人天下降 X% - DBA/平台支持工时下降 X% - 故障定位时间缩短 X% --- ## 十、最终决策建议 ### 建议结论 **推荐采用“局部迁移 / 混合架构”，不建议做 PostgreSQL → MongoDB 全量替换。** ### 推荐保留在 PostgreSQL - 订单 - 支付 - 库存 - 账务 - 审计主链路 - 强约束主数据 ### 推荐优先试点迁移到 MongoDB - 配置中心 - 内容/CMS - 商品目录 - 用户画像 - 工单协作 - 设备状态快照 ### 推荐的下一步 1. 输出业务域划分表 2. 完成一致性清单 3. 选择一个文档型低风险域做 PoC 4. 建立 Outbox / CDC / 双跑与回滚能力 5. 用真实数据验证 ROI、SLA、TCO，再决定是否扩大范围 --- ## 一句话结论 **从业务、架构与运维三方面综合判断，PostgreSQL 到 MongoDB 的最佳方案不是“全面替换”，而是“让强事务核心继续留在 PostgreSQL，让文档型聚合域按业务边界渐进迁往 MongoDB，并通过事件驱动与数仓体系完成整体协同”。**