都说国产数据库90%兼容Oracle,为何迁移过程中总遇难题?

数据库 新闻
本文提出了怎么在各环节采取合适的方式来加快国产化改造的建议,希望能对大家有所启发。

Q1 目前国产数据库与Oracle相比主要欠缺在哪些方面?

孔再华:我所在的民生银行正在做数据库国产化改造,选型时全面分析了国产数据库相比于Oracle等传统商业数据库的欠缺之处。

一、性能。我们看到目前国产数据库在性能上多数会偏重于某个方向,有些是OLTP的性能较好,有些则是OLAP的性能较好,所以从HTAP的角度来说,国产数据库与Oracle相比还是存在一定的差距。

但也不妨从另一个方向考虑:我们是不是因为性能这个问题才做国产化改造的呢?显然不是。所以我们需要解决的是怎样去克服数据库国产化的性能问题。一方面,不同性能类型的数据库,需要采用不同的国产化方案;另一方面,像分布式数据库、内存数据库这样一些超融合的数据库,也是可以“弯道超车”的地方,我们可以将自身的需求融入到这些数据库里进行改造和实现。

二、功能性。Oracle等传统商业数据库经历了几十年的发展,功能已相当成熟,周边生态也非常完善,这些对于“年轻”的国产数据库来说还有很长的路要走。

在这个问题上,目前国产数据库可粗略分为两种类型,一种是研发之初就朝着接轨Oracle生态的方向,照着Oracle的功能做一遍,总体来说可能做到80%-90%,还存在一定欠缺;另一种则是跟Oracle完全不同,但其实数据库在保障性能和主要功能的前提下,有很多功能差异是很正常的,比如Oracle和DB2就是很不一样的两款数据库,所以我们也不能仅仅参照Oracle来做对比。

当然这些功能差异也是我们需要克服的困难,对于原本用得很熟练的功能,国产化后我们可能需要另找一些替代方案,甚至联合一些国内厂商或第三方厂商去改善这些功能和生态环境。所以国产数据库在功能性方面的欠缺,需要大家共同努力。

三、可用性。像Oracle这么成熟的数据库,在每次新版本发布时都还会有大量bug的修复,但由于目前国产数据库的使用率还不算高,大家探坑的机会也就不多,使用起来才发现有不少bug也是可以预见的情况。所以在可用性这方面同样需要大家共同努力,一起去踩坑,一起将国产数据库推向更好的方向。

Q2 Oracle往往与应用耦合度较高,迁移过程中会涉及应用迁移和改造,如何评估改造量和改造难度?如何保障兼容性?

孔再华:这是一个非常好的问题,也是我们目前面临的最大痛点。我们银行之前在使用Oracle的过程中,在应用开发时大量使用到Oracle提供的一些功能,国产化后就面临着很大的改造难度。所以说,怎么进行改造和迁移?怎样评估改造难度?确实是很关键的问题。

我们做国产数据库选型时,一般会看它们对Oracle的兼容性。很多国产数据库都会声称,自己对Oracle的兼容性能达到百分之九十几。那到底是百分之九十几呢?其实这个准确的数据无需较真,因为剩下的百分之几也都是我们在迁移过程中经常会碰到的东西,为了做好迁移工作,我们少不了需要一定的借力。

在应用改造迁移方面,我们最大的难点是:怎样评估应用里有哪些东西是不兼容的?

这时就需要利用一些工具,比如代码扫描工具、SQL抓取工具等。我们联合了一些第三方的厂商,让他们按照我们的需求开发一些工具,使用这些工具扫描代码就能把里面的SQL全部扫描出来,或者扫描数据库,无论是生产环境还是测试环境的,都可以把曾经跑过的SQL全部找出来。当拿到这些东西之后,我们再放到一个评估的工具里去验证,原来的语法是否能在新的数据库里执行。对于不能够执行的语法,则需要推荐一些建议去进行改造。

所以这些工具的成熟与否,跟我们迁移改造的过程是否顺利息息相关。工具如果好用,迁移起来就更便捷,如果不好用,那很多时候都需要人为判断、人为寻找替代方案,甚至人为地把整个应用进行改造,而不仅仅是改造SQL。

在数据库迁移方面,金融行业很多数据库都是7*24小时工作的,我们并没有太多时间去做离线的数据迁移,所以要评估在数据迁移的过程中,DDL的对象过去是否可行?数据离线的时间是否被允许?

关于DDL的对象,首先,从Oracle迁移到国产数据库,肯定有相关材料介绍一一对应的关系。然后,需要一个迁移工具,这个工具负责将原有Oracle里的字段类型、对象,转换成国产数据库的对象。经评估,现有的开源工具和商业工具,对于我们迁移到国产数据库中的一些规则类型的改造都稍显不足,所以我们跟相关的厂商合作,把这些规则梳理好、把相应的工具造出来,并且在我们迁移过程中不停加以完善,这个工具就会变得越来越好使。

由此,我们在DDL的转换上问题就不大了,但接下来问题比较大的是存储过程这块,还有一些用到Oracle自身函数的东西。同样的,我们也需要进行详细的梳理,然后打造相关的工具。其实我们以往不推荐大家去使用存储过程,因为使用了存储过程就相当于跟对应的数据库绑定了。我们一直推荐大家简单地使用数据库,因为数据库作为后端最核心的一个提供服务的组件,需要很高的可用性,所以还是要尽量给数据库减负,而不是一味地依赖数据库的这些能力。如果之前已经这么干了,就只能通过工具,逐个发现不适合的地方进行改造。如果未来自己有机会做新数据库的开发,一定要避免使用触发器、存储过程等这些跟数据库耦合度很高的东西。

当解决了这些问题之后,接下来就是关于数据迁移这块。如果是从Oracle迁移到其它数据库,可能会有些不错的方法可以做在线迁移。因为Oracle本身或者一些第三方厂商都具有在线迁移工具,这些工具会通过扫日志的方式同步数据,然后在需要做切换时,停业务同步最后一段数据,切换业务到新的国产数据库。

但也有可能这些工具并不支持你选用的国产数据库,这种情况就需要单独造一个离线工具进行评估,从Oracle到国产数据库里怎么改造。最好还是找厂家协助写一个在线迁移工具,这个在线迁移最好不要落地,能够去并发、不落地地将Oracle的数据查询出来,放到国产数据库里去。

对于一些特别大的表,我们可能还需要提高它的并发,还需要工具提供单表并发的功能。通过写一定的查询语句,把单表里的内容拆成更多份,然后每一份之间再进行并行,提高迁移速度。

总体来说,做替代Oracle的国产化改造其实非常困难,但这注定是一个任务,是一个目标,我们就是要这么去干!以上我所讲述的,就是怎么在各环节采取合适的方式来加快国产化改造的建议,希望能对大家有所启发。

责任编辑:张燕妮 来源: dbaplus社群
相关推荐

2016-08-25 08:57:21

RDBMS数据NoSQL

2017-05-08 16:30:51

公共云宕机云计算

2010-03-30 14:09:06

Oracle数据库

2012-03-01 09:44:00

云计算安全可用性

2021-12-08 23:32:42

云计算云迁移数据

2010-03-18 09:28:14

Oracle数据库迁移

2017-07-11 16:13:42

云迁移IP地址企业

2011-07-07 13:59:54

存储过程远程数据库Oracle数据库

2015-08-17 14:50:19

亚马逊云平台应用迁移

2010-01-11 16:28:36

Fedora 2安装

2010-03-04 09:54:24

Android开发

2019-07-18 14:09:33

数据库数据迁移

2010-01-04 15:27:45

Silverlight

2017-04-07 15:00:57

Lotus-NotesORACLE数据迁移

2019-10-16 11:40:56

数据库PostgreSQL Oracle

2020-10-06 18:57:14

PostgreSQL数据库数据导入

2011-11-04 14:07:40

存储

2010-10-13 10:21:37

物理机虚拟机迁移

2010-04-20 10:01:16

Oracle数据库

2011-03-11 09:14:18

国产数据库
点赞
收藏

51CTO技术栈公众号