openGauss和PostgreSQL深度差异对比

何亮666s

已于 2024-06-01 10:49:27 修改

阅读量3.7k

点赞数 17

文章标签： postgresql 数据库 database 数据库开发数据库架构 gaussdb

于 2024-06-01 10:43:12 首次发布

本文链接：https://blog.csdn.net/2303_79549383/article/details/139370269

版权

众所周知，openGauss是基于PostgreSQL 9.2 版本进行研发的，但是发展到现在，二者的差异越来越大。今天我就选取其中的比较重要的五个部分(Xid、检查点、页面断裂处理、内存表、流复制)带大家深入了解二者的差异。

Xid

Xid就是事务ID(tanssaction ID)，事务ID用于在数据库中标识事务操作的唯一标识符，它对于数据库事务的管理和控制十分重要。在PostgreSQL中，它是一个32位整数，递增地分配给每个新的事务。

openGauss将Xid由 int32 改为了 int64。

int32 最大的值是4294967296，大约43亿，如果遇到一些数据量很大的数据库，那么就会存在Xid被耗尽的风险。为了防止事务回卷，事务环被分为两个半圆，当前事务号过去的21亿事务属于过去的事务号，当前事务号往前的21亿属于未来的事务号，未来的事务号对当前事务是不可见的。

Postgresql有三个特殊事务号：0代表无效事务号；1表示数据库集群初始化的事务id，也就是在执行initdb操作时的事务号；2代表冻结事务id。Txid=2的事务在参与事务id比较时总是比所有事务都旧，冻结的txid始终处理非活跃状态，并且始终对其他事务可见。

PostgreSQL通过vacuum freeze的方式来循环利用这些Xid，如果发生当新老事务id差超过21亿(即2 ^ 31)的时候，事务号会发生回卷，此时数据库会报出如下错误并且拒绝接受所有连接，必须进入单用户模式执行vacuum freeze操作。

使用 int64 的Xid则不会存在这些问题，2 ^64可以说是一个天文数字，不可能被耗尽，也就不存在事务回卷宕机的风险。

但是如果引用64位的Xid也会导致一个新的问题：需要存储的Xid占用空间太大。但是事实上在openGauss中，Tuple占用的存储风险与PostgreSQL相同。这是因为openGauss在每个页的PageHeader新增了一个BaseXid用于记录64位基准Xid信息，而原本的TupleHeader还是记录32位的Xid偏移量，这样以来，由 BaseXid + Xid偏移量就可以很轻易地求出来任意的Xid，而因此牺牲掉的代价仅仅是BaseXid的8字节。

在这里插入图片描述

与此同时，vacuum freeze这个清除过期Xid的方式openGauss还是保留了。有读者可能好奇：既然已经没有事务回卷的风险了为什么还要进行这个操作呢？

这里就要引入CSN(Commit Sequence Number)的概念了， CSN是待提交事务的序列号(一个64位的无符号自增长整数)，每个事务启动时会创建一个CSN快照。

一个CSN占据8字节，如果数据库已经执行了10亿个事务，则CSN LOG所需要的空间就是 1000000000 * 8 bytes = 7.45G。这显然是十分浪费空间的，所以保留vacuum freeze的意义就是及时清理过期的CSN，最大化利用空间。

检查点

在PostgreSQL中的检查点叫全量检查点，执行时会将buffer中的所有的脏页刷到磁盘，需要在一定时间内完成刷脏页的操作，导致数据库运行性能波动较大。同时全量检查点开始时需要遍寻内存中的所有脏页，内存越大，寻找脏页的时间也越长，具体过程如下：

遍历所有BUFFER，将当前时刻的所有脏块状态改为CHECKPOINT NEEDED，来表示需要将这些脏块写出磁盘。这一步是在内存中完成的不涉及磁盘操作。
刷物理文件，从缓存中将脏块fsync到磁盘。这一步涉及磁盘操作。将标记为CHECKPOINT NEEDED的block写出到磁盘。
Checkpoint本身也会被记录到XLOG中，检查点会被信息刷出到xlog中。
更新控制文件中的检查点信息到当前位置。

这样做总体看上去没什么问题，但是在Buffer容量设置的很大的时候，那么寻找脏块的时间就会很长，并且刷入磁盘的时间也会很长。

对此openGauss新增了增量检查点功能，默认每分钟执行一次。openGauss增量检查点会小批量的分阶段的进行脏页刷盘，同时更新lsn信息，回收不需要的xlog日志。在增量检查点的机制下，会维护一个按照LSN顺序递增排列的脏页面队列，无需每次遍历内存中所有的脏页。