解决文件存储难题 openGauss隆重推出段页式特性

现代社会信息数据爆炸式增长，工业界业务需求纷繁复杂。数据存储的数据量，建表数量也都不断增长。openGauss通用的普通表，每个数据表对应一个逻辑逻辑上的大文件（最大32T），该逻辑文件又按照固定的大小划分多个实际文件存在对应的数据库目录下面。所以，每张数据表随着数据量的增多，底层的数据存储所需文件数量会逐渐增多。同时，openGauss对外提供hashbucket表、大分区表等特性，每张数据表会被拆分为若干个子表，底层所需文件数量更是成倍增长。由此，这种存储管理模式存在以下问题：

1. 对文件系统依赖大，无法进行细粒度的控制提升可维护性；

2. 大数据量下文件句柄过多，目前只能依赖虚拟句柄来解决，影响系统性能；

3. 小文件数量过多会导致全量build、全量备份等场景下的随机IO问题，影响性能；

为了解决以上问题，openGauss引入段页式存储管理机制，类似于操作系统的段页式内存管理，但是在实现机制上区别很大。

一、 段页式实现原理

在段页式存储管理下，表空间和数据文件以段(Segment)、区(Extent)以及页（Page/Block）为逻辑组织方式进行存储的分配和管理。如下图所示。具体来说，一个database(在一个tablespace中)有且仅有一个段空间（segment space），实际物理存储可以是一个文件，也可以拆分成多个文件。该database中所有table都从该段空间中分配数据。所以表的个数和实际物理文件个数无关。每个table有一个逻辑上的segment，该table所有的数据都存在该segment上。每个segment会挂载多个extent，每个extent是一块连续的物理页。Extent的大小可以根据业务需求灵活调整，避免存储空间的浪费。

图 1 段页式存储设计示意图

段页式文件可以自动扩容，不需要用户手动指定，直到磁盘空间用满或者达到tablespace设置的limit限制。段页式存储不会自动回收磁盘空间。当某些数据表被删除之后，其在段页式文件中占据的空间，会被保留，即段页式文件中会存在一些空洞，磁盘空间没有被释放。这些空洞会被后面新扩展或者创建出来的表重用。用户如果确定不需要重用这些空洞，可以手动调用系统函数，来进行磁盘空间的回收，释放磁盘空间。

内部实现上，每个segment 对应原先页式存储的一个物理文件。比如每个分区表、每个hashbucket表的一个bucket，都会有一个单独的segment。每个segment下面会挂载多个extent，每个extent在文件中是连续的