[mongo]应用场景及选型

应用场景及选型

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） - 编辑实时数据同步任务
• 执行
• 基于源库的日志文件解析机制，可以实现秒级数据的同步
• 对源库性能影响较小
• 可以支持应用的无缝迁移

应用主导迁移

1. 升级已有应用支持 MongoDB
2. 数据插入请求直接进入 MongoDB
3. 数据查询和更新请求首先定向到 MongoDB
4. 如果记录不存在，从 RDBMS 读出来并写入到 MongoDB
5. 重复步骤3
6. 当步骤4在限定时间段（一星期、一个月）没有被调用，认为迁移完成

• 需要研发团队配合 ，有一定开发和测试量
• 为保证不遗漏数据，仍然先要执行一次批量同步

应用迁移比较

•