⭐⭐⭐ Spring Boot 项目实战 ⭐⭐⭐ Spring Cloud 项目实战
《Dubbo 实现原理与源码解析 —— 精品合集》 《Netty 实现原理与源码解析 —— 精品合集》
《Spring 实现原理与源码解析 —— 精品合集》 《MyBatis 实现原理与源码解析 —— 精品合集》
《Spring MVC 实现原理与源码解析 —— 精品合集》 《数据库实体设计合集》
《Spring Boot 实现原理与源码解析 —— 精品合集》 《Java 面试题 + Java 学习指南》

摘要: 原创出处 帅萌的杂谈铺 「帅萌的杂谈铺」欢迎转载,保留摘要,谢谢!


🙂🙂🙂关注**微信公众号:【芋道源码】**有福利:

  1. RocketMQ / MyCAT / Sharding-JDBC 所有源码分析文章列表
  2. RocketMQ / MyCAT / Sharding-JDBC 中文注释源码 GitHub 地址
  3. 您对于源码的疑问每条留言将得到认真回复。甚至不知道如何读源码也可以请教噢
  4. 新的源码解析文章实时收到通知。每周更新一篇左右
  5. 认真的源码交流微信群。

导读

去IOE,最近这几年比较火的话题,市场上也有不少成功的案例。也有不少企业也想去Oracle,今天就聊一聊去Oracle 有哪些难题?

Top1 Oracle 太强

Oracle 和MySQL对比(或其他开源数据库)。不客气的说Oracle 相对其他数据库,功能或者SQL优化器方面遥遥领先。

例如:MySQL8.0才开始执行hash join。

高可用 Oracle 有rac 稳的一逼。

#现在的MySQL8.0 能和Oracle的9i持平就很不容易了。

Top2 Oracle的存储过程触发器对开发人员太友好

很多业务开发,把业务的逻辑封装到Oracle的存储过程,触发器中了。

这样会简化业务逻辑代码,Java的程序员只要调用接口即可。

而MySQL首先就是要禁用存储过程、触发器、视图。

#enmmm 要执行去Oracle 就得把这一些存储过程、触发器,转换为业务的代码。

Top3 开发人员的思想

因为上述原因,oracle的功能、触发器、存储过程等等要强于MySQL。

开发人员可能默认数据库可以搞定一切,实在不行上“一体机”。

秒杀、AP类的SQL、各种都可以往数据库里面怼,Oracle都怼进去了MySQL也可以怼进去。

#redis不就是存存储Session...

Top4 没操作过没信心

对应Oracle to MySQL这个操作而言不仅仅涉及到单独的数据,还涉及到业务的改造。

往往不是一个部门就能绝对的事,因为没信心没实际操作过。

会有风险担心(这点没毛病),对于未知的事务本应该有敬畏之心。

这点可以在小的不重要的业务先练练手。多部门直接配合多磨炼磨炼。

也对其他组件多多了解。

还有对操作过程中引发故障的担当。

Top5 技术储备不足

本身的技术储备不足,基础平台没完善。例如Redis,Kafka 大数据等等。

Oracle同步MySQL的工具、MySQL分库分表的工具、MySQL to 大数据组件的工具.... 都属于基础组件。

还有MySQL本身的高可用,MySQL的监控等等。

Top6 人力投入大,对DBA要求高

从技术选型上来看,不仅仅是从Oracle到MySQL或者PG,还可能迁移到ES甚至是hbase等。这就对DBA有较高的要求。人力的投入和对DBA的要求可能也是去O难的重要原因之一。

例如:

像小明以前的公司,信息化建设以来几亿花费建立起来的系统,几乎都是oracle的解决方案。在服务业务的角度来看,去IOE的象征意义远大于实际意义,传统行业求稳不求新,行政压力、技术压力(原有供应商资源和技术栈将大比例更换)、财政压力都蛮大的。

总结

去Oracle不容易,其实最大的阻力来自老板的决断,也可能是公司对这件事的看法。这个操作是“自上往下推”的一个操作,以kpi的方式去实施。

若想做的更好建议招一个经验丰富的架构师吧,全方位的评估(去Oracle不单单是DBA能完成的活)。

文章目录
  1. 1. 导读
  2. 2. Top1 Oracle 太强
  3. 3. Top2 Oracle的存储过程触发器对开发人员太友好
  4. 4. Top3 开发人员的思想
  5. 5. Top4 没操作过没信心
  6. 6. Top5 技术储备不足
  7. 7. Top6 人力投入大,对DBA要求高
  8. 8. 总结