[mongo]应用场景及选型

应用场景及选型

MongoDB 数据库定位

  • OLTP 数据库
  • 横向扩展能力,数据量或并发量增加时候架构可以自动扩展
  • 灵活模型,适合迭代开发,数据模型多变场景
  • JSON 数据结构,适合微服务/REST API
  • 基于功能选择 MongoDB

关系型数据库迁移

从基于关系型数据库应用迁移到 MongoDB 的理由

  • 高并发需求 (数千 – 数十万 ops) ,关系型数据库不容易扩展
  • 快速迭代 – 关系型模式太严谨
  • 灵活的 JSON 模式
  • 大数据量需求
  • 地理位置查询
  • 多数据中心跨地域部署

应用迁移难度

  • 关系型到关系型 – 相对简单
  • 关系型到文档型 – 相对复杂
  • 需要考虑
    • 总体架构 (从单体式到分布式)
    • 模式设计(从关系模型到文档模型)
    • SQL 语句 / 存储过程 / JDBC / ORM
    • 数据迁移 (如何处理已有数据?)

总体架构

模式设计

  • 针对已有关系模型,考虑如何用文档模型进行设计
  • [mongo]应用场景及选型_第1张图片

数据迁移

  • 数据库导出+导入
  • 批量迁移工具
  • 实时同步工具
  • 应用主导迁移

数据迁移方式及工具

数据迁移

数据库导出导入

  • 停止现有的基于 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在限定时间段(一星期、一个月)没有被调用,认为迁移完成
  • 需要研发团队配合 ,有一定开发和测试量
  • 为保证不遗漏数据,仍然先要执行一次批量同步

应用迁移比较

你可能感兴趣的:(mongo,mongo)