openGauss数据与PostgreSQL的差异对比

openGauss 数据与 PostgreSQL 的差异对比

1. 前言

openGauss 数据库已经发布 2.0.1 版本了，中启乘数科技是一家专业的专注于极致性能的数据库服务提供商，所以也关注 openGauss 数据库的特性。因为 openGauss 是从 PostgreSQL 发展出来的，所以我们详细讲解对比一下 openGauss 与原生 PostgreSQL 数据库的对比。

2. openGauss 大功能方面的变化

openGauss 是基于 PostgreSQL9.2 版本开发的，基本包括了 PostgreSQL9.4 的功能。目前 PostgreSQL 正式版本已经到 13 了， 14 的 beta 版本也发布了。openGauss 只把 PostgreSQL9.4 之后的新版本的极少数功能移植进来了，绝大多数功能都没有纳入。

openGauss 最大的变化就是把 PostgreSQL 的进程模式改成了线程模式，当然这两个模式其实各有优缺点。线程模式对短连接有优势，比进程模式的数据库可以承担更大的并发短请求，但线程模式也有明显的缺点，所有的线程共享内存，如果一个线程的的野指针把别人的内存改了，不会报错，一时半会可能还发现不了，极端情况下会导致数据损坏而不被发现。所以说这个改变不能说有什么明显的好处，某些情况下可能还是一个退步。为了改成线程模式，openGauss 的把 C 语言的源代码改成了 C++。C++的好处是容易封装，坏处是移植性降低了。

当然 openGauss 增加了线程池的功能，目前还不清楚这个功能是否稳定可靠。如果稳定可靠可以不使用第三方的连接池工具了。

openGauss 另一个变化是把事务 ID(XID)从 32bit 改成了 64bit，64bit 的 xid 的好处是永远不可能耗尽，好处是我们永远不用担心会发生 xid 回卷宕机的风险。注意，虽然 xid 改为了 64bit，但是过期的事务 ID 依旧需要清理。实际上 PostgreSQL 数据库默认达到 2 亿事务就强制整理，而 32bit 的 xid 可以达到 20 亿，所以我们实际上可以修改 autovacuum_freeze_max_age 为 10 亿来推迟对 xid 的整理。

我们知道磁盘扇区大小是 512 字节，一些 SSD 可以是 4k 大小，而数据库一般是 8k/16k/32k，一个数据库数据块刷到操作系统的过程中可能发生宕机造成这样有块断裂问题，即块中一半是新数据，另一半还是旧数据，这就是块的逻辑损坏，这可能导致数据库无法启动。

MySQL 通过双写 double write 来解决这个问题&#x