去ORACLE 喊了多少年了,已经是50岁的大姑娘出嫁,不新鲜了,但是去ORACLE 这个话题的操作性仅仅是围绕那个数据库去更换ORACLE,很少听到,到底怎么从企业实际的业务角度来去除ORALE 数据库。恰巧最近新入驻的企业要彻彻底底的,去除ORACLE,这里就把正在做的事情来说说。
1 去ORACLE 难题有哪些
去除ORACLE 数据库本身并不是难题,难题是基于ORACLE 特性以及ORACLE 以上的应用怎么操作的问题
难点1: 所有的业务都在一个ORACLE 数据库上,这的确是一个难点,很多使用ORACLE的作为业务数据库的应用都有一个特点,除非是“良心” 发现,将不同的业务装配到不同的ORACLE 实例上,否则一个ORACLE 数据库被装载多个业务的表是常见的问题。
对这个问题类型的ORACLE ,实际上使用哪个数据库去更换并不是那么重要,从业务的角度去先将业务从数据库中拆分是重要的,不同的业务一组表,将这组表迁移到其他的数据库实例上,算是这类状态下,去O的日常工作
总结:这类问题,在于早期业务使用数据库方式的问题,后续从不同的业务中将表根据业务功能进行分组,是这种类型去ORACLE 的第一步工作。
难点 2: 数据的处理方式的问题,在ORACLE 中部分数据处理的方式有使用存储过程,或函数以及TRIGGER , 物化视图,等方式,数据处理的方式是去ORACLE 第二个难点,首先有一些是ORACLE 独有或特有的处理数据的方式,在承接的数据库中是否能完成这个功能,如分布式数据库大部分不支持存储过程,支持存储过程的性能也不会好很多,物化视图更是这样,大部分数据库都没有物化视图的功能,或者FLASH BACK的功能,以及非常聪明的SQL 处理解析的方式,所以选择承接的数据库方面也需要花心思来选择。
难点 3:数据量以及单表承载数据的问题,这点上虽然比上面的问题要简单,但是和上面的两个问题牵连,大型ORACLE 系统的数据在放到其他数据库上时,部分概率会牵扯到分表,将原来的一个表的数据拆分到多个数据表中,业务逻辑方面也是需要注意的。
基于上面的三点考虑可以总结出一个分类图
首先确认的问题
1 ORACLE 在迁移时必须对业务要进行梳理,妄想数据库平移,业务系统不做调整的,那基本上是在痴人说梦,所以去O 必然是一个系统重构部分的过程,同时这里在系统重新梳理和操作的过程中,应用系统可能还要设计出产出两种数据库操作语句的系统,比如在进行去O 的项目过程中,对关键业务进行逐步的迁移,应用系统能兼容 ORACLE 和另一种数据库产品的语法。
2 数据量评估,在去O的过程中对于固有数据,存留数据要有评估,同时对增量数据也要有评估。这对选择替换ORACLE的数据库的类型和方式有一定的意义。
比如ORACLE 中存储的数据都是日志类的数据,那么大可以放到MONGODB 中处理,并且通过自动清理的方式来管理这堆日志数据,或者单体表过大,通过业务不可以进行分割的,那么通过PG 来存储这样的大表并进行数据的写入和查询的操作,还有在业务可行的基础上,进行分库,分表的操作,通过MYSQL 来处理溢出的数据。但前提是,需要获知自己的应用产出的数据,和数据量。
3 数据导入导出,数据同步的方式,这点是需要考虑的,比如ORACLE TO MYSQL,ORACLE TO PG , ORACLE TO MONGODB ,这些数据库是否可以和ORACLE 进行数据的实时同步,或者如何一次性快速的导出数据,同时也不能将一切问题都压在数据库的头上,在业务端程序端,架构端,可以采用早期非切换时期的历史数据迁移,以及切换业务后的,增量数据拷贝后切换,等,所以理解业务在数据库中做了什么还是很重要的,比如对历史数据经常UPDATE 的操作,可能就不适合上面的方式,可能需要一个时间点来进行统一的切换,或通过cannal ,otter 等工具进行辅助的数据同步。
基于上面的问题总结
1 更换ORACLE 的数据库选型
2 业务数据持续同步的方式
3 基于业务的灵活性提供切换数据库的方法
4 异构数据库数据的导入导出问题
5 整体应用数据库切换不同语句撰写的方式方法
6 数据存量和增量的估算,对选型数据库数据计算和数据承受力的评估
7 ORACLE 的原有的功能,在其他数据库上的实现或应用程序,或非数据库中间件的支持和改造
综上所述,去除ORACLE 不是一个分布式数据库,或者MYSQL ,或者整体迁移所能一步到位的,原先在ORACLE 上的应用管理的越混乱,基于ORACLE 原有的功能越依赖,则去除ORACLE 的困难越大。
基于去ORACLE的工作,是一个基于架构,开发,数据库,业务等多方面的工作,需要各方努力,才能将ORACLE 从数据库的 SUPPORT LIST 上抹除。