聊聊Opengauss的一些增强特性


不过华为的OPENGAUSS加入到这个阵营后,我们也看到了一个新的PG魔改者。在OPENGAUSS的PG核心引擎里,加入了很多很有趣的新特性。根据华为最新的基准测试数据看,在鲲鹏服务器上,2路服务器+OPENGAUSS 2.0的TPMC基准测试达到了150万+,而在4路的鲲鹏服务器上,居然高达230万。可能有些朋友对此没有太大感觉,不过如果我简单做个比较,2012年,Oracle在T系列T5-8小型机上创造的TPMC世界纪录是855万,跑出这个结果的硬件配置的按当时的售价大约是633万美金。
一台2路
的鲲鹏服务器上跑OPENGAUSS可以满足传统企业
90%以上的应用负载,是不是
很恐怖呢?
到底OPENGAUSS对PG做了哪些魔改,才能达到如此高的性能呢?今天我们简单的说几个。首先我们谈谈增量检查点,可能很多朋友对增量检查点不以为然,实际上增量检查点是支持高并发的数据库系统持续提供稳定的性能输出的关键。如果没有增量检查点,那么当检查点写盘性能跟不上的时候,数据库出现卡顿是大概率事件。而传统的PG因为FULL_PAGE_WRITES的存在,对增量检查点的支持并不好。OPENGAUSS采用了double write+FULL_PAGE_WRITES双支持的方案。如果启用了double write,那么full_page_writes被自动关闭(关于这个问题,参考昨天我发的讨论PG FULL_PAGE_WRITE的文章)。因为在这方面的优化,使增量检查点变成可能。当年Oracle出现增量检查点功能的时候,也是DBA的巨大福音,有了这功能,检查点的优化就简单多了。其次是内存表,很多应用场景都想把部分表的数据放到内存缓冲中去,Oracle在早期也设置了KEEP POOL来缓存部分表数据。实际上内存表和ORACLE 的KEEP POOL是完全不同的。因为内存表机制是在内存引擎中直接操作一张表。MYSQL也有内存引擎NDB,不过NDB对SQL语法都是有限制的。OPENGAUSS也只是声称内存表支持绝大多数的SQL语句。有了这个功能,应用开发就简单多了。第三个是行存储与列存储并存,以前老白在讨论HTAP工作负载的时候也提出过,行存储天生就对OLAP不友好,解决HTAP场景的根本还是行列混合存储。OPENGAUSS支持建表的时候选择使用行存储引擎还是列存储引擎,从而可以在OLTP系统中对历史数据做OLAP处理,部分支持HTAP的场景。

第四是连接线程池,这个功能我感觉是学习了Oracle的SHARED SERVER模式。对于短连接的应用,可以通过预置的连接线程池来实现数据库连接共享,从而避免短连接应用对数据库性能产生较大的影响。

第五是SMP并行查询增强,PG在较新的版本中也支持并行查询,并行查询的支持为数据库引擎处理较为复杂的大型查询提供了一种新的可能,随着服务器能力的不断增强,SMP并行查询的价值也越来越大。

第六是业务连续性支持,OPENGAUSS提供了多种主备复制的解决方案,并提供极致RTO复制能力,还可以通过集群管理工具支持自动化的故障切换。在2.0中还支持强数据一致性的复制模式,这对于企业级应用从ORACLE向OPENGAUSS迁移提供了有力的保障。第七是DBE_PERF Schema,DBE_PERF是我们做运维自动化工具的人的最爱,PG虽然提供一些性能视图给DBA,但是和Oracle相比还是相差较大。特别是等待事件只能统计次数,无法获得等待的平均延时,对于数据库状态分析还是支持不足。DBE_PERF解决了很多这方面的问题,让PG数据库的监控变得更简单了。第八是WSR报告,在几年前我第一次使用gaussdb 1.0的时候,就喜欢上了这种和ORACLE AWR报告十分类似的报告,因为DBE_PERF的存在,WSR报告的水准也比较高,对于从ORACLE DBA转行过来的运维人员,这个报告可能是你窥视OPENGAUSS性能的起点。时间关系我们今天就讨论到这儿。下一步我们的D-SMART要开始针对OPENGASUSS做适配,我们也将会对OPENGAUSS做各种深入的测试。如果有新的发现,我们再聊吧。

聊聊Opengauss的一些增强特性》来自互联网,仅为收藏学习,如侵权请联系删除。本文URL:http://www.hashtobe.com/270.html