帮你了解一下Gaussdb，你学会了吗？

大家都已经很熟悉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生态的数据库选择中有所帮助。在企业做信创数据库替代的产品选择时，可能会考虑到成本的问题，对于比较在乎成本的用户，或者需要迁移的数据库数量很多的用户，商用版与开源版同时存在的生态可能比较适合。核心关键应用用商用的，普通的应用用开源的，其内核相同，学习与运维成本相对就会较低。