应用场景及选型
MongoDB 数据库定位
- OLTP 数据库
- 横向扩展能力，数据量或并发量增加时候架构可以自动扩展
- 灵活模型，适合迭代开发，数据模型多变场景
- JSON 数据结构，适合微服务/REST API
- 基于功能选择 MongoDB
关系型数据库迁移
从基于关系型数据库应用迁移到 MongoDB 的理由
- 高并发需求 (数千 – 数十万 ops) ，关系型数据库不容易扩展
- 快速迭代 – 关系型模式太严谨
- 灵活的 JSON 模式
- 大数据量需求
- 地理位置查询
- 多数据中心跨地域部署
应用迁移难度
- 关系型到关系型 – 相对简单
- 关系型到文档型 – 相对复杂
- 需要考虑
- 总体架构 (从单体式到分布式）
- 模式设计（从关系模型到文档模型）
- SQL 语句 / 存储过程 / JDBC / ORM
- 数据迁移 （如何处理已有数据？）
总体架构
模式设计
- 针对已有关系模型，考虑如何用文档模型进行设计
-
数据迁移
- 数据库导出+导入
- 批量迁移工具
- 实时同步工具
- 应用主导迁移
数据迁移方式及工具
数据迁移
数据库导出导入
- 停止现有的基于 RDBMS 的应用
- 使用 RDBMS 的数据库导出工具，将数据库表导出到 CSV 或者 JSON（如 mysqldump）
- 使用 mongoimport 将 CSV 或者 JSON 文件导入 MongoDB 数据库
- 启动新的 MongoDB 应用
- 数据库导出导入: mysql - mongo
- mysqldump inventory -hxxxx -uroot -p -T mysql-files
批量同步
- 安装同步工具（如 Kettle / Talend） - 创建输入源（关系型数据库）
- 创建输出源（MongoDB） - 编辑数据同步任务
- 执行
- 适用批量同步，定期更新, 特别是每晚跑批的场景
- 支持基于时间戳的增量同步，需要源表有合适的时间戳支持
- 对源库有较明显的性能影响，不宜频繁查询
- 不支持实时同步
实时同步
- 安装实时同步工具（如Informatica / Tapdata） - 创建输入源（关系型数据库）
- 创建输出源（MongoDB） - 编辑实时数据同步任务
- 执行
- 基于源库的日志文件解析机制，可以实现秒级数据的同步
- 对源库性能影响较小
- 可以支持应用的无缝迁移
应用主导迁移
- 升级已有应用支持 MongoDB
- 数据插入请求直接进入 MongoDB
- 数据查询和更新请求首先定向到 MongoDB
- 如果记录不存在，从 RDBMS 读出来并写入到 MongoDB
- 重复步骤3
- 当步骤4在限定时间段（一星期、一个月）没有被调用，认为迁移完成
- 需要研发团队配合 ，有一定开发和测试量
- 为保证不遗漏数据，仍然先要执行一次批量同步
应用迁移比较
