这一章主要介绍四个概念:

数据库集群的逻辑结构

数据库集群的物理结构

表文件的内部布局

读写数据元组的方法

01

—

数据库集群的逻辑结构

Pg中的集群，也即database cluster，是由PostgreSQL服务端来管理的一组数据库(database)的集合。注意这里是数据库(database)的集合，不是数据库服务(database servers)的集合。一个PostgreSQL服务器运行在单个主机上，管理单个数据库集群。

Pg与大多数的关系型数据库一样都是由表来存储数据，一个表(table)属于某个数据库(database)，数据库(database)又同属于一个database cluster。

图1.1.数据库集群的逻辑结构

图片来源：https://www.interdb.jp/pg/pgsql01.html

在一个数据库集群中，除了有表、数据库这些数据库对象，还有比如索引、视图、函数、序列等对象，pg对这些对象统一采用对象标识符(OIDs)来管理，oid是无符号的4字节整数。数据库对象和各自的oid存储在各自的system catalogs中，比如table是存储在pg_class, 而dababase存储在pg_database中。

02

—

数据库集群的物理结构

上面我们谈的是集群的逻辑结构，也即抽象概念。现在我们聊聊的物理结构也即真实存在的结构。实际上，pg的数据库集群本质上是一个目录。目录中包含一些子目录和很多的文件。

在我们安装pg时，我们一般使用initdb的命令去初始化一个新的数据库集群。initdb 有个-D参数，通过它来指定应该存储数据库集群的目录。(initdb命令可以参考我之前的一篇博客：

https://blog.csdn.net/qq_35462323/article/details/104059818)

而集群中的database对应$PGDATA/base目录下的一个文件夹，文件夹的名称即我们上面提到的oid。

比如我的pg数据上有下面四个数据库(使用\l命令查看所有数据库)：

分别查看其oid：

select datname,oid from pg_database where datname in ('postgres','template0','template1','testextenddb');

可以发现查询到的oid是与base子目录下文件夹名是一一对应的。

图1.2.数据库集群示例

图片来源：https://www.interdb.jp/pg/pgsql01.html

那么database中的table是否也是对应base目录下的一个路径呢？答案是是的。

pg中size小于1GB的表或者索引都是存储在其所属的数据库目录下的某个文件。表和索引作为数据库对象在内部由单独的oid管理，而这些数据文件由变量relfilenode管理。

比如查看postgres数据库下的autotest_check表的oid和relfilenode

select oid,relfilenode  from pg_class where relname = 'autotest_check' limit 1;

此时，autotest_check对应文件的路径为'base/13287/21415'

注意：表和索引的relfilenode值并不总是与各自的oid匹配，因为表和索引的relfilenode值会因为TRUNCATE, REINDEX, CLUSTER等命令而改变。

在9.0或更高版本中，可以使用pg_relation_filepath函数返回某个table对应的oid路径。

比如此处的autotest_check，确实是为上面分析的'base/13287/21415'。

当表和索引的文件大小超过1GB时，PostgreSQL会创建一个名为relfilenode.1 的文件，如果新文件已被填满，则下一个名为relfilenode.2的文件将被创建，以此类推(注：在构建PostgreSQL时，可以使用选项——with-segsize来更改表和索引的最大文件大小)。

除了database对应于$PGDATA下的base文件夹，我们还要了解下，$PGDATA下的其他文件或者文件夹的含义和作用。

下表来源官方文档：https://www.postgresql.org/docs/current/storage-file-layout.html。

表1.1.$PGDATA目录下的文件和子目录的布局

03

—

表文件的内部布局

在table数据文件内部，文件是被划分为固定长度的页(或块)，默认是8kb大小。每个文件中的页面从0开始按顺序编号，这些数字称为块号。如果文件被填满，PG会在文件的末尾添加一个新的空页来增加文件的大小。

图1.3.表文件的页面布局

图片来源：https://www.interdb.jp/pg/pgsql01.html

表中的页面包含三种数据：

heap tuples: 堆元组，用于记录数据，从页面底部开始按顺序排列，tuple的内部结构将在第5章和第9章详细介绍。

line pointers: 行指针，占4个字节，保存着指向每个堆元组的指针。行指针构成一个简单的数组，它扮演元组索引的角色。每个索引从1开始按顺序编号，称为偏移量号。当一个新的元组被添加到页面时，一个新的行指针也被推到数组上以指向新的元组。

header data：Header数据，占24个字节，用于存储页面的基本信息。

源码中由PageHeaderData结构定义。该结构中主要变量：

pd_lsn: 这个变量存储该页面最后一次更改时写入的xlog记录的lsn。是一个8字节的无符号整数。

pd_checksum: 这个变量存储这个页面的检验和值。

pd_lower：指向行指针的末尾。

pd_upper:  执行最新的堆元祖的开始。

pd_special: 在表中的页面中，它指向页面的末尾。

另：行指针的末尾和最新元组的开始之间的空白称为空闲空间或空洞。

04

—

读写数据元组的方法

文章最后，介绍下写和读数据元组的方法。

首先是写元组：

假设一个表由一个页面组成，其中只包含一个堆元组。这个页面的pd_lower指向第一个行指针，而line指针和pd_upper都指向第一个堆元组。见图1.4 (a)。

插入第二个元组时，它被放置在第一个元组之后。第二行指针被压入第一行，它指向第二个元组。pd_lower指向第二行指针，而pd_upper指向第二个堆元组。见图1.5 (b)。这个页面中的其他头数据(例如，pd_lsn, pg_checksum, pg_flag)也被重写为合适的值; 更多详情见第5章和第9章。

图1.4.写数据元组

再来是读数据元组：

读数据两种典型的访问方法，顺序扫描和b树索引扫描，概述如下:

顺序扫描——通过扫描每个页面中的所有行指针，顺序地读取所有页面中的所有元组。见图1.5(a)。

B-tree索引扫描——索引文件包含索引元组，每个索引元组由一个索引键和一个指向目标堆元组的TID组成。如果您正在寻找的键的索引元组已经找到，PostgreSQL将使用获得的TID值读取所需的堆元组。例如在图1.5(b)中，得到的索引元组的TID值为' (block = 7, Offset = 2) '。这意味着目标堆元组是表中第7页的第2个元组，因此PostgreSQL可以读取所需的堆元组，而无需在页面中进行不必要的扫描。

图1.5.读数据元组