大家都已经很熟悉openGauss了,昨天我的文章中说陕西电力的用采系统用Gaussdb替代了Oracle,就有朋友问我这个Gaussdb是不是就是openGauss。这个问题还真的有点不好回答,Gaussdb和openGauss渊源很近,但是还不是一码事。华为在数据库产品这方面还是挺复杂的。这个Gaussdb实际上指的是Gaussdb企业版,在早期的华为云上,叫做Gaussdb for openGauss。这个企业版的Gaussdb分为分布式和主备两种形态,陕西用采用的是其中的分布式版本。而openGauss是Gaussdb产品的开源版本,是基于Gaussdb代码基础上分离出来的一个独立的数据库产品,也就是其主备版本,其中的分布式特性是完全剥离的。
这是一个Gaussdb的分布式形态的架构图。从这张图上,我们可以看出Gaussdb分为CN/DN/GTM三种节点。CN是计算节点,DN是存储节点,GTM是分布式事务管理器。实际上还有一些其他的组件,比如集群管理CM,管理配置信息的ETCD等,这里就不一一罗列了。
CN是Coordinator Node的简称,负责数据库系统元数据存储、查询任务的分解和部分执行,以及将DN中查询结果汇聚在一起。DN是数据存储节点,负责存储本地数据,并且负责分布式执行计划的本地算子执行。
可能有些朋友看到上面的架构会想起POSTGRES-XC这个开源项目,确实是的,早期的GAUSSDB是基于POSTGRES-XC开源项目的,因此虽然经过多年迭代,还是保留了一定的PGXC的痕迹。有兴趣的朋友可以去做个对比,实际上目前的Gaussdb与PGXC已经是完全不同的数据库了。
从这张图上,我们可以看出Gaussdb执行SQL的逻辑。客户端通过CN的监听端口连接到数据库上,在CN上发起一个SQL查询。CN进行SQL解析,生成分布式执行计划,并将查询计划下推到多个DN,DN启动执行线程完成查询,将结果返回CN,CN汇总执行结果,对客户端返回结果。
针对网上对Gaussdb的质疑,认为Gaussdb仅仅是PG套壳,实际上也是不够严肃的。实际上在Gaussdb的官方文档中也没有遮遮掩掩,直接表明了Gaussdb与PG以及PG-XC的关系。Gaussdb与PG的主要区别在于进程模型与线程池模型的差异,以及Gaussdb在PG的ASTORE基础上自研了内存引擎,列存和USTORE。目前在openGauss中USTORE还是处于BETA版本,而在商用的Guassdb上,USTORE已经正式商用了。
另外在GTM上,Gaussdb改写了PGXC的GTM,打破了PGXC在高并发环境下的GTM性能瓶颈。开源的PGXC因为GTM过重,并且GTM无法横向扩展而导致高并发的负载下,GTM会成为一个十分明显的瓶颈点。
作为信创替代工作的潜在数据库产品,大家可能很关心Gaussdb的Oracle兼容性问题,从openGauss上我们看到的和Oracle兼容的特性并不很多,因此很多朋友可能很关心Gaussdb是不是也像openGauss一样。如果简单分析一下Gaussdb,我们还是可以看出研发团队还是在兼容性上做了一定的工作的。首先PL/SQL存储过程的兼容性还是不错的,大多数Oracle的存储过程是可以简单的迁移过去的,当然PL/SQL上不大可能100%兼容,大多数国产数据库,哪怕是和Oracle兼容性做得很好的达梦数据库都只能做到90+%的存储过程语法兼容,不过这些兼容对于大多数应用迁移来说就完全够用了,Oracle PL/SQL的一些特殊语法,可能大多数开发人员都没听说过。
在语法上,Gaussdb支持(+)外连接,“||”拼接字符串等Oracle数据库的操作,还是做了一定的友好性兼容的,NVL,DECODE等函数也实现了和Oracle语法的兼容,也设计了rowid位列。不过Gaussdb并没有引入Oracle的dual表,因此虽然sequence的语法做了与Oracle兼容,不过只能使用select seq.nextvel 语法来替代select seq.nextvel from dual;。遇到这种Oracle数据库使用的比较频繁的语句还是要修改应用的。另外rownum位列的缺失也会让分页查询的语法与Oracle的一些传统写法不同。另外在时间函数上,Gaussdb引入了sysdate,并且支持对sysdate进行类似Oracle的加减法操作。不过我并没有找到systimestamp,如果要使用timestamp就只能使用pg_systimestamp了。
在统计和窗口函数上,Gaussdb提供的内容要比Oracle还丰富一些,这对于分布式数据库来说是十分重要的。这方面实际上是分布式数据库的一个短板,能够提供丰富的统计与窗口函数,说明Gaussdb在复杂SQL语法兼容方面做得还可以。不过因为条件有限,我目前还没有做真实的测试,性能是不是够好,还不敢说。
可以看出Gaussdb商用版在Oracle语法兼容上做了一定的工作,如果要从Oracle迁移应用过来,比起openGauss来会简化不少,不过比起这方面做得最好的国产数据库达梦数据库来看,还是有一定的差距的。
语法兼容性还是一些表面的问题,实际上如果把应用从集中式的Oracle数据库迁移到分布式的Gaussdb,还有很多性能方面的问题需要考虑。比如SEQUENECE,在集中式数据库中,哪怕是在rac上,SEQUENCE只要CACHE设置的合理,就不会有大的性能问题。而在分布式数据库Gaussdb中,Sequence的申请都会涉及GTM操作,因此成本是较高的。如果大批量的数据写入要使用Sequence,那么还是要采取一些特殊的做法的,否则性能是无法保证的。
另外一方面SQL的语法上Gaussdb虽然做了大量的优化,但是分布式数据库的CBO优化器工作机制与集中式数据库的差异也决定了在语法近似的SQL语句的执行上存在巨大的差异,因此我们在做应用迁移的时候还是需要充分考虑的。
目前Gaussdb形成了商用数据库、开源数据库(openGuass)、基于开源数据库的第三方商用数据库这种丰富的生态,又在大生态上兼容流行度排名靠前的PostgreSQL数据库。因此在生态建设方面具有得天独厚的优势,这十分有利于该生态的数据库产品的发展。目前神州通用、南大通用、海量、云和恩墨等数据库厂商都加入了openGauss生态,使用开源代码封装商用数据库产品。其中南大通用的Gbase 8C是基于openGauss内核的分布式数据库,其他三家以集中式主备模式的数据库为主。
今天本来想随便写两句,没想到也写了这么大一篇了,希望今天我的这篇文章能对大家在openGauss生态的数据库选择中有所帮助。在企业做信创数据库替代的产品选择时,可能会考虑到成本的问题,对于比较在乎成本的用户,或者需要迁移的数据库数量很多的用户,商用版与开源版同时存在的生态可能比较适合。核心关键应用用商用的,普通的应用用开源的,其内核相同,学习与运维成本相对就会较低。