当前位置: 首页 > 科技观察

从Oracle迁移到MySQL,我们必须了解这些问题

时间:2023-03-15 13:03:27 科技观察

从Oracle迁移到MySQL需要考虑的远比我们要梳理数据类型转换的技术细节更重要,更重要。有两个问题需要提前考虑:为什么要从Oracle迁移?为什么要迁移到MySQL?阐明。问题一:为什么要从Oracle迁移?从行业实践(主要是互联网行业)来看,这件事情首先肯定不是技术上的可行性,而是商业上的可行性。说到底,主要的出发点就两个字:成本。MySQL是开源免费的,更重要的是在行业实践中得到了充分的验证,具有得天独厚的优势。阿里去IOE在很多年前就很火了,现在看来已经成为了行业的一个标杆。成本这件事很微妙,不是三言两语能说清楚的。例如,您可以使用Office来工作。当然,你可以考虑购买license或者绿色版激活,但是如果你用WPS,也是情有可原的。当然,在功能上与Office有一些差距,但不会有模糊的界限。从商业的另一个维度,想象一下我们接触的互联网行业。除了充值和钱相关的??业务,在很多业务中,对数据完整性和一致性的要求都会降低一个维度。很多时候,钱能解决的问题都不是问题,有什么比钱更重要的,我觉得应该是安全,安全包括生命安全,行业安全,系统安全,这些是绝对不允许有一些重大的问题,这些影响太大,比如医院医生给病人开药的数据,这些影响是非常大的,一旦出了问题,很容易成为公共事件。以金融级业务为分界点,上面的区域是安全领域,下面的领域其实是一些可选的空间,非常大。选择创业的原因之一也在这里。有了技术后盾,这些成本对于企业来说也需要绑定到厂商身上。如果出现问题,没有专业快速的支持,那就是悲剧了。然后是开源定制。其实很多开源技术的开源协议都是不一样的。我们在采用开源技术的时候,还需要考虑这些协议的边界和适用范围。所以这里需要明确的是:1、成本因素需要权衡,绝对不是非黑即白的事情。2、迁移到MySQL其实不是最好的方案,而是一个可选的方案。3.足够的开源技术积累4.迁移的本质是找到最适合的业务场景,而不是技术实现。以第4点为例,Oracle的性能是毋庸置疑的,但是如果有海量的Read请求其实不适合Oracle来处理,当然也不适合MySQL。也许Redis解决方案会更好。问题二:为什么要迁移到MySQL要回答这个问题,其实我们的主线就是MySQL能做什么。***还是成本,开源免费,易于定制,MySQL的选择肯定不仅仅是社区版,还有一系列的分支,比如Percona分支,MariaDB分支,存储引擎InnoDB,MyRocks等等。都是免费选项。二是MySQL足够高效和轻量级。从MySQL的效率来看,学习周期会很短,简单易上手,对系统资源要求不高。三是横向扩展能力。如果把Oracle比作地铁,把MySQL比作公交车,就更容易理解了。我们可以很容易地添加公交线路,但是添加地铁线路是完全不同的。我觉得这是迁移到MySQL的一个核心点,这也是为什么很多网上MySQL的规模往往是几百上千,业务的爆发式增长,MySQL的扩展能力不是体现在MySQL数据库本身,而是在架构中。在可扩展性方面,这是许多MySQLDBA的成本更高的原因之一。第四是复制。这是MySQL相对于Oracle的一个亮点。如果需要做跨数据中心的复制,允许有一定的延迟。使用MySQL的本机复制解决方案非常容易。MySQL支持许多不同的维度。复制方案。五是业务依赖轻,分为两个维度。一个是功能限制,另一个是性能限制。这本身就是MySQL在功能和性能上的不足,但却是一个优势,因为要支持分布式需求,业务需要更加依赖数据库,原本不支持的存储过程自然可以弱化。第六是开源带来的生态。开源红利给企业带来了很多技术方案的选择,让原本需要花钱买的东西变成了我们自己用的东西。问题三:从Oracle迁移到MySQL首先要考虑的是架构上的差异。Oracle和MySQL之间的区别是相当大的。当然Oracle中也可以使用同义词的架构来实现类似MySQL的访问模型。数据类型的不同其实是更具体的技术细节,我会做一些补充。Null和空字符串在oracle中都可以当作null来处理,但是在MySQL中这两者是不同的。oracle表名和用户名有长度限制,30个字符以内,MySQL中长度要大很多,尤其是表名需要注意。在oracle中默认按大写处理,在MySQL中默认区分大小写。对于MySQL的类型,MySQL中需要考虑的细节很多,比如数值类型,Oracle中的数字是可以固定的,MySQL有一系列的数值类型可以选择。不建议统一bigint适应所有需求。为了更清楚地回答注意事项,可以归纳为一个问题:MySQL相比Oracle缺少什么?性能肯定有区别,我们主要看功能。比较的原则不是Oracle一定要有MySQL,而是它在某些使用场景下有更好的使用特性。存储过程支持有限。这是很多企业的技术债。处理得好,就是一条坦途,处理不好,就是一个大坑。比如存储过程,如果硬要用存储过程调用来连接,后面会后患无穷。没有同义词,也没有数据库链接。MySQL不支持这个特性其实是件好事,这样就不用跨库关联了。没有sequence,这个mysql的自增列可以弥补。没有物化视图,很难实现增量刷新的需求。分区表是有的,但是很少用到。优化器薄弱,多表关联,HashJoin仍然是MySQL的软肋。索引的差异,覆盖索引的实现也大不相同。绑定变量的性能差别不大,Oracle中敏感的绑定变量问题在MySQL中不是问题。性能工具,MySQL中的性能工具还是比较少的,粒度和作用有限。总结一下:迁移的本质是找到最适合的业务场景,而不是技术实现。