文章目录
  1. 1. 1.整体思路
  2. 2. 2.数据库修改
    1. 2.1. DDL
    2. 2.2. DML
    3. 2.3. 触发器、存储过程
  3. 3. 3.程序修改
  4. 4. 4.数据迁移
    1. 4.1. 全量+增量
  5. 5. 5.性能
    1. 5.1. hint
    2. 5.2. 子查询
    3. 5.3. 函数与索引
  6. 6. 6.扩展性
    1. 6.1. 分库分表
  7. 7. 7.应用场景

传统的中小企业应用中,使用oracle的系统占比较多。迁移到云环境mysql数据库的情况下,需要考虑诸多因素,可用性、效率等。针对阿里云上的系统迁移情况来看,中小企业为主,迁移的应用数量比较大,所用技术五花八门,人肉处理的工作量非常大,效率较低。

1.整体思路

最主要的思路是:

  1. 先考虑可用性、跑起来,DDL+数据迁移,基本的DML,程序的修改和调整,
  2. 再考虑高性能高可用高扩展,性能优化,分库分表支持,
  3. 中间可以积累一些通用的框架和平台工具,比如:
    • 数据库反向建模与DDL生成,基于EMF、GMF之类的
    • 程序的SQL扫描处理,自动发现
    • DML转换工具,基于下面第二节的考虑要素
    • 数据迁移工具,这个应该相对比较成熟
    • 在线性能度量和优化工具,这个阿里应该也有积累
    • 将上述工具平台化,并串起来,自动评估企业应用的去O上云复杂度,评估成本
  4. 长期来看,应该基于一些友商,比如用友、金蝶、中软、中科软、中科软等一些固定产品做一些封装和深度定制合作,解决同一类平台上的不同应用系统的去O工作。
  5. 对于特定的一些行业信息化系统,也有一些类型特点,可以积累一些行业类的迁移解决方案。

2.数据库修改

DDL

  • 反向成模型,再生成mysql或其他数据库,主要是数据类型转换,主外键、约束
  • 处理sequence与自增

DML

必须改、可以改可以不改、不用改

触发器、存储过程

  • 避免,如有需要重写,考虑sql或代码里重写

3.程序修改

  • 写在代码里的SQL拼装,全文检索或语法分析获取
  • 写在xml里的mapping
  • 写在HQL类的转换引擎隐式SQL
  • 扫描代码、properties和xml
  • JDBC驱动、druid等proxy拦截SQL,系统日志过滤SQL
  • 尽量单表的简单操作,便于移植
  • 如果原先代码里没有用ORM类框架,可以使用快速的脚手架,这套脚手架可以快速的应用到不同的目标数据库,通用性的编程性基础设施都应该是一致和完备的,类似hibernate的思想。

4.数据迁移

全量+增量

5.性能

优化应该积累成规则,一起做到框架中去,最好能在运行期收集指标信息,持续动态优化,

hint

子查询

函数与索引

6.扩展性

分库分表

7.应用场景

这些工作经过积累沉淀为平台工具后,可以开源出来大家共同维护,也可以在阿里云上作为自助服务式的在线工具,提供给中小企业的技术人员直接操作转换自己的线下应用到云上。
另一方面,企业内部可能有多种不同的孤立数据源,经过这些工具转换以后,可以比较容易的在阿里云上进一步进行数据的整合,形成企业大数据中心,作为发展企业大数据的出发点。

补充:与阿里云去O团队沟通了解,目前做的工作大概就是这个思路,很多东西比这些要更深。

文章目录
  1. 1. 1.整体思路
  2. 2. 2.数据库修改
    1. 2.1. DDL
    2. 2.2. DML
    3. 2.3. 触发器、存储过程
  3. 3. 3.程序修改
  4. 4. 4.数据迁移
    1. 4.1. 全量+增量
  5. 5. 5.性能
    1. 5.1. hint
    2. 5.2. 子查询
    3. 5.3. 函数与索引
  6. 6. 6.扩展性
    1. 6.1. 分库分表
  7. 7. 7.应用场景