【杂谈】关于我为什么要发起AIO(ALL IN ORACLE)项目

2008年，阿里第一次提出“去IOE”(IBM主机、ORACLE数据库，EMC高端存储设备)，当时不少人觉得是痴人说梦，但通过阿里多年的努力，在阿里的确几乎已经实现了。而且在2013年棱镜门事件出现后，我国政府也在大力支持去IOE化，比如某年win8桌面操作系统也未进入中央机关政府采购名单。

但时至今日，仍然有不少大型企业的后台仍然还在使用ORACLE数据库及ORACLE的应用产品，其中不乏几大国有银行，甚至连京东和华为这样的大型企业，其财务端后台还是用的ORACLE公司的EBS系统。这背后其实不是说不想换，而是ORACLE数据库在一些场景上，的确无法替代，而且ORACLE数据库更为稳定可靠。

从1979发布的第一个ORACLE数据库版本起至今，ORACLE数据库大大小小更新了不计其数次，在写此文章时，已有21C版本。

ORACLE数据库中的自带函数也是目前关系型数据库中最多的，这也加大了从ORACLE数据库移植到其他数据库的难度。而且ORACLE的PL/SQL语言是目前众多开发语言中最接近自然语言的，用pl/sql开发对应的后台数据处理程序极其方便快捷，比JAVA连库查数据处理数据再存入数据效率高多了，技术门槛也低，所以使用ORACLE数据库的开发人员，大多会利用ORACLE数据库创建一些存储过程或者函数来实现需求。但是这个也加大了数据库移植的困难度，因为目前不存在任何一个其他关系型数据库能做到100%的从ORACLE数据库移植而不需要改代码的。尤其是ORACLE公司自己的某些软件产品，有相当大占比的程序代码都是在数据库中以PL/SQL形式存在的。

在阿里的JAVA开发规范手册中有这么两条

【强制】禁止使用存储过程，存储过程难以调试和扩展，更没有移植性。
【强制】超过三个表禁止 join。需要 join 的字段，数据类型必须绝对一致；多表关联查询
时，保证被关联的字段需要有索引。

注意，这里说的是java，这个的确没错，因为java开发的项目主要的程序都在java里，程序主线程一定是java，此时如果在非java的地方写了什么程序，比如数据库存储过程，里面的逻辑就不受java控制了。

但是，如果本身就是用数据库来做程序开发，数据库自己就可以管理到日志，也不存在说难以调试和扩展。至于多表join，同样的数据量级同样的索引，ORACLE的查询效率比mysql快了N倍。虽然说开发人员的确要注意查询sql性能的优化，但是在某些需求场景下，必须要做超过3个表的关联，因为查询条件分布在多个表，不一起关联过滤会导致内存中提取的数据过多而导致效率低下。所以很多使用ORACLE数据库的开发人员，为了节省时间，粗犷式写SQL，至于优化就交给ORACLE数据库自己去优化了，实在不行再DBA出面调优。尤其像一些复杂报表的查询，那SQL真像是坨*，但真还能查出来，而且速度也快，同样的SQL放到mysql中去跑，数据库跑挂了都说不定。。。当然这不能成为开发人员偷懒的借口，该手动优化的还是得手动优化。

正因为ORACLE数据库开发的便利度及其稳定性，导致很多企业一直还在使用，但是随着互联网的发展，各种交互越来越多，跨开发语言的交互、跨角色的交互、跨公司的交互等等。先不说新版本的ORACLE数据库支持其他开发语言到了何种程度，老版本ORACLE本就原生或者通过三方扩展包来支持这些交互，只是国内很少有人去整合这些内容并及时更新新功能和修正bug，所以我想通过发起这样一个项目来归纳整理各种其他语言的程序效果在ORACLE数据库中如何实现。

AIO(ALL IN ORACLE)意为，通过ORACLE来实现所有的东西。当然这个“所有”是夸张的描述，但是这个项目里面，会有很多那种让人一看就发出惊叹“ORACLE数据库连这种功能都能实现？”的内容。

有太多企业内部系统越来越重，一时半会也无法切换到所谓最新流行的架构，不能就这么让他们的业务落后于这个时代，也不能让他们强行切次系统就倒下。所以AIO这个项目看似强化了ORACLE的使用场景，实际是为了多给一点这些企业系统转型的时间。缺少开发人员的企业，可以通过AIO项目快速获取解决方案，在不动核心系统架构保障业务仍可继续运行的情况下，另起一条线，安安心心去思考如何调整核心系统架构去拥抱未来。

当然也期待有更多的合作伙伴能一起探讨ORACLE数据库更多的可能性，毕竟知己知彼方能百战不殆，国产数据库一直在努力超越，但是大多数人连外国的数据库能做到什么程度都不清楚，何谈超越？

之后AIO项目可能会改名，因为“AIO”已被其他公司在计算机软件分类下注册，新的项目名称以后想到了再说吧。

posted on 2021-07-15 07:44  DarkAthena  阅读(98)  评论(0)  编辑  收藏  举报

导航