hanfeng_twt
作者hanfeng_twt·2024-03-14 15:06
数据库架构师·SphereEx

Oracle 兼容性面面观

字数 4538阅读 584评论 0赞 0

随着近些年来,国产数据库逐步成熟及自主创新的诉求,正有越来越多的企业计划或正在进行数据库迁移工作。在这其中 Oracle 作为大型商用数据库的代表,过去数十年是很多企业的选择;如今也面临从上面迁移到其他平台的问题。如何平滑、安全、低成本的完成迁移工作,是大家共同关心的问题。在这其中,兼容性无疑是重中之重,产品间良好的兼容能力,将有助于大大降低迁移的成本及风险,也是国内很多厂商采取的产品策略之一。本文收集部分厂商的产品,从多维度对比兼容性方面能力,从而让读者更好地了解兼容能力及如何评估产品的兼容性。

1. 漫谈兼容性问题

数据库产品,是否被大规模使用?一方面是产品自身功能,另一方面是产品生态问题。如果产品有着繁荣生态,无疑对使用者来讲会大大降低使用成本和风险。在这其中,Oracle 无疑是数据库领域的领导者。在过去数十年时间里,Oracle 公司产品取得了巨大的成功,在国内有着海量的用户。当面临上面谈到的迁移工作时,兼容 Oracle 无疑对用户来讲好处多多。确实,我们也看到国内很多数据库厂商将兼容 Oracle 作为产品的核心能力之一。下文将对这一能力做对比说。在这之前,我们先谈谈兼容性的几个问题。
❖ 不存在完美兼容
产品间是必然存在差异的,不存在完全兼容的两个产品。也就是说,不要追求完美兼容,它只是降低使用新产品的一种手段,可能也不是最优的方案。这点要有清醒的认识。百分百兼容是不可能的事情,务实的态度是实现核心功能的兼容。
❖ 聚焦核心兼容能力
Oracle 的产品功能非常庞大,大量的功能意味着兼容工作量的巨大。同时,前者还在不断演进发展中,作为模仿者的兼容压力也会与日俱增。这里要强调尽量收敛兼容范围,将其主流的、使用最多的功能作为重点兼容目标,而不是追大求全。
❖ 兼容在形,也在神
所谓形似神似,兼容不仅仅是功能表面的使用方式一致,更重要的是结果的一致。小到一个计算精度、排序方式、错误码提示,大到隔离级、SQL 支持、存储过程等。往往形式的迁移通过工具转换、人工改写很容易完成,而后者需对比执行结果,相对困难很多。
❖ 兼容有层次,等价亦可行
能做到完全兼容,代码完全不改固然是好的;但是很多情况是只能提供等价实现,这也是一种选择。虽然需要修改代码才能适配,但只要明确改写方式并提供辅助工具完成,也不失为一种方法。后文在兼容能力对比上,也区分为兼容支持和等价改写支持。
❖ 前瞻设计,兼容标准而非产品
最高的境界是不做兼容式产品,大家都遵循一种标准。这样当用户替换产品时,是不需要考虑改造问题的。这点是比较理想化的,但作为用户在前期选择产品时,可将标准开放性作为一个要素去考虑,同时对数据库的使用上也尽量使用标准化功能,而非个性功能。

2. 国内主流产品兼容度

随着近些年来数据库替换趋势愈演愈烈,国内很多数据库厂商将Oracle兼容度作为产品核心能力之一。下文收集了国内部分厂商的兼容情况,从替换中的核心功能点加以对比说明。以下内容是根据各家产品对外的官方文档内容整理而得,因文档化差异及收集范围有限,可能存在较大偏差,仅供参考。其中:色块多少代表支持程度(1~5),绿色代表兼容支持,红色代表等价支持;缺失部分为未查询到明确信息(不代表不支持)。

1).产品介绍

❖ OceanBase
OceanBase 企业版是一款完全自研的企业级原生分布式数据库,在普通硬件上实现金融级高可用,首创“三地五中心”城市级故障自动无损容灾新标准,刷新 TPC-C 标准测试,单集群规模超过 1500 节点,具有云原生、强一致性、高度兼容 Oracle/MySQL 等特性。
❖ PolarDB-O
云原生关系型数据库 PolarDB O 引擎(兼容Oracle语法)是由阿里巴巴自主研发的,高度兼容 Oracle 的高性能企业级数据库。基于云原生存储计算分离架构实现高容量存储及分钟级弹性扩缩容能力。专注解决企业数字化转型中数据库系统的平滑迁移、安全合规和成本优化等问题。
❖ KingbaseES
KingbaseES 是一款面向大规模并发交易处理的企业级关系型数据库。该产品支持严格的ACID特性、结合多核架构的极致性能、行业最高的安全标准,以及完备的高可用方案,并提供可覆盖迁移、开发及运维管理全使用周期的智能便捷工具。产品融合了人大金仓在数据库领域几十年的产品研发和企业级应用经验,可满足各行业用户多种场景的数据处理需求。
❖ DM
DM8 是达梦公司在总结 DM 系列产品研发与应用经验的基础上,坚持开放创新、简洁实用的理念,推出的新一代自研数据库。DM8 吸收借鉴当前先进新技术思想与主流数据库产品的优点,融合了分布式、弹性计算与云计算的优势,对灵活性、易用性、可靠性、高安全性等方面进行了大规模改进,多样化架构充分满足不同场景需求,支持超大规模并发事务处理和事务-分析混合型业务处理,动态分配计算资源,实现更精细化的资源利用、更低成本的投入。

2).兼容列表

❖ 用户角色
用户及角色部分,是使用数据库第一步。这部分功能相对简单,各家基本也都完成等价实现。针对数据库替换场景,这部分的工作量相对不大。
❖ 数据类型
数据类型部分,情况则相对复杂。Oracle 支持的数据类型范围较广,国内产品大部分实现兼容或等价支持,基本可满足替换要求。不支持的部分主要是部分使用场景较少或Oracle即将废弃的数据类型。但这里需要注意的是,虽然国内产品支持大部分数据类型,但在处理精度、存储空间等方面与Oracle还是有所区别。很多情况下,不能简单照搬原有的数据结构定义,还需要有所甄别调整。很多厂商也提供了迁移工具,方便完成数据类型的对应转换。
❖ 字符集及排序
字符集方面,常见的中文字符集(gbk、gb18030)及utf8系列字符集是支持重点。各厂商产品基本支持这些字符集,可满足需要。针对字符集排序方面,各家支持力度不同,有的提供多样的排序方式,有的则支持较少。
❖ 数据库对象
在数据库对象方面,Oracle 支持非常丰富的对象类型,包括但不限于表、索引、分区、视图、序列、同义词、触发器、DB Link等等。针对上述类型对象,国内产品都做了一定程度的兼容。但需要指出的是,Oracle 在这些对象上的功能是比较强大的,国内产品在支持上通常也只完成其基本功能的兼容,其大量复杂功能仍然是不具备的。不能说迁移完成即可,还需分析其原有使用的功能范围,毕竟迁移后功能无法完全覆盖。很多厂商提供的迁移工具,可方便完成数据库对象的迁移工作。
❖ 函数
函数部分,Oracle支持数百种函数,可以说极大丰富了数据库处理数据的能力。各厂商产品也都做了大量函数部分的工作。针对主要的函数,基本都可实现兼容或等价实现。这里需要注意的是,因为函数在大量应用逻辑中使用,因而采用兼容模式会大幅降低代码改造的工作量,当然有些公司提供的迁移工具中可实现代码逻辑的函数转换工作。
❖ SQL语法
SQL 语法部分,是 Oracle 颇为复杂的部分,很多基于 Oracle 开发的系统大量使用了 Oracle 的复杂 SQL。这些也成为后续改造迁移工作的重点和难点。各厂商都完成了大量 SQL 语法方面的兼容支持工作。但这部分的覆盖范围非常广,目前各厂商对外文档中对这些的能力描述还都较少。也有部分厂商提供迁移工具,可实现 SQL 语法的转换能力,可以减少迁移改造工作量。此外,这部分还需要关注一点是兼容 SQL 语法不仅是语句可执行,其语义也应是等价的,即执行结果是完全一致的。这方面还需要大量用户改造后的比对验证工作,也希望各厂商能提供此功能方便用户做好迁移工作。
❖ 过程化语言
过程化语言,是指在数据库端处理数据的一种语言。作为近存储端处理数据的一种手段,其处理是比较高效的。当然这种方式会依赖于数据库实现,且从代码管理角度看不是很好维护。Oracle 支持非常丰富的过程化语言支持,各厂商都在一定程度做了支持,但相对而言还有限。部分厂商提供的迁移工具,也支持将过程化语言转化为外部程序处理方式来解决。从长期角度来讲,过程化语言还是建议逐步减少使用,尽量减少依赖于数据库实现。此外,在分布式架构下,过程化语言的支持更为困难,不同产品差异更大;很多分布式数据库产品都不支持过程化语言。
❖ 数据字典/系统视图
数据字典,是元数据的存储。系统视图,是反映系统运行状态的一个窗口。通过它们可以快速了解系统的多方面情况。Oracle 数据库提供了非常多的数据字典和系统视图。很多用户也会基于这些字典和视图,去构建自己的监控、DEVOPS系统等。因此,兼容原数据库的字典和视图对用户来说很有意义。目前各厂商都在一定程度上做了支持,但差异还比较明显。
❖ SQL引擎
SQL 引擎部分,是 Oracle 内核最为强大的组件,提供如查询改写、预编译、CBO、执行计划(展示、缓存、绑定、管理)、自适应游标、提示等非常丰富的能力,可对 SQL 语句及执行做到全方位的管理。这方面国产数据库的差距还比较明显,经常能听到这样的声音"在 Oracle 数据库跑的很好的SQL,在国产库上执行很慢",这大多都是 SQL 引擎差异造成的。
❖ 安全特性
在安全能力上,Oracle 提供了权限、鉴权、加密、审计、标签、SSL、防火墙、VPD、Wallet 等诸多安全功能。这方面国内厂商产品较 Oracle 还有不小的差距。一方面各家还在持续增强安全能力,一方面通过数据库与生态产品合作,解决企业安全问题。
❖ 备份恢复
备份恢复,是保障数据安全的底线。Oracle 提供了完善的备份恢复能力,这方面国内厂商产品也基本覆盖了常规的备份恢复需求。但针对更高的需求,如备份集压缩、检验、租户备份等,还是有一定差距。
❖ 高可用
在高可用方面,Oracle 提供了RAC、ADG等多种架构选择;同时还支持例如闪回等能力。通过多种方式保证系统可用性。国内厂商产品有的在架构层面仿照 Oracle 做了实现,提供多种架构方案;有的则通过分布式架构下的多副本机制,提供较 Oracle 更为灵活及保障性更高的实现。
❖ 访问接口
Oracle 可通过很多的数据访问接口,如常见的JDBC、OLE DB、ODBC、.NET、Python、Go、PHP、OCI、Pro*C等等,几乎面对不同访问语言都有对应的访问接口可用。特别是很多传统应用基于C、COBOL、ADA等开发,也提供了对应接口。这方面,国内厂商产品大多完成对主流访问接口的支持,部分小众化的语言还不支持。
❖ 生态兼容
Oracle 具备庞大的生态,上下游有大量的生态企业支持,组成了庞大的生态圈。但因其私有通信协议及较为封闭的环境,在生态兼容上国内厂商很难去共享其已有生态。这点与 MySQL 等开源产品不同,后者的开放性保证其生态繁荣发展。
❖ 异构迁移
最后谈到的就是在 Oracle 向国产数据库迁移中,能提供的相关能力。这里主要包括结构、数据、过程迁移能力以及研发测试阶段能提供的相关辅助能力(如回放等)。这方面各厂商都提供外部工具辅助用户完成迁移动作。

如果觉得我的文章对您有用,请点赞。您的支持将鼓励我继续创作!

0

添加新评论0 条评论

Ctrl+Enter 发表

作者其他文章

相关文章

相关问题

相关资料

X社区推广