openGauss数据库段页式与代码走读

@TOC(目录)

一些概念

段页式存储是一种在数据库系统中常见的存储管理方式，它将数据库中的存储空间按照一定的规则组织成不同的段（segments）来进行管理。

所有的表都在一个文件中，解决文件句柄过多，磁盘存在上限等问题。

扩展区块（Extent）（物理概念）

一段连续的物理存储空间，用于存放存放部分数据的容器。

一共有四种尺寸64K、1M、8M、64M。正好在段空间内的2 3 4 5文件内存放。

里边存放的就是page。

段页式存储文件（段空间）(物理概念)

[carrot@dev-openeuler-arm 15797]$ ll 
total 147M
-rw------- 1 carrot carrot 128M Feb 23 11:02 1
-rw------- 1 carrot carrot 128M Feb 23 11:02 2
-rw------- 1 carrot carrot 128M Feb 23 11:02 2_fsm
-rw------- 1 carrot carrot 128M Feb 23 11:02 3
-rw------- 1 carrot carrot 128M Feb 23 11:02 3_fsm
-rw------- 1 carrot carrot 128M Feb 23 11:02 4
-rw------- 1 carrot carrot 128M Feb 23 11:02 4_fsm
-rw------- 1 carrot carrot 128M Feb 23 11:02 5
-rw------- 1 carrot carrot 128M Feb 23 11:02 5_fsm
-rw------- 1 carrot carrot 4.0K Feb 23 10:59 pg_filenode.map
-rw------- 1 carrot carrot 4.0K Feb 23 10:59 pg_filenode.map.backup
-rw------- 1 carrot carrot    4 Feb 23 10:59 PG_VERSION

其中的 1 ~ 5 就是段页式文件，是物理的文件。

1号文件存放的是segmentHeader，不存放数据。

2 ~ 5 几个物理文件之中存放的是一个个的extent(扩展块)，不同文件存放不同尺寸的扩展块(Extent)，同一个文件之中的扩展块可能来自于不同的表。。

文件空间不够的话，每次会扩展128M。

段（Segment）(逻辑概念)

段页式中，一个段就是一个表。

一个表由多个扩展区块组成，扩展逻辑如下：

 尺寸     数量    容量   | 单extent页面容量  页面容量    累计容量   累计页面容量 
[ 64K ] *  16个 = 1M     | 8                 128         1M         128          
[ 1M  ] * 127个 = 127M   | 128               16256       128M       16384        
[ 8M  ] * 112个 = 896M   | 1024              114688      1GB        131072       
[ 64M ] *  ∞ 个 =        | 8192                                                 

当向表中插入数据但空间不足时，每次会扩展一个Extent，先扩展的extent大小为64K，16个之后为1M，最大是64M…先小后大。

因此我们知道一个page的页号，就可以很轻易地算出来属于那个extent，且这个extent的尺寸是多大。

注意：每个表最大支持是32TB，因此64M extent并不是无穷的。

SegmentHeader 与 BMT（Block Map Tree）

一个表由多个extent组成，这些extent之间物理上是不连续的，因此我们需要有一个结构来记录表上都有哪些extent，这个结构便是BMT。

一个表会有一个BMT，用于存放自己的extent列表。

从上边的扩展逻辑可以看出，实际上只需要一个int数组即可。已知一个表最大是32TB，可以算出一共需要大概513K个extent，每个extent只需要一个uint来作为ID即可。

513K个uint一共占用2M+空间。但是数据库页面只有8K，因此这里并不能是一个连续的物理地址。

typedef blockNumber extentPos;               页面号也可以直接作为extent的位置，也可以认为就是extetId。（代码中没有这个typedef，都用的blockNumber，但这么理解好理解）


// SegmentHeader，表的元数据，占用一个页面刚好
struct SegmentHeader {

    extentPos level0_slot[1255];             能直接存在当前页面的extentid最多只有
    blockNumber level1_slots[256];           剩下的存不下的，存在其他的页面内，这里存放页面的id。
    
    blockNumber fork_head[];                 其他fork的SegmentHeader所在的页面
};


// 能存放2000的extentid，大小刚好8000B，占用一个页面刚好。
struct BMTLevel0Page {
    uint64 magic
    extentPos slots[2000];
}

可以看到这里几个结构体的主要思想之一就是，每个结构体刚好一个页面。所以无论是extent、SegmentHeader、BMTLevel0Page，其位置都可以通过页面号来确定，也就是blockNumber。

吐槽：BMT就是level0、level1组成的东西，不过不得不吐槽，这个BMT叫树属实有点不形象了，这个level1的名字取的也让人非常迷惑。

与其叫树，不如叫一个二维数组，这样子level0 1还稍微形象点。或者叫做组列表，level1就是组。

如何根据BlockNumber找到页面具体位置

假如我们现在需要找BlockNumber为185172567的页面。

1、pg_class内获取SegmentHeader所在的页面id，读取文件1获得SegmentHeader

2、计算185172567页面所在的extent是哪一个

pageid = 185172567

已知16个64Kextent共可存储128个页面，累计到127个1Mextent可存储16384个页面， 累积到112个8Mextent共可存储131072页面。

pageid > 131072, 因此可知这个页面是在64M的extent之中，也就是在段页式文件5之中。

（pageid - 131072） / 8192 = 22588 ... 599    可以知道他在第22588个64Mextent中的599个页面

16 + 127 + 112 + 22588 = 22843，第22588个64Mextent中也就是第22843个extent

SegmentHeader中直接存储的只有前1255个extentPos，因此我们需要通过level1去寻找。

（22843 - 1255 = 21588） / 2000 = 10 ... 1588；    每个BMTLevel0Page存储2000个extentPos，因此他在level1_slot[10]所标识的组里，是第1588个


根据SegmentHeader.level1_slots[10]找到对应的页面，类型转换为BMTLevel0Page


extentPos extentpos = BMTLevel0Page.slots[1588]


综上可知，BlockNumber为185172567的页面所在的位置为：

    段页式文件5，偏移量为extentpos的extent，里边的第599个页面。
    在代码里，这个位置使用结构体SegPageLocation来表示，里边的三个变量就是上面三个变量。

或者这里随手写了个段页式计算器，一个html，计算是js完成的，代码保存到本地然后浏览器打开即可。
一个随手写的计算器