麒麟v10 上部署 TiDB v5.1.2 生产环境优化实践
742
2023-04-25
都说国产数据库90%兼容***,为何迁移过程中总遇难题?
Q1 目前国产数据库与***相比主要欠缺在哪些方面?
孔再华:我所在的民生银行正在做数据库国产化改造,选型时全面分析了国产数据库相比于***等传统商业数据库的欠缺之处。
一、性能。我们看到目前国产数据库在性能上多数会偏重于某个方向,有些是OLTP的性能较好,有些则是OLAP的性能较好,所以从HTAP的角度来说,国产数据库与***相比还是存在一定的差距。
但也不妨从另一个方向考虑:我们是不是因为性能这个问题才做国产化改造的呢?显然不是。所以我们需要解决的是怎样去克服数据库国产化的性能问题。一方面,不同性能类型的数据库,需要采用不同的国产化方案;另一方面,像分布式数据库、内存数据库这样一些超融合的数据库,也是可以“弯道超车”的地方,我们可以将自身的需求融入到这些数据库里进行改造和实现。
二、功能性。***等传统商业数据库经历了几十年的发展,功能已相当成熟,周边生态也非常完善,这些对于“年轻”的国产数据库来说还有很长的路要走。
在这个问题上,目前国产数据库可粗略分为两种类型,一种是研发之初就朝着接轨***生态的方向,照着***的功能做一遍,总体来说可能做到80%-90%,还存在一定欠缺;另一种则是跟***完全不同,但其实数据库在保障性能和主要功能的前提下,有很多功能差异是很正常的,比如***和***就是很不一样的两款数据库,所以我们也不能仅仅参照***来做对比。
当然这些功能差异也是我们需要克服的困难,对于原本用得很熟练的功能,国产化后我们可能需要另找一些替代方案,甚至联合一些国内厂商或第三方厂商去改善这些功能和生态环境。所以国产数据库在功能性方面的欠缺,需要大家共同努力。
三、可用性。像***这么成熟的数据库,在每次新版本发布时都还会有大量bug的修复,但由于目前国产数据库的使用率还不算高,大家探坑的机会也就不多,使用起来才发现有不少bug也是可以预见的情况。所以在可用性这方面同样需要大家共同努力,一起去踩坑,一起将国产数据库推向更好的方向。
Q2 ***往往与应用耦合度较高,迁移过程中会涉及应用迁移和改造,如何评估改造量和改造难度?如何保障兼容性?
孔再华:这是一个非常好的问题,也是我们目前面临的最大痛点。我们银行之前在使用***的过程中,在应用开发时大量使用到***提供的一些功能,国产化后就面临着很大的改造难度。所以说,怎么进行改造和迁移?怎样评估改造难度?确实是很关键的问题。
我们做国产数据库选型时,一般会看它们对***的兼容性。很多国产数据库都会声称,自己对***的兼容性能达到百分之九十几。那到底是百分之九十几呢?其实这个准确的数据无需较真,因为剩下的百分之几也都是我们在迁移过程中经常会碰到的东西,为了做好迁移工作,我们少不了需要一定的借力。
在应用改造迁移方面,我们最大的难点是:怎样评估应用里有哪些东西是不兼容的?
这时就需要利用一些工具,比如代码扫描工具、SQL抓取工具等。我们联合了一些第三方的厂商,让他们按照我们的需求开发一些工具,使用这些工具扫描代码就能把里面的SQL全部扫描出来,或者扫描数据库,无论是生产环境还是测试环境的,都可以把曾经跑过的SQL全部找出来。当拿到这些东西之后,我们再放到一个评估的工具里去验证,原来的语法是否能在新的数据库里执行。对于不能够执行的语法,则需要推荐一些建议去进行改造。
所以这些工具的成熟与否,跟我们迁移改造的过程是否顺利息息相关。工具如果好用,迁移起来就更便捷,如果不好用,那很多时候都需要人为判断、人为寻找替代方案,甚至人为地把整个应用进行改造,而不仅仅是改造SQL。
在数据库迁移方面,金融行业很多数据库都是7*24小时工作的,我们并没有太多时间去做离线的数据迁移,所以要评估在数据迁移的过程中,DDL的对象过去是否可行?数据离线的时间是否被允许?
关于DDL的对象,首先,从***迁移到国产数据库,肯定有相关材料介绍一一对应的关系。然后,需要一个迁移工具,这个工具负责将原有***里的字段类型、对象,转换成国产数据库的对象。经评估,现有的开源工具和商业工具,对于我们迁移到国产数据库中的一些规则类型的改造都稍显不足,所以我们跟相关的厂商合作,把这些规则梳理好、把相应的工具造出来,并且在我们迁移过程中不停加以完善,这个工具就会变得越来越好使。
由此,我们在DDL的转换上问题就不大了,但接下来问题比较大的是存储过程这块,还有一些用到***自身函数的东西。同样的,我们也需要进行详细的梳理,然后打造相关的工具。其实我们以往不推荐大家去使用存储过程,因为使用了存储过程就相当于跟对应的数据库绑定了。我们一直推荐大家简单地使用数据库,因为数据库作为后端最核心的一个提供服务的组件,需要很高的可用性,所以还是要尽量给数据库减负,而不是一味地依赖数据库的这些能力。如果之前已经这么干了,就只能通过工具,逐个发现不适合的地方进行改造。如果未来自己有机会做新数据库的开发,一定要避免使用触发器、存储过程等这些跟数据库耦合度很高的东西。
当解决了这些问题之后,接下来就是关于数据迁移这块。如果是从***迁移到其它数据库,可能会有些不错的方法可以做在线迁移。因为***本身或者一些第三方厂商都具有在线迁移工具,这些工具会通过扫日志的方式同步数据,然后在需要做切换时,停业务同步最后一段数据,切换业务到新的国产数据库。
但也有可能这些工具并不支持你选用的国产数据库,这种情况就需要单独造一个离线工具进行评估,从***到国产数据库里怎么改造。最好还是找厂家协助写一个在线迁移工具,这个在线迁移最好不要落地,能够去并发、不落地地将***的数据查询出来,放到国产数据库里去。
对于一些特别大的表,我们可能还需要提高它的并发,还需要工具提供单表并发的功能。通过写一定的查询语句,把单表里的内容拆成更多份,然后每一份之间再进行并行,提高迁移速度。
总体来说,做替代***的国产化改造其实非常困难,但这注定是一个任务,是一个目标,我们就是要这么去干!以上我所讲述的,就是怎么在各环节采取合适的方式来加快国产化改造的建议,希望能对大家有所启发。
版权声明:本文内容由网络用户投稿,版权归原作者所有,本站不拥有其著作权,亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容,请联系我们jiasou666@gmail.com 处理,核实后本网站将在24小时内删除侵权内容。