平替还是改造

以下文章来源于白鳝的洞穴 ，作者白鳝

白鳝的洞穴.

老白个人交流平台，系统优化、Oracle和架构及驴行天下

优炫数据库兼容Oracle及MySQL等数据库常用SQL语法，并通过优炫迁移工具实现一键式迁移Oracle及MySQL等数据库的对象及数据到优炫数据库，为数据库国产化“平替”铺平道路，满足“存量替换”场景的需求；同时对于新的应用系统通过“边开发、边优化”， 满足“增量创新”场景的需求。

文章来源于 | 白鳝的洞穴

作者 | 白鳝

近日，ITPUB举行了一个关于信创替代的线上沙龙，其中讨论的问题是信创替代，平替还是改造的问题。对于数据库而言，有一些相关的案例，因此我发表了一些观点。不过因为时间关系，并没有把想表达的所有观点都表达出来，因此想先把这一切都写下来，否则有些思考会被淡忘。

对于数据库而言，信创替代中的平替是指选取与Oracle等需要替代的数据库兼容度较高的产品，在不对应用系统做较大改造的前提下实现替代；而改造则根据国产数据库的特点，对应用系统做较大的针对性改造，实现数据库国产化替代。就这两种替代方案而言，改造替代肯定是成本相对较高的模式。因此国产数据库厂商一般建议先平替迁移，然后再做少量的优化改造，实际上这种模式就是我所说的平台模式。因为其成本相对较低，替代速度较快，因此也比较受到用户的青睐。

为了看清楚二者的优缺点，先介绍一个某行业核心系统替代的案例。这个案例来自于两个业务基本相似的不同企业。这套系统是企业最为核心的系统，复杂度也比较高，存在大量的复杂业务逻辑的SQL，数据量也相当巨大。

在这个案例中，一个企业采用平替模式，把原来在Oracle跑的应用直接迁移到与Oracle有较高兼容性的分布式数据库上，然后针对某些不兼容特性与性能存在问题的SQL语句进行了比较周密的改写与优化。系统上线也比较顺利，不过上线一段时间后，遇到了一些偶发性的性能与系统卡顿的问题。被迫先暂时回切到Oracle系统，然后再去定位问题，解决问题后再做切换。

另外一个企业则认为他们选择的国产数据库在功能、性能、Oracle兼容性方面都存在一定的问题，因此决定在迁移过程中多花点时间，多花点钱，一次性完成改造切换。虽然改造周期比第一家企业要长一些，不过通过这次改造，把一些以前系统设计不合理，完全依靠Oracle强大的能力硬扛的系统功能点都改造完了。因此系统上线后相对稳定，哪怕出现一些问题也可以很快解决掉。

采用这两种方式进行改造迁移，最终都能够解决遇到的问题，完成迁移。不过对于复杂的关键性业务系统而言，简单的平替似乎并不是一个特别靠谱的方案。从Oracle平替迁移过来的应用往往存在大量的问题，放到没有Oracle稳定与强大的国产数据库上，可能会留下太多的隐患。

上面所说的是复杂、大型、关键的业务系统，在这方面企业往往可以投入较大的资金去做改造，因此改造替换比简单平替要更好一些。不过对于海量的小型的、业务不那么复杂的系统而言，都采用深度改造的替代方法恐怕对企业的投资来说过于巨大。因此这些系统采用平替的方案可能更为务实一些。这是目前客户希望国产数据库做各种兼容性的主要原因。

似乎这个问题已经讲清楚了，其实不然，哪怕是改造替代，也要注意一些问题。有人可能会说，既然都改造替代了，那么让应用去适应国产数据库就可以了，数据库选型可以随意一些了。

其实不然，在这里还有一个案例。有家企业做国产数据库替代，为了节约资金，学习互联网企业的先进经验，选择了一个基于MySQL的分库分表的方案，将整个系统拆分成了几十个MySQL数据库。不过因为研发队伍能力与研发进度要求等问题，对于读写分离，历史数据分离等都没在开始时候做上。甚至有些复杂业务对于只习惯写SQL完成业务逻辑的研发人员来说也十分困难。为了实现业务，在这些库之间还设置了大量的广播表，用以复制那些有共享数据需求的应用。系统上线后，随着数据量的增长，系统出现的问题也越来越严重，很快就脱离了研发团队技术能力。

这个案例可以看出信创替代中的另外一个问题，那就是企业在选型数据库与解决方案的时候，一定要选择研发与运维队伍能够把控的技术路线。没有互联网企业的技术能力的，就不要轻易学习人家的分库分表；没有分布式数据库研发与应用经验的企业，就老老实实用集中式数据库。

信创替代，说难很难，说容易也容易，不过做之前根据自己的能力特点，选择适当的方案还是十分关键的。现在对信创这个话题，有各种观点。每种观点都有一定的道理。不过对于某些企业或者行业，这个工作已经是必须做的事情了，那么就去做好了。数据库替代这个事情，想想都是问题，不过咬牙做下去，似乎都能找到答案。