Q1国产数据库与Oracle相比主要有哪些不足？孔再华：我所在的民生银行正在进行数据库本地化。在选型时，综合分析了国产数据库与Oracle等传统商业数据库相比的不足。一、性能。我们看到，目前国内的数据库大多会在性能上专注于某个方向。有的在OLTP中表现较好，有的在OLAP中表现较好。所以从HTAP的角度来看，国产数据库与Oracle相比还是存在的。一定的差距。但是你不妨换个方向想一想：我们做本地化改造是不是因为性能问题？很明显不是。那么我们需要解决的就是如何克服数据库本地化的性能问题。一方面，不同性能类型的数据库需要采用不同的本地化解决方案；另一方面，分布式数据库、内存数据库等一些超融合数据库也是可以“弯道超车”的地方。我们可以将自己的需求集成到这些数据库中进行改造实现。二、功能性。Oracle等传统商业数据库经历了几十年的发展，功能已经相当成熟，周边生态也非常完备。“年轻”的国产数据库还有很长的路要走。在这个问题上，目前国内的数据库大致可以分为两种。一是在研发之初就与Oracle生态系统进行整合，按照Oracle的功能去做。总体来说能做到80%-90%，还是有不足之处；另一个和Oracle完全不同，但其实数据库在保证性能和主要功能的前提下，有很多功能上的差异是正常的。比如Oracle和DB2是两种截然不同的数据库，不能只拿Oracle来比较。当然，这些功能上的差异也是我们需要克服的困难。对于我们已经很好用的功能，我们可能需要在本地化之后寻找一些替代方案，甚至与一些国内厂商或者第三方厂商合作，完善这些功能和生态环境。所以，国内数据库功能的不足，需要大家共同努力。三、实用性。对于像Oracle这样成熟的数据库，每次发布新版本都会有大量的bug修复。不过由于目前国内的数据库使用率并不高，所以大家探坑的机会并不多。有许多可以预见的错误。所以在易用性方面，需要大家一起努力，一起踩坑，把国产数据库推向更好的方向。Q2Oracle通常与应用程序高度耦合。迁移过程涉及应用的迁移和改造。如何评估转化量和转化难度？如何保证兼容性？孔再华：这是一个很好的问题，也是我们目前面临的最大痛点。在之前使用Oracle的过程中，我行在应用开发中使用了很多Oracle提供的功能。本土化后，转型面临很大困难。那么，如何转型迁移呢？如何评估转型难度？这确实是一个关键问题。我们在选择国产数据库时，通常会看其与Oracle的兼容性。国内很多数据库都会宣称自己对Oracle的兼容性可以达到90%以上。那么百分之九十是多少？其实这个准确的数据不需要是真的，因为剩下的百分之几是我们在迁移过程中经常遇到的事情。为了做好迁移工作，我们需要一定的杠杆。在应用的改造和迁移方面，我们最大的难点在于：如何评估应用中有哪些不兼容的地方？这个时候就需要用到一些工具，比如代码扫描工具，SQL爬虫工具等等，我们联合了一些第三方厂商，让他们根据我们的需要开发一些工具。使用这些工具扫描代码可以扫描里面所有的SQL，或者扫描数据库，不管是生产环境还是测试环境。找出所有运行过的SQL。拿到这些东西后，我们把它们放到一个评估工具中，验证原来的语法是否可以在新数据库中执行。对于无法执行的语法，需要推荐一些建议进行改造。因此，这些工具的成熟度与我们迁移转型过程的顺利与否息息相关。如果该工具易于使用，则迁移将更容易。如果不好用，往往需要人为判断，人为寻找替代品，甚至人为改造整个应用，而不仅仅是改造SQL。在数据库迁移方面，金融行业的许多数据库都是24/7全天候工作的。我们没有太多时间做离线数据迁移，所以我们需要评估DDL对象在数据迁移过程中是否可行。数据下线时间允许吗？关于DDL的对象，首先，从Oracle迁移到国产数据库时，一定要有相关资料介绍的一一对应关系。然后需要一个迁移工具，负责将原来Oracle中的字段类型和对象转换成国内数据库的对象。经过评估，现有的开源工具和商业工具对于我们迁移到国内数据库的一些规则类型的转换略有不足，因此我们与相关厂商合作，对这些规则进行了梳理，并打造了相应的工具，并在我们的迁移过程中不断改进，这个工具会越来越好。结果，我们在DDL转换上没有大问题，但下一个大问题是存储过程，以及一些使用Oracle自己的功能的东西。同样，我们也需要进行详细的梳理，然后创建相关的工具。其实过去我们并不推荐大家使用存储过程，因为使用存储过程就相当于绑定了对应的数据库。我们一直建议大家单纯使用数据库，因为数据库作为后端核心提供服务的组件，需要高可用，所以还是要尽可能的减轻数据库的负担，而不是一味的盲目依赖于数据库的这些能力。如果以前做过，只能借助工具，把不合适的地方一一找出来修改。如果以后有机会开发新的数据库，一定要避免使用触发器、存储过程等与数据库高度耦合的东西。解决了这些问题之后，接下来就是数据迁移了。如果您要从Oracle迁移到其他数据库，可能有一些很好的方法可以进行在线迁移。因为Oracle本身或者一些第三方厂商有在线迁移工具，这些工具会通过扫描日志来同步数据，然后在需要切换的时候停止业务同步最后一条数据，将业务切换到国内新的数据库。但也有可能是这些工具不支持你选择的国产数据库。在这种情况下，就需要单独创建一个离线工具来评估，如何从Oracle向国产数据库转型。最好找厂家帮忙写一个在线迁移工具。这种在线迁移最好不要实施。可以不执行并发查询Oracle数据，放入国内数据库。对于一些特别大的表，我们可能还需要增加它的并发，我们也需要工具来提供单表并发。通过编写一定的查询语句，将单表中的内容分成更多的部分，然后将每个部分并行化，提高迁移速度。总的来说，做本地化改造来替代Oracle其实是非常难的，但这注定是一个任务，也是一个目标，这就是我们要做的！我上面讲的就是如何在各个环节采取合适的方法，加快本土化改造。希望对大家有所启发。
