国产数据库兼容性深度解析:Oracle兼容成标杆,PostgreSQL生态崛起

2024国产数据库兼容性分析:Oracle兼容成标杆,PostgreSQL生态崛起,兼容性评估成关键。

原文标题:国产数据库兼容性简要分析

原文作者:牧羊人的方向

冷月清谈:

本文分析了2024年国测结果中一些国产数据库产品对主流数据库(如Oracle、MySQL)的兼容性。

国产数据库的兼容性主要分为功能级和内核级两种。功能级兼容性是指基于自研数据库产品兼容主流数据库的能力;内核级兼容性是指基于MySQL或PostgreSQL等开源产品二次开发,天然具备一定兼容性的数据库。

目前,Oracle数据库的兼容性已成为国产数据库厂商竞争的焦点,许多厂商都提供了从Oracle迁移的工具和评估方案。云数据库厂商则倾向于提供多种数据库产品以供选择。值得注意的是,基于PostgreSQL生态的数据库在兼容Oracle方面表现出色,而传统DB2数据库的兼容性普遍不高。

数据库兼容性涵盖SQL语法、语义、数据库逻辑对象、生态工具等多个方面。具体包括SQL语法与PL/SQL兼容性、数据库逻辑对象兼容性、字符集兼容性、数据类型兼容性、特殊功能兼容性、数据库索引及性能优化兼容性、数据库工具兼容性、驱动包和开发平台的兼容性以及安全方面的兼容性。文章还列举了兼容性评估和测试标准,并对MySQL和PostgreSQL数据库的特性进行了对比,指出PostgreSQL在数据类型支持和高级功能方面更具优势,而MySQL在简单查询和高并发场景下表现更佳。选择哪种数据库类型取决于具体的业务场景和需求。

怜星夜思:

1、文章提到PostgreSQL生态的数据库对Oracle兼容性更好,实际应用中,这种兼容性体现在哪些方面?除了语法和函数外,还有其他更深层次的兼容性吗?
2、对于DB2数据库兼容性不高的问题,除了文章提到的迁移工具转换成功率低之外,还有哪些因素导致了这种现状?未来是否有可能改善?
3、文章提到了国产数据库的兼容性评估标准,实际操作中,如何制定更有效的评估标准和测试方案,以确保选型的准确性?

原文内容

2024年国测结果公布了一些数据库产品,这些数据库产品对主流数据库的兼容性如何,数据库兼容性又有哪些兼容项,本文将简要分析。

1、国产数据库兼容性一览
在前文介绍了最新2024年国测结果公布的一些数据库产品,那么这些数据库产品在当前的数据库改造过程中,对主流的Oracle/MySQL等传统数据库具备怎样的兼容性。在兼容的层次上分为两种,功能级和内核级:
  • 功能级:主要是基于自研的数据库产品,在自身数据库能力的基础之上兼容主流的数据库产品能力。

  • 内核级:主要是基于MySQL或PostgreSQL开源产品二次研发的数据库产品,天然具备某类产品的兼容性,同时基于开源产品构建兼容其它数据库的能力。

上图是国产数据库的兼容性一览,从图中可以看出以下特性:

1)Oracle数据库的兼容性成为标杆

随着传统数据库尤其是Oracle的信创替换工作深入,各数据库厂商对Oracle数据库的兼容能力已经成为数据库选型过程中的一个关键指标之一。数据库厂商也推出了各自产品从Oracle迁移过来的迁移成本和改造评估、SQL语法转换工具和迁移工具,这一块的周边工具生态也是在逐渐完善。

2)云数据库厂商兼备多种数据库产品

从产品能力上看,云厂商具备产品集约的能力,集中多种数据库产品的能力,提供多样性的选择。随着基础设施上云以及数据库上云的呼声越来越高,云数据库厂商提供多种数据库类型套餐选择,也为传统数据库的信创改造提供了便利。

3)基于PostgreSQL生态的数据库高度兼容Oracle

由于PostgreSQL和Oracle数据库在内核设计上高度相似,基于PostgreSQL生态的数据库产品相比MySQL生态的数据库也具备一定的优势。

4)传统DB2数据库兼容性不高

从已知的国产数据库产品兼容性能力来看,没有哪个厂商声称对DB2高度兼容。有部分厂商的迁移工具如GaussDB支持从DB2迁移到Oracle,但从实际迁移效果来看,SQL和表结构迁移转换的成功率不高,更多的需要应用进行迁移改造和适配。这也为传统DB2数据库的信创改造增加了迁移难度和改造成本。

2、数据库兼容性分析
2.1 数据库兼容项

提到国产数据库的兼容性,可能会有疑问,这个兼容性具体指代哪些,应用又需要进行哪些适配性改造。简言之兼容性包括SQL语法兼容性、语义的兼容性、数据库逻辑对象的兼容性以及生态工具的兼容性等。

1)SQL语法与PL/SQL兼容性

SQL语法有ANSI、SQL92、99、2003SQL等标准,但不同的数据库实现了自己的SQL语法扩展和特性,导致其之间的SQL语法存在一定的差异。比如Oracle并不十分严格的遵循SQL国际标准,其早期的数据库版本中存在大量的自定义风格的SQL。因此在SQL语法兼容性上需要尽可能支持Oracle的SQL语法,以减少迁移过程中的工作量。另外像PL/SQL是Oracle的一种过程化编程语言,许多应用程序都会使用到。但是大部分国产数据库在PL/SQL支持度上可能不超过80%。如果应用程序重度使用PL/SQL,那么迁移可能会增加一些工作量。

2)数据库逻辑对象兼容性

数据库逻辑对象包括表、视图、索引、存储过程、触发器等,在逻辑对象兼容性方面需要尽可能支持Oracle等传统数据库的逻辑对象,不能支持的需要进行兼容性改造。像存储过程和触发器等过程化对象,国产数据库需要支持其定义和执行,以确保应用程序中的业务逻辑能够在新数据库中得到正确实现。不少数据库厂商已经提供了迁移改造的评估和转换工具,基本能支持60%~70%的SQL和数据库对象转换,减少了迁移的工作量。

3)数据库字符集兼容性

字符集兼容性是数据库迁移过程中需要关注的重要问题。不同数据库可能支持不同的字符集,因此在迁移过程中需要确保数据的字符集在新数据库中能够正确显示和存储。例如MySQL支持utf8、utf8mb4等字符集,而Oracle支持AL32UTF8、AL16UTF16等字符集。当要将数据从一个数据库迁移到另一个数据库时,需要确保数据的字符集不会丢失或损坏,务必注意字符集的兼容性,以确保数据能够正确地存储和显示。

4)数据类型兼容性

数据类型兼容性是数据库迁移过程中最重要的一环,不同数据库产品支持的数据类型有差异。在迁移过程中可能会遇到类型转换的问题。常见的需要特别注意的数据类型包括PFILE、XMLTYPE等,以及nchar/nvarchar等字符类型。此外,还需要注意char字段的填充问题,以及编码上的差异可能导致的数据迁移不一致等问题。尤其要注意null值的处理,在MySQL和Oracle数据库处理上是不一样的。

5)特殊功能兼容性

传统数据库在系统中使用了一些特殊功能,如序列号、自增字段、物化视图、触发器、全局临时表、内置函数和系统视图等。国产数据库在迁移过程中需要尽可能支持这些特殊功能,或者提供类似的替代方案。例如,对于序列功能,国产数据库可以提供类似的自增字段或序列生成器来替代;对于物化视图功能,国产数据库可以提供缓存查询结果或定期刷新视图等替代方案。在迁移过程中,需要评估这些特殊功能在新数据库中的实现方式和性能表现。

6)数据库索引及性能优化兼容性

Oracle等传统数据库提供了多种索引类型,如B树索引、位图索引、全文索引等。国产数据库在索引兼容性方面需要支持这些索引类型,并提供相应的性能优化手段。例如,对于B树索引,国产数据库需要支持其创建、删除和更新操作,并优化其查询性能。此外,国产数据库还可以提供其他性能优化手段,如分区表、查询重写等,以提高数据库的查询效率和响应时间。另外像Oracle数据库有统计信息收集、执行计划跳变和绑定等,在国产数据库迁移改造过程中需要关注这些特殊的点。

7)数据库工具兼容性

传统数据库提供了丰富的数据库工具,如数据导入导出工具、备份恢复工具、性能监控工具等。国产数据库在工具兼容性方面需要尽可能支持这些工具的功能和使用方式,以降低迁移过程中的学习和使用成本。例如,国产数据库可以提供与Oracle类似的数据导入导出工具,并支持常见的文件格式和数据格式转换。此外,国产数据库还可以提供性能监控和调优工具,以帮助用户更好地管理和优化数据库性能。

8)驱动包和开发平台的兼容性

传统数据库提供了丰富的驱动包和开发平台支持,如JDBC、ODBC、Python和go等。国产数据库需要支持这些驱动包和开发平台,以确保应用程序能够顺利连接到新数据库并进行数据操作。此外,国产数据库还需要提供相应的开发文档和示例代码,以帮助开发人员更好地理解和使用新数据库的功能和特性。

9)安全方面的兼容性

数据库安全特性是防止未经授权的访问、数据泄露、数据损坏和其他安全威胁,确保数据库系统的完整性、可用性和保密性。常见的数据库安全特性包括访问控制、数据加密、审计和监控、数据脱敏等。国产数据库需要支持各种安全认证机制,比如SSL/TLS加密、用户身份验证、权限管理、密码复杂度、国密算法等,以确保数据的安全性和完整性。

当然国产数据库的兼容性分析远不止以上这些,每一项又可以细化为不同的评估准则。在实际选型过程中,制定兼容性评估和测试标准,以作为选型的依据,如下表所示:

2.2 MySQL和PostgreSQL数据库特性简单对比

在统计国产数据库的兼容性的时候有个疑问,基于PostgreSQL数据库生态研发的国产数据库是如何在内核层面做到兼容MySQL数据库的,MySQL和PostgreSQL数据库二者本身具备不小的差异。比如GaussDB数据库在在创建数据库时,通过参数DBCOMPATIBILITY指定兼容数据库的类型A、B、C和PG四种兼容模式,分别表示兼容Oracle、MySQL、Teradata(TD)和PostgreSQL。在使用兼容MySQL或PostgreSQL模式的时候,为什么不选择对应的云数据库MySQL/PostgreSQL版本,性能表现和兼容性上会更好。以下是MySQL和PostgreSQL数据库在特性上的对比,简单了解下这两个数据库的差异。

1)起源与发展

  • PostgreSQL的根源可以追溯到伯克利的POSTGRES项目,旨在推动数据库技术的边界,强调理论的严谨性和对SQL标准的严格遵循。这种学术背景赋予了PostgreSQL强大的理论基础和对数据一致性的高度关注,使其成为支持复杂查询、事务处理和高级数据类型的理想平台。PostgreSQL基于自由的BSD/MIT许可,这使得它更加灵活,允许更广泛的商业用途。

  • MySQL是开源的关系型数据库管理系统,由瑞典MySQL AB公司开发,后归属于Oracle旗下。初衷是为了满足互联网应用程序的快速开发需求。MySQL的设计哲学围绕着简化数据库管理、提高性能,并提供快速开发的环境。其核心代码基于GPL(GNU通用公共许可证)或Commercial License(商业许可证),对于商业用途有一定的限制。

2)SQL语法特性对比

PostgreSQL在数据类型支持上更为丰富,提供了数组、JSON、范围类型等特殊数据类型的支持。此外,PostgreSQL还支持更多高级功能和扩展,如复杂的查询、窗口函数、触发器、事务处理等。

3)性能与扩展性

MySQL在简单的select查询性能表现优异,适合高并发的场景;PostgreSQL则在复杂查询、连接操作上性能更佳。

因此,在选择MySQL生态还是PostgreSQL生态的数据库时,结合实际的业务场景进行选择。比如业务SQL不复杂,没有过多的join关联、聚合计算等复杂查询,又需要高并发的业务请求,适合基于MySQL数据库,比如大部分的金融核心系统。而一些偏报表查询或加工、财务报送类系统,适合基于PostgreSQL数据库改造。当然,如果应用本身设计上的历史包袱,造成大量的处理逻辑由数据库来完成,一个存储过程可能接近上万行,应用优化成本太高,只能选择复杂运算性能更好的数据库了,比如OceanBase等。

以上仅是个人观点,如有不当之处请指出。

参考资料:

  1. https://zhuanlan.zhihu.com/p/652274980

  2. 国产数据库兼容性大比拼,韩锋频道

  3. https://blog.csdn.net/weixin_43298211/article/details/139929527

从DBA的角度来看,PostgreSQL在数据管理和运维方面也有一些特性和Oracle比较接近,比如表空间管理、资源管控等。这些特性对于大型数据库系统的管理和维护至关重要,也使得PostgreSQL成为Oracle迁移的一个不错的选择。

制定评估标准,首先要明确自身业务需求,哪些SQL特性是必须支持的,哪些功能是不可或缺的。然后,可以参考一些行业标准和最佳实践,结合实际情况制定测试用例,进行性能测试、功能测试和稳定性测试。最后,根据测试结果进行综合评估,选择最合适的数据库产品。

DB2的兼容性问题,部分原因是DB2本身的市场份额相对较小,国产数据库厂商的投入力度不足。另外,DB2的一些特性比较独特,例如其存储过程的语法和Oracle、MySQL都有较大差异,这也增加了兼容的难度。未来随着信创的推进,如果DB2的迁移需求增多,相信国产数据库厂商也会加大投入,改善兼容性。

对于评估标准,可以分阶段进行。初期可以先进行一些简单的测试,筛选掉一些明显不符合要求的产品。然后针对入围的产品进行更深入的测试,包括模拟真实业务场景的压力测试,以及一些特殊情况的测试,例如断电恢复、数据备份等等。这样可以更全面地评估数据库的性能和稳定性。

我觉得兼容性好坏不能一概而论,得看具体的数据库产品。有些基于PostgreSQL的数据库确实在一些Oracle特性的支持上做得不错,比如分区表、物化视图等。但有些可能只是在语法层面做了兼容,实际运行效率和Oracle还是有差距的。所以,选择数据库还是要根据实际的业务需求和测试结果来决定。

关于PostgreSQL生态数据库对Oracle的兼容性,除了语法和函数,更深层次的兼容性体现在体系结构和一些核心特性上。比如,两者都支持MVCC(多版本并发控制),这对于高并发场景下的数据一致性非常重要。另外,PostgreSQL也支持类似Oracle的PL/SQL的存储过程语言PL/pgSQL,这使得从Oracle迁移存储过程的难度降低。当然,兼容性并非完全等同,实际迁移过程中仍需进行代码适配和调整。

个人觉得,DB2的兼容性问题可能也跟其本身的版本和特性有关。不同版本的DB2之间也存在一些兼容性问题,这无疑增加了国产数据库适配的难度。未来可能需要一些专门针对DB2迁移的工具和方案出现,才能更好地解决这个问题。

我感觉DB2的架构和Oracle、MySQL这些主流数据库不太一样,可能在底层实现上就存在很大的差异,导致兼容起来比较困难。而且DB2的用户群体相对比较小众,厂商可能觉得投入产出比不高,所以优先级就比较低。