Postgresql与openguass对比

背景介绍

PostgreSQL是世界上最先进的开源关系型数据库，以其强大的功能、稳定性和可扩展性著称。而openGauss是华为公司于2020年6月30日开源的数据库系统，内核基于PostgreSQL 9.2.4版本演进而来。值得注意的是，PostgreSQL 11.3版本拥有290个数据库参数，而openGauss当前拥有515个数据库参数，每个参数对应一个数据库内核功能，这表明华为对PostgreSQL内核进行了大量的改造和增强。

内核增强对比

1. 事务ID (XID) 处理

• **PostgreSQL**：使用32位整数作为事务ID，最大约43亿，可能面临耗尽风险，需要通过vacuum freeze进行循环利用。

• **openGauss**：将事务ID扩展为64位，实现了XID不可耗尽的特性，彻底解决了事务回卷问题，同时保留了vacuum freeze机制用于清理过期的CSN。

2. 检查点机制

• **PostgreSQL**：采用全量检查点，执行时会将buffer中所有脏页刷到磁盘，导致性能波动大。

• **openGauss**：支持增量检查点，通过小批量分阶段的方式进行脏页刷盘，提升了性能稳定性。

3. 页面断裂处理

• **PostgreSQL**：使用full page write解决页面断裂问题，但会大大增加xlog日志量。

• **openGauss**：实现了类似MySQL的双写（double write）机制，写数据块的同时将脏页写到共享双写空间中，性能更优。

4. XLOG预分配

• **PostgreSQL**：XLOG日志在写满后才会分配下一个日志，可能导致性能抖动。

• **openGauss**：实现了XLOG预分配功能，在日志未写满时就分配下一个日志，提高了性能稳定性。

性能优化

1. 线程池架构

• **PostgreSQL**：采用进程模型，每个连接对应一个进程。

• **openGauss**：改为线程模型，支持线程池，实现了session和thread之间的解耦，提高了线程利用率，支持上万并发。

2. NUMA架构优化

• **openGauss**：通过NUMA绑核减少跨核内存访问时延，提升CPU利用率，改善多线程同步性能。

3. 并行回放

• **openGauss**：支持备机并行回放日志，提高复制性能。

4. 内存表

• **openGauss**：支持基于LLVM的内存查询引擎，支持高吞吐、低延迟访问。

5. 列存表优化

• **openGauss**：支持列存表，并优化了列存表的并发插入性能，解决了插入时一行数据占一个CU导致空间膨胀的问题。

高可用特性

1. 最大可用模式

• **PostgreSQL**：在一主一从同步模式下，备库宕机会导致主库挂起，同步模式不会自动降级。

• **openGauss**：支持最大可用模式（most_available_sync），当备机断连时会立刻切换为异步模式，备机恢复后自动恢复同步模式。

2. 流复制自动创建物理复制槽

• **openGauss**：搭建主从流复制环境后会默认自动创建物理复制槽，防止备库需要的XLOG被主库删除。

3. 主库XLOG容量限制

• **openGauss**：通过max_size_for_xlog_prune参数控制XLOG最大值，防止主备长期断连导致主库目录爆满。

4. 主备从与一主多备架构

• **openGauss**：支持主备从模式和一主多备模式，更灵活的高可用架构选择。

安全特性

1. 客户端密码认证增强

• **PostgreSQL**：默认密码加密算法为MD5。

• **openGauss**：增强为SHA256，提高了安全性。

2. 流复制线程连接认证

• **openGauss**：主备复制线程连接默认需要进行SSL认证，增强安全性。

3. Schema权限控制

• **openGauss**：对public schema进行安全增强，默认普通用户没有权限在public下创建对象。

不足之处

1. 功能缺失

• **openGauss**：缺少pg_stat_replication视图，无法查看主从延迟信息。

• **openGauss**：不支持PostgreSQL的并行功能。

• **openGauss**：没有postgresql.auto.conf，无法使用ALTER SYSTEM SET配置参数。

• **openGauss**：不支持PITR（基于时间点的恢复）。

2. 插件生态

• **openGauss**：不支持PostgreSQL插件，这是一个极大的劣势，失去了PostgreSQL强大的扩展性。

3. 社区成熟度

• **openGauss**：社区刚刚起步，活跃度不高，周边工具（如高可用工具、数据同步工具）不完善。

4. 复杂度与通用性

• **openGauss**：编译过程复杂，依赖项多且版本固定，跨平台编译难度大，平台通用性差。

应用场景

PostgreSQL适用场景

1. 需要广泛插件支持的应用

2. 跨平台部署要求高的场景

3. 对社区和生态系统依赖性高的场景

4. 分析类应用（依赖并行查询）

openGauss适用场景

1. 需要极高并发支持的应用（线程池架构）

2. 大规模交易处理系统（NUMA优化、增量检查点）

3. 对主从高可用要求严格的场景（最大可用模式）

4. 列存储分析需求（列存表优化）