openGauss数据与PostgreSQL的差异对比

openGauss 数据与 PostgreSQL 的差异对比

1. 前言

openGauss数据库已发布了2.0.1版本，在线查询系统技术有限公司是一家专业致力于提供极致性能数据库服务的企业因此我们对其特性也给予高度关注由于openGauss源自PostgreSQL的发展我们对openGuss与原生PostgreSQL数据库进行了详细比较分析

2. openGauss 大功能方面的变化

基于 PostgreSQL9.2 开发的 openGauss 系列产品基本包含了 Postgres 9.4 功能。截至当前正式版本为 Postgres 13, Postgres 14 的 Beta 版本已发布。该产品仅实现了 Postgres 9.4 及以上新版本中少部分新增功能,未包含其余大部分核心功能。

openGauss的主要改动集中在将 PostgreSQL 的进程式通信转换为多线程架构。然而这两种模式在某些方面存在明显差异：首先，在处理短暂的数据传输请求时，多线程架构表现出更强的处理能力；其次，在内存管理方面存在显著的不同：所有参与操作的线程共享同一块内存空间，在这种情况下如果一个线程出现"野指针"问题（即通过指针间接指向其他内存区域），虽然不会立即报错但也可能隐藏潜在的内存篡改风险直到数据恢复或系统崩溃时才暴露出来。这种转变虽然在某些特定场景下带来了性能上的提升但同时也牺牲了一些稳定性保障措施；因此从整体效果来看这种改变并不能带来显著的优势反而可能在某些情况下带来不便。为了实现这一转变(openGauss) 采用 C++代码替代原有的 C 语言实现以提高模块间的封装性和可移植性

如今, openGauss 已经引入了线程池模块.当前尚不清楚该功能的稳定性与可靠性如何?若该功能具有良好的稳定性与可靠性,则无需依赖第三方连接池工具.

openGauss 另一个重要改进在于将事务 ID(XID)的位宽从 32位升级至 64位。这一改进确保了事务 ID 不可能发生回滚导致的系统崩溃。需要注意的是尽管 XID 已经升级到64位但过期未使用的事务 ID仍需定期清理以避免占用过多资源。具体来说 PostgreSQL 数据库在达到约20亿个事务时会自动整理旧的 XID 这一机制原本设计用于防止 XID 回滚问题而无需人工干预。因此我们可以相应地将数据库参数 autovacuum_freeze_max_age 设置为10亿来延迟对 XID 的清理操作从而延长系统的稳定运行时间

我们了解扇区容量通常为512字节，并部分SSD可采用4K规格。然而，在数据库系统中常见的是8K、16K、32K等多种规格的选择。在数据块刷入操作系统的过程中若发生故障可能导致数据块断裂问题即其中一半的数据为新存储内容另一半仍为旧数据状态导致逻辑损坏从而影响数据库的正常运行状态

MySQL采用了dual write的方式解决了该问题，在数据页发生首次变更时将整个页面记录到xLog日志中，在线提交时可快速恢复至一致状态。然而这种方法存在弊端：不仅会显著增加xLog的日志量还会对系统的性能产生一定影响因此我们建议适当延长检查点之间的间隔时间以减少这种影响。而openGauss则实现了类似MySQL的功能它在进行数据写入的同时也会将脏页存入一个共享的双写区域中这样即使发生故障也能迅速恢复至一致状态这一功能还依赖于 enable_double_write参数与增量检查点协同工作虽然如此但它仍具有一定的实际应用价值

openGauss备用库模式与PostgreSQL存在显著差异。 PostgreSQL采用拉拔式的备库机制，在主库里执行WAL日志拉拔操作至备用库里；而openGauss采用了推送式模式，在主库里执行WAL日志推送至备用库。这种转变导致备用库搭建过程更加复杂：在搭建备用库时需对主库里进行WAL日志推送配置（replconninfo1或replconninfo2），即配置replconninfoN（N=1~8）。由于仅允许配置8个参数组合，因此理论上最多只能建立8个备用库。回想从前从Oracle转向PostgreSQL的经历还令人欣慰的是无需修改主数据库设置即可部署备用系统；但换用openGauss后便如同回到了原始状态。

openGauss 内置了主备库切换功能，在提升操作便捷性的同时也带来了运行效率上的优化需求。然而这一特性使得它与数据库系统深度集成的同时也存在一定的稳定性问题。经笔者实际测试发现，在特定场景下备用库会突然从主库里断开连接并产生大量日志信息导致空间紧张情况出现

 2021-06-24 08:38:43.824 [unknown] [unknown] localhost 47427058550848 0  0 [BACKEND] LOG:  configuration file "/opt/software/openGauss

    
 /data/slave/postgresql.conf" contains errors; unaffected changes were applied
    
 2021-06-24 08:38:43.832 [unknown] [unknown] localhost 47428485064448 0  0 [BACKEND] LOG:  Connect failed.
    
 2021-06-24 08:38:43.833 [unknown] [unknown] localhost 47428485064448 0  0 [BACKEND] LOG:  Connect failed.
    
 2021-06-24 08:38:43.833 [unknown] [unknown] localhost 47428485064448 0  0 [BACKEND] LOG:  Connect failed.
    
 2021-06-24 08:38:43.833 [unknown] [unknown] localhost 47428485064448 0  0 [BACKEND] LOG:  Connect failed.
    
 2021-06-24 08:38:43.833 [unknown] [unknown] localhost 47428485064448 0  0 [BACKEND] LOG:  Connect failed.
    
 2021-06-24 08:38:43.833 [unknown] [unknown] localhost 47428485064448 0  0 [BACKEND] LOG:  Connect failed.

通过查看上述日志记录，在打印日志的过程中不带空隙地进行连续不断地输出，很快就会占用大量的存储空间。在生产环境中这种设计是一个高度危险的做法。尽管存在空间警报机制存在，在工程师介入之前有可能就已经超出了可用的空间范围。

openGauss 排除了 recovery.conf 文件。当然 PostgreSQL12 也采用了这一策略。在启动数据库时，请明确指定是备用库还是主库：

    gs_ctl start -D $GAUSSHOME/data/master -M standby

这一变化本质上是一个令人沮丧的变化。假如数据库管理员未添加‘-M standby’选项，则会导致该备用库无法正常运行，并不得不重新构建该系统以恢复正常工作状态。值得注意的是，默认情况下PostgreSQL会提供一个明确指示文件（通常是db_config），告知当前数据库是主机还是备用机；然而，在openGauss环境下则必须手动完成此配置步骤才能避免类似问题的发生。

注：主要改动包括：

1. 将"认为"改为"提出了"
2. "痛点"改为"问题"
3. "设计"改为"解决方案"
4. "切为异步模式"改为"切换为异步模式"
5. "自动连接并切为同步模式."改为"...就会自动切回同步连接状态."
6. 详细描述了故障切换后的不同情况
7. 增加了对现有方案合理性的讨论

该数据库实现了对列外数据存储的支持，并且能够实现数据压缩优化。在实际应用中需要注意可能出现的膨胀相关问题。如果操作人员缺乏专业知识或经验不足的情况下建议谨慎处理以避免潜在风险。

openGauss 在每一个库下，默认配置有一个名为 dbe_perf 的表空间，在这个表空间中包含了数百个性能视图数据。其中大部分性能视图与 PostgreSQL 内置功能相关。为了便于管理和查看数据信息的内容设置到这里面的好处在于非常高效且易于维护。

openGauss 支持了 xlog 预分配功能，在 xlog 数据库尚未填满时会预留后续的一个或多个 xlog 数据块。网上有一种说法称 PostgreSQL 无法进行预分配的 WAL 日志管理是不正确的观点。实际上 PostgreSQL 提供了一种方法可以让已使用的 WAL 日志文件重命名为预分配式的日志文件，并通过设置 min_wal_size 参数来指定预先预留的 WAL 文件数量，默认情况下该值设置为 80MB 。对于需要大量数据填充的数据库环境来说这一默认配置略显不足 ，建议将 min_wal_size 值进行适当调高以满足实际需求

openGauss 实现了增量 checkpoint，官方称让数据库更平滑。

openGauss 实现了并行恢复，默认是关闭的。

因为 openGauss 的物理备份库也会建立复制槽，在创建过程中为了避免备份库占用主数据库的空间超出容量限制，openGauss 新增了两个关键参数： enable_xlog_prune 和 max_size_for_xlog_prune。这些参数的作用是通过删除过量的日志文件来减少占用空间的需求，并以此来避免因过多的日志占用而导致主数据库空间溢出的问题。

 postgres=# show max_size_for_xlog_prune;

    
  max_size_for_xlog_prune
    
 -------------------------
    
  2147483647kB
    
 (1 row)

但默认 max_size_for_xlog_prune 设置的比较大，起不到保护作用。

openGauss 支持与 oracle 使用方法基本相同的定时任务 dbms_job。

该系统具备基础级的逻辑解码能力；然而，在完整性方面与 PostgreSQL 存在差距。该系统缺少完整版的 PostgreSQL 逻辑复制机制。

openGauss在索引支持功能上不及最新版PostgreSQL，在没有brin 索引的情况下，PostgreSQL最新版本对Btree 索引进行了较大的优化改进；然而，在这一领域上openGauss仍存在不足，并且不具备布隆过滤器功能

3. openGauss 一些硬伤

首先主要不支持分布式事务处理（DTS）功能。这也很自然地理解为这一特性在早期版本中被有意排除以减少复杂性与开销的开销问题。自 PostgreSQL 9.6 版本开始逐渐增强其分布式事务处理能力以适应现代数据库需求与应用场景的多样化需求。然而由于其基于 PostgreSQL 9.4 版本的基础架构尚不清楚 openGauss 是否计划在未来版本中引入类似的支持这一决策仍需进一步跟进与确认。

在复杂性和依赖关系方面存在明显不足。具体而言，在实际应用中发现尝试将华为云中的第三方工具进行本地编译会比本地数据库代码更加繁琐。由于其对外部依赖极为敏感且版本固定难以适应不同环境的变化，导致跨平台部署时的困难程度显著增加。转为C++后会导致代码的通用性下降，并非所有场景都能带来预期效果。此外，在实际应用中发现尝试将华为云中的第三方工具进行本地编译会比本地数据库代码更加繁琐。由于其对外部依赖极为敏感且版本固定难以适应不同环境的变化，导致跨平台部署时的困难程度显著增加。转为C++后会导致代码的通用性下降，并非所有场景都能带来预期效果。

openGauss对原生psql进行了改名优化，并命名为gSQL。这一新命令gSQL在运行时需要特别指定参数"-r"方能支持上下翻操作和智能补全功能。而当采用Oracle时，默认配置下的SQLPLUS界面常遭到批评和抱怨；后来引入rlwrap工具后虽然有所改善但仍显不够理想。转而使用PostgreSQL后发现psql所带来的命令智能补全部能极大地方便了DBA的工作流程；然而初学gSQL的用户在不了解" -r "这一参数设置时常会重蹈早期使用Oracle时的老错误，在这种情况下又不得不重新切换回类似SQLPLUS界面的操作模式

openGauss 当前对外扩展功能较为欠缺。相比之下,开放型数据库（openGauss）目前仅提供'CREATE EXTENSION'这一基础功能,并未对外公开。然而,这也促使了大量开发者致力于开发各种功能扩展,其中也不乏一些令人满意的成果——例如针对空间数据处理系统的PostGIS支持尚可满足基本需求,甚至能够实现某种程度的功能内置于数据库系统中

openGauss 未实现表继承功能，并取消了PostgreSQL的一些核心功能模块；具体来说包括诸如 pg_waldump 和 pg_xlogdump 等工具以及 pg_receivewal 功能。

相较于 PostgreSQL 数据库而言, openGauss 系统架构更为复杂一些。在该版本之前的架构中, 当内存规模低于 8GB时将无法正常启动。在该版本中对内存管理进行了优化, 现在即使使用较小的内存也能顺利运行。原生 PostgreSQL 主程序仅占约 10MB, 而相对而言 openGauss 占据约 100MB的内存空间

 [root@pg01 ~]# ls -l /usr/pgsql-12/bin/postgres

    
 -rwxr-xr-x 1 root root 7731856 Aug 12  2020 /usr/pgsql-12/bin/postgres
    
 [root@pg01 ~]#
    
 [gauss@pgtrain bin]$ ls -l gaussdb
    
 -rwxr-xr-x 1 gauss gauss 102432784 Jun  2 19:45 gaussdb

openGauss 的一个重要问题是对其进行了多个方面
的调整和修改。这些调整看似随意，
并未充分考虑现有生态系统的需求。然而，
在这一过程中 导致与众多PostgreSQL
生态系统的软件存在兼容性问题。这对用户来说确实是一个重大挑战。

虽然最大的硬伤在于缺乏全面的技术支持资料。openGauss 在对 PostgreSQL 进行诸多调整的同时，并未对技术细节进行充分说明；其官方指南基本上形同残次品，在具体操作指引方面存在严重缺失：例如在官方指南中并未详细描述如何搭建备用库配置；而安装手册仅提及使用 gs_uninstall 命令进行卸载操作这一条目；然而在极简版版本中这一命令却完全缺失；导致用户即使拥有其他版本的经验也无法顺利完成操作；且该版本连基础命令集合都显得匮乏：面对如此情况令人感到非常困惑与不满。因此 openGauss 的官方指南相比 PostgreSQL 来说显得差距巨大：与 VUE、element-ui 等知名开源软件相比更是相形见绌；与 tidb 相比则相差甚远。我们期待 openGauss 社区能更加重视官方指南的质量建设 使其实用性得到显著提升