聊聊OPENGAUSS3.0


现在国产数据库出的太多太快了,所以在跟踪这些数据库上就有些困难了,特别是对于我这种上了年纪,记性不好的人。最近在对一些国产数据库进行归类,有个同事把Opengauss归类到分布式数据库这类里面去了。我当时觉得很奇怪,在我的印象里,OpenGauss是一种十分典型的集中式数据库,是在PostgreSQL 9.2上魔改的。不管怎么改,想把OpenGauss改成分布式数据库还是有点难度的。

聊聊OPENGAUSS3.0

看到我不相信,同事给我拿来一篇新闻报道里面写了16节点1000万TPMC,妥妥的分布式架构啊。难道华为在3.0里发了大招了?于是我立马下载了一套OpenGauss 3.0的官方文档翻了起来。

聊聊OPENGAUSS3.0

从openGauss的产品定位上看似乎是集中式的,因为强调了准备部署的高可用关系型数据库,而不是分布式关信息数据库。

再看系统架构那就更明确的说了,openGauss是单机系统。看样子openGauss是分布式数据库的说法有点不靠谱,那么为什么发布会的海报上会这么画呢?于是我在网上搜到了发布会宣传资料的原文。

原来是标题党害死人啊,很多人看了看标题再看了几眼插图,就先入为主的认为openGauss 3.0是分布式数据库了。原来这个分布式数据库指的是和ShardingSphere的生态合作。前阵子我正好收到Medium推送的一篇文章,讲的就是ShardingSphere支持openGauss的事情。实际上ShardingShpere/Sharding Proxy已经成为国外很主流的一种分库分表中间件了,这种深度定制的解决方案,在性能上确实也是不错的,16节点1000万TPMC就是一个很好的证明。不过虽然如此,这种分布式也仅仅是PROXY /SHARDING模式的分布式,并不是真正的分布式数据库。不过有一定开发能力的企业使用ShardingSphere+openGauss的组合倒是可以研发一套自己的分布式数据库产品。有华为的资金支持,这套组合体的稳定性还是可以信赖的,加上ShardingSphere对Oracle,PG,MYSQL、SQL SERVER等多种数据库的原生态支持,以及通过JDBC/ODBC对SQL 1992标准的关系型数据库的支持,跨库访问的生态十分良好。这个组合的数据库产品在总体功能上应该是很有特色的。

华为还是舍得在研发上投入的,虽然openGauss脱胎于PostgreSQL 9.2.4这个早期版本,不过openGauss在功能特性上与原生态的PG已经有了相当大的不同,在华为的《特性描述手册》里可以看到很多令人兴奋的功能特性。

LLVM是现在很多数据库产品都引用的一个开源项目,可以提高SQL执行器的效率,向量化引擎也是为了进一步提升SQL执行效率的功能,我想这些技术的引入可以更为充分的榨干底层硬件的能力,从而提升数据库的处理性能。

行列混合存储引擎是RDBMS为了兼顾OLTP/OLAP特性的一种必然选择,很多数据库都宣称自己是一种HTAP的数据库系统,这实际上是把简单的统计分析当成OLAP了,实际上OLAP要复杂的多,需要支持很多大数据扫描,输出,计算的场景,在某些场景下,列存恐怕是必然的选择。openGauss的列存表在1.0就支持了,需要创建表的时候显式指定,开发人员在建表的时候就可以考虑把系统中的一些一次写入后经常对某些列进行分析计算的表设计为列存表。

压缩也是OLAP应用十分需要的功能,配合列存表会获得相当高的压缩比,从而大幅度减少表扫描的IO成本。

鲲鹏NUMA架构优化的功能我实际上是不希望看到鲲鹏两个字的,作为一个开源的通用数据库产品,和硬件绑定似乎给人以小家子气的感觉。不过我也能够理解研发团队的苦衷,和NUMA硬件绑定是需要软硬件做十分紧密的绑定,需要双向努力才能完成的。数年前我和YellowBrick的CEO Nil交流的时候,他认为今后分析型数据库一定是软硬件紧密集成的。我想如果华为能够把鲲鹏上的NUMA优化拓展到飞腾、安晟培等ARM平台上,甚至X86平台上,那就更完美了。ARM架构上NUMA的性能问题肯定会影响到上面的数据库在高性能、高并发环境下的性能表现。

SQL BY PASS是一个比较不错的设计,如果一个十分简单SQL因为复杂的CBO逻辑而消耗了不必要的CPU资源或者浪增加了执行时长,那就十分不值得了,从这些小设计上来获得性能的提升,说明研发团队充分考虑了运行场景。在一个系统中,简单的SQL的执行数量占比是相当高的。

XLOG NO LOCK FLUSH是一个十分神奇的功能改善,这个2.0版本引入的特性在大并发写入场景会有较大的作用。消除WALInsertLock的具体算法目前还不可知,通过官方文档的只言片语可以猜测openGauss中并没有完全消除XLOG写入锁,因为WALBUFFER如此重要的数据结构要获取写指针肯定还是需要串行化的。只是openGauss规定backend在写入WAL RECORD之前需要告知本次写入的长度,从而在写之前就更新了写指针,让后续想要写入WALBUFFER的线程可以并行写入。

另外openGauss在2.1版本开始引入了USTORE,可以用来替换ASTORE。USTORE是类似ORACLE这样的存储结构,UPDATE是在原来记录上修改的,而ASTORE是采用APPEND模式,修改一条记录的时候会生成一个新的元组。USTORE可以解决表膨胀,也可以减轻VACUUM的负担。不过从参数上看,3.0版本下,USTORE默认是关闭的,看样子目前还没有信心USTORE性能一定高于ASTORE。因为USTORE启用后,UNDO机制,MVCC的机制也发生了较大的变化,这种整体的性能磨合还需要时间。

D-SMART原本已经提供了对openGauss 2.0的支持,因此上周openGauss 3.0发布后,我们立即进行了接入处理。其主体兼容性与2.0版本差不多,因此基本上指标都能采集。不过因为3.0提供了更多新的特性,因此深度的功能还需要一定时间来做适配。

从基本信息上看,服务器版本依然是PG 9.2.4,和2.0同出一源。发行版本和数据库创建时间因为我们软件的适配问题目前没有采集到。

从插件上看,默认集成了disk/file/hdfs/KV/MOT的fdw插件,用于外部数据的集成。从这里可以看出openGauss对数据协作生态方面是比较重视的。

简单的体验了一下openGauss 3.0后,我们还是拿出了一个针对PG系数据库产品的一个小测试对数据库进行了一次小实验。这是我的一个朋友在他们的应用中发现的一个PG的小BUG,几乎覆盖了所有PG数据库版本,并且几乎所有的基于PG数据库开发的国产数据库都中招了。

通过小测试,我们发现,openGauss在这个问题上的表现与PG 9.2.4几乎是一模一样的,也未能发现和修复这个小BUG。不过使用阿里云提供的修复方法无法修复,而在以前我们测试过的几乎所有的国产数据库上,使用阿里云的修复方法都是可以修复的。看样子华为对openGauss内核还是做了较大的修改的,在很多方面已经脱离了PG社区版本。

聊聊OPENGAUSS3.0》来自互联网,仅为收藏学习,如侵权请联系删除。本文URL:https://www.hashtobe.com/268.html