大家都已经很熟悉 openGauss了，昨天我的文章中说陕西电力的用采系统用Gaussdb替代了Oracle，就有朋友问我这个Gaussdb是不是就是openGauss。这个问题还真的有点不好回答，Gaussdb和openGauss渊源很近，但是还不是一码事。华为在数据库产品这方面还是挺复杂的。这个Gaussdb实际上指的是Gaussdb企业版，在早期的华为云上，叫做Gaussdb   for   openGauss。这个企业版的Gaussdb分为分布式和主备两种形态，陕西用采用的是其中的分布式版本。而openGauss是Gaussdb产品的开源版本，是基于Gaussdb代码基础上分离出来的一个独立的数据库产品，也就是其主备版本，其中的分布式特性是完全剥离的。

这是一个 Gaussdb的分布式形态的架构图。从这张图上，我们可以看出Gaussdb分为C N/DN/GTM 三种节点。 C N 是计算节点， D N 是存储节点， G TM 是分布式事务管理器。实际上还有一些其他的组件，比如集群管理 C M ，管理配置信息的 E TCD 等，这里就不一一罗列了。

CN 是 Coordinator Node 的简称 ，负责数据库系统元数据存储、查询任务的分解和部分执行，以及将 DN 中查询结果汇聚在一起。 D N 是数据存储节点，负责存储本地数据，并且负责分布式执行计划的本地算子执行。

可能有些朋友看到上面的架构会想起 POSTGRES-XC 这个开源项目，确实是的，早期的 G AUSSDB 是基于 P OSTGRES-XC 开源项目的，因此虽然经过多年迭代，还是保留了一定的 P GXC 的痕迹。有兴趣的朋友可以去做个对比，实际上目前的 Gaussdb与P GXC 已经是完全不同的数据库了。

从这张图上，我们可以看出 Gaussdb执行S QL 的逻辑。客户端通过 C N 的监听端口连接到数据库上，在 C N 上发起一个 S QL 查询。 C N 进行 S QL 解析，生成分布式执行计划，并将查询计划下推到多个 D N ， D N 启动执行线程完成查询，将结果返回 C N ， C N 汇总执行结果，对客户端返回结果。

针对网上对 Gaussdb的质疑，认为Gaussdb仅仅是P G 套壳，实际上也是不够严肃的。实际上在 Gaussdb的官方文档中也没有遮遮掩掩，直接表明了Gaussdb与P G 以及 P G - XC 的关系。 Gaussdb与P G 的主要区别在于进程模型与线程池模型的差异，以及 Gaussdb在P G 的 A STORE 基础上自研了内存引擎，列存和 U STORE 。目前在 openGauss中U STORE 还是处于 B ETA 版本，而在商用的 Guassdb上，U STORE 已经正式商用了。

另外在 G TM 上， Gaussdb改写了P GXC 的 G TM ，打破了 P GXC 在高并发环境下的 GTM 性能瓶颈。开源的 PGXC 因为 G TM 过重，并且 G TM 无法横向扩展而导致高并发的负载下， G TM 会成为一个十分明显的瓶颈点。

作为信创替代工作的潜在数据库产品，大家可能很关心 Gaussdb的Oracle兼容性问题，从openGauss上我们看到的和Oracle兼容的特性并不很多，因此很多朋友可能很关心Gaussdb是不是也像openGauss一样。如果简单分析一下Gaussdb，我们还是可以看出研发团队还是在兼容性上做了一定的工作的。首先P L/SQL 存储过程的兼容性还是不错的，大多数 Oracle的存储过程是可以简单的迁移过去的，当然P L/SQL 上不大可能 100%兼容，大多数国产数据库，哪怕是和Oracle兼容性做得很好的达梦数据库都只能做到90+%的存储过程语法兼容，不过这些兼容对于大多数应用迁移来说就完全够用了，Oracle  PL/SQL 的一些特殊语法，可能大多数开发人员都没听说过。

在语法上， Gaussdb支持( +) 外连接， “||”拼接字符串等Oracle数据库的操作，还是做了一定的友好性兼容的，N VL,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在复杂S QL 语法兼容方面做得还可以。不过因为条件有限，我目前还没有做真实的测试，性能是不是够好，还不敢说。

可以看出 Gaussdb商用版在Oracle语法兼容上做了一定的工作，如果要从Oracle迁移应用过来，比起openGauss来会简化不少，不过比起这方面做得最好的国产数据库达梦数据库来看，还是有一定的差距的。

语法兼容性还是一些表面的问题，实际上如果把应用从集中式的 Oracle数据库迁移到分布式的Gaussdb，还有很多性能方面的问题需要考虑。比如S EQUENECE ，在集中式数据库中，哪怕是在 rac上，S EQUENCE 只要 C ACHE 设置的合理，就不会有大的性能问题。而在分布式数据库 Gaussdb中，Sequence的申请都会涉及G TM 操作，因此成本是较高的。如果大批量的数据写入要使用 Sequence，那么还是要采取一些特殊的做法的，否则性能是无法保证的。

另外一方面 S QL 的语法上 Gaussdb虽然做了大量的优化，但是分布式数据库的C BO 优化器工作机制与集中式数据库的差异也决定了在语法近似的 S QL 语句的执行上存在巨大的差异，因此我们在做应用迁移的时候还是需要充分考虑的。

目前 Gaussdb形成了商用数据库、开源数据库（openGuass）、基于开源数据库的第三方商用数据库这种丰富的生态，又在大生态上兼容流行度排名靠前的PostgreSQL数据库。因此在生态建设方面具有得天独厚的优势，这十分有利于该生态的数据库产品的发展。目前神州通用、南大通用、海量、云和恩墨等数据库厂商都加入了openGauss生态，使用开源代码封装商用数据库产品。其中南大通用的Gbase   8C是基于openGauss内核的分布式数据库，其他三家以集中式主备模式的数据库为主。

今天本来想随便写两句，没想到也写了这么大一篇了，希望今天我的这篇文章能对大家在 openGauss生态的数据库选择中有所帮助。在企业做信创数据库替代的产品选择时，可能会考虑到成本的问题，对于比较在乎成本的用户，或者需要迁移的数据库数量很多的用户，商用版与开源版同时存在的生态可能比较适合。核心关键应用用商用的，普通的应用用开源的，其内核相同，学习与运维成本相对就会较低。