[[420955]]

一、概述

PostgreSQL是一個功能非常強大的、源代碼開放的客戶/服務器關系型數(shù)據(jù)庫管理系統(tǒng)(RDBMS)，PostgreSQL被業(yè)界譽為“先進的開源數(shù)據(jù)庫”，支持NoSQL數(shù)據(jù)類型(JSON/XML/hstore)，主要面向企業(yè)復雜查詢SQL的OLTP業(yè)務場景，提供PostGIS地理信息引擎、阿里云自研多維多模時空信息引擎等。

本文著重介紹PostgreSQL的數(shù)據(jù)目錄，其中保存著配置文件、數(shù)據(jù)文件、事務日志和WAL日志等重要文件，所有客戶創(chuàng)建的數(shù)據(jù)文件和初始配置文件都可以在數(shù)據(jù)目錄中找到，因此數(shù)據(jù)目錄是重要的客戶價值所在。

二、名詞

1.OID

數(shù)據(jù)庫對象是數(shù)據(jù)庫存儲或引用的數(shù)據(jù)結構體，數(shù)據(jù)庫本身也是數(shù)據(jù)庫對象，同時包括表、索引、視圖、序列和函數(shù)等。Object ID是數(shù)據(jù)庫對象的唯一標識符，保存在無符號四字節(jié)的整形變量中，所有數(shù)據(jù)庫對象各自對應一個OID。PostgreSQL有兩個視圖各司其職，分別保存著不同類別的OID，其中pg_database保存數(shù)據(jù)庫本身對象的OID，pg_class保存表、索引和序列等對象的OID。

2.Relation

關系代表非數(shù)據(jù)庫本身的數(shù)據(jù)庫對象，包括表、視圖、索引和toast等，不包括數(shù)據(jù)庫本身。

3.MVCC

Multi-Version-Concurrency-Control是一種并發(fā)控制機制，數(shù)據(jù)庫引擎根據(jù)不同的事務隔離級別，通過查詢事務快照和事務提交日志來完成元組的可見性檢查。如果希望理解數(shù)據(jù)庫機制原理，MVCC是必不可少的學習知識。

4.Page

數(shù)據(jù)庫文件在Linux平臺被劃分為默認8K固定長度的page進行管理，通過啟動參數(shù)BLCKSZ可以預設page的大小。如果page設低了，相同數(shù)據(jù)量的文件需要分裂成更多的page，IO次數(shù)和索引分裂次數(shù)都會增加，性能會降低較多;如果page設高了，page內(nèi)部的數(shù)據(jù)檢索效率會降低，性能一樣會降低不少，一般來說8K和16K對于數(shù)據(jù)庫系統(tǒng)來說是最優(yōu)解。

三、數(shù)據(jù)目錄

數(shù)據(jù)目錄默認在/var/lib/pgsql/data下，支持使用環(huán)境變量$PG_DATA管理。下圖所示是數(shù)據(jù)目錄的一級結構，后續(xù)會重點介紹具有代表性的重要文件和目錄，比如base、pg_xact等。

四、base

1.概述

base目錄存儲用戶創(chuàng)建的數(shù)據(jù)庫文件，及隸屬于用戶數(shù)據(jù)庫的所有關系，比如表、索引等。

2.一級目錄

目錄結構分為兩級，第一級結構如下圖所示，一級目錄名是用戶數(shù)據(jù)庫對象的OID，1代表的是postgres數(shù)據(jù)庫，一級目錄內(nèi)的二級子文件都是隸屬于該數(shù)據(jù)庫對象的關系，包括表、索引、視圖等。

3.二級文件

二級子文件如下圖所示，存儲著某個數(shù)據(jù)庫內(nèi)的所有關系，包括表、索引、視圖等，這里以postgres數(shù)據(jù)庫目錄示例。二級子文件分為三大類，第一類是以關系OID命名的主數(shù)據(jù)文件，第二類是文件名以_fsm結尾的空閑空間映射文件，第三類是文件名以_vm結尾的可見性映射文件。

4.主數(shù)據(jù)文件

主數(shù)據(jù)文件存儲隸屬于對應數(shù)據(jù)庫下的數(shù)據(jù)庫關系文件，包括數(shù)據(jù)、索引等，客戶最重要的業(yè)務數(shù)據(jù)便是存儲在主數(shù)據(jù)文件中。

當關系文件大小低于RELSEG_SIZE × BLCKSZ時，數(shù)據(jù)庫引擎創(chuàng)建名稱為pg_class.relfilenode的單文件，反之會切分為名稱如pg_class.relfilenode.segno的多個文件。單個關系文件內(nèi)部被劃分為默認8K固定大小的多個page并存儲在磁盤上，8K可以在initdb時通過BLCKSZ參數(shù)修改配置。主數(shù)據(jù)文件寫入時，會先將元組數(shù)據(jù)從行指針數(shù)組的底部開始堆疊，直到空間耗盡。

用戶通過SQL查詢到的單行數(shù)據(jù)記錄對應單個元組(tuple)，因為MVCC機制的原因，元組可能是無法查詢到舊版本數(shù)據(jù)，也可能是活躍的新版本數(shù)據(jù)，舊版本數(shù)據(jù)會在未來的某個時刻被清理。當查詢沒有命中索引觸發(fā)順序掃描時，數(shù)據(jù)庫引擎順序掃描page的行指針讀取到元組，反之如果命中B樹索引，引擎會通過索引文件的元組，通過索引鍵的TID值讀取到元組。

下圖是主數(shù)據(jù)文件的層級結構。

下表格是上圖所示page內(nèi)部結構的元數(shù)據(jù)信息。

下表格是上圖所示tuple內(nèi)部結構的元數(shù)據(jù)信息。

5.FSM

FSM是空閑空間映射文件，記錄著heap和index的每個page的空閑空間信息，有利于快速定位到有充足空閑空間的page以便存儲tuple，如果沒有定位到則需要擴展新page。除了Hash Index文件沒有FSM文件，其他heap和index都需要FSM文件。

總體上，F(xiàn)SM采用3-4級多叉樹的結構組織FSM page，單個FSM page內(nèi)部采用完全二叉樹的結構進行管理，高級別FSM page的葉子節(jié)點關聯(lián)低級別的FSM page，低級別FSM Page的葉子節(jié)點存儲著heap、index page的可用空間數(shù)目，而非葉子結點依次存儲葉子節(jié)點的最大可用空間數(shù)目，每個節(jié)點占用1個字節(jié)。

6.VM

VM是可見性映射文件，記錄著每個heap page的可見性信息，因此index page并沒有vm文件。一方面它可以提高vacumn的執(zhí)行效率，另一方面通過vm文件可以感知到page內(nèi)的元組是否全部可見，如果全部可見的話，查詢引擎查詢索引元組直接獲取到數(shù)據(jù)即可，不必再訪問數(shù)據(jù)元組檢查可見性，減少了回表次數(shù)，極大提升了查詢的效率。

VM采用位圖的結構存儲可見性信息，每個heap page只在vm文件中存儲2位，第一位代表元組是否全部可見，第二位代表元組是否全部被凍結。

#define VISIBILITYMAP_ALL_VISIBLE  0x01 
#define VISIBILITYMAP_ALL_FROZEN  0x02 

五、global

1.概述

global目錄存儲pg_control及數(shù)據(jù)庫集群維度的數(shù)據(jù)庫及其關系，非客戶維度的數(shù)據(jù)，例如pg_database、pg_class等。目錄內(nèi)的文件結構和base是一致的。

global目錄文件結構如下圖所示。

2.pg_control

pg_control文件記錄數(shù)據(jù)庫集群控制信息，包括initdb初始化、WAL和checkpoint的信息。

六、pg_wal

1.概述

pg_wal是WAL機制中的wal日志存儲目錄。PG10及之后的高版本改目錄名為pg_wal，10之前目錄名稱是pg_xlog。

2.WAL機制

Write-Ahead-Logging：日志先行機制。數(shù)據(jù)變更優(yōu)先寫入日志文件，事務失敗則變更記錄被忽略，事務成功再選擇合適時機寫入數(shù)據(jù)文件，數(shù)據(jù)的刷盤速度慢于日志刷盤速度。當數(shù)據(jù)庫系統(tǒng)崩潰后，引擎會從上一次成功的checkpoint點開始依次重放wal記錄，如果LSN>pd_lsn則重放wal記錄，反之跳過，確保數(shù)據(jù)記錄恢復到崩潰前的狀態(tài)。

3.文件結構

4.wal segment

wal段文件存儲著數(shù)據(jù)庫行記錄明細，每一條記錄明細都是服務于數(shù)據(jù)庫恢復操作的，確保前后數(shù)據(jù)一致。首先針對數(shù)據(jù)的任意一次修改操作均被記錄在wal段文件中，包括insert、update和delete，其次系統(tǒng)的一些管理行為也會被記錄在wal段文件中，例如事務提交和vacuum等行為。

wal段文件命名形如00000001 00000001 00000092，文件名共24位，前8位是timeline，中間8位是logid，后8位是logseg，logseg的前6位始終是0，后2位是lsn的前2位。根據(jù)wal段文件名的最后2位，wal記錄根據(jù)對應的LSN分別記錄在不同的wal段文件中。

5.history

.history文件內(nèi)容包括原.history文件，當前時間線切換記錄和切換原因，作用于數(shù)據(jù)庫的時間點恢復行為。當數(shù)據(jù)庫引擎從多個時間線的備份中恢復時，數(shù)據(jù)庫從.history文件中找到從pg_control的start_timeline到指定的recovery_target_timeline間的所有wal段文件進行恢復。

6.archive_status

archive_status是wal段文件的備份目錄，包括.ready和.done文件。超出wal_keep_segments數(shù)目限制的wal日志會在archive_status目錄內(nèi)被打標，歸檔操作完成后被進一步移除。

7.ready

.ready是同名wal段文件在archive_status目錄內(nèi)的標記文件，代表該wal段文件可被歸檔。wal段文件在數(shù)據(jù)目錄中的存儲文件數(shù)量是有上限的，一般通過wal_keep_segments參數(shù)來約束，因此數(shù)據(jù)庫引擎在wal段文件個數(shù)達到上限后會在archive_status目錄內(nèi)增加可移除的wal段文件的標記文件，文件名是原wal段文件名后增加.ready后綴，等待歸檔工具進行歸檔。

8.done

.done是同名wal段文件在archive_status目錄內(nèi)的標記文件，代表該wal段文件已被歸檔，可以被清理。數(shù)據(jù)庫引擎默認通過archive_command命令對.ready文件進行歸檔，歸檔成功與否取決于archive_command命令返回true還是false，當archive_command返回true時，代表與.ready文件同名的wal段文件已被歸檔，引擎再將該文件的擴展名重命名為.done，等待數(shù)據(jù)庫引擎在下一次的checkpoint時進一步清理原wal段文件。

七、pg_xact

1.概述

pg_xact是事務提交日志(Commit Log)的存儲目錄，事務提交日志默認256KB，文件名形如NNNN，系統(tǒng)初始化后從0000開始遞增至FFFF。PG 10及之后的高版本改目錄名為pg_xact，10之前目錄名稱是pg_clog。

下圖是pg_xact目錄下的clog文件，027E前的文件因為事務已被凍結，所以被vacuum清理完畢。

2.Commit Log

事務提交日志存儲數(shù)據(jù)庫的單個事務運行狀態(tài)。Commit Log由共享內(nèi)存中一組8KB的page組成，每個page包含一列數(shù)組，每個數(shù)組元素包含XID和該事物的實時狀態(tài)。當page不足時，創(chuàng)建新的page來存儲新的事務。

八、配置文件

1.postgresql.conf

postgresql.conf文件存儲著配置文件的位置、資源限制、集群復制等參數(shù)數(shù)據(jù)，是數(shù)據(jù)庫運行時最重要的配置文件。

2.postgresql.auto.conf

postgresql.auto.conf文件存儲著數(shù)據(jù)庫的全局配置參數(shù)，數(shù)據(jù)庫引擎在啟動時加載postgresql.auto.conf文件后，覆蓋postgresql.conf文件中已有的配置，形成最終的數(shù)據(jù)庫啟動配置。

3.pg_hba.conf

pg_hba.conf文件負責客戶端的連接和認證，起到防火墻的作用，格式是：TYPE / DATABASE / USER / ADDRESS / METHOD。

九、總結 

本文從肉眼可見的數(shù)據(jù)目錄及其子文件開始展開，由淺入深直到不可見的源碼結構體維度，詳細介紹了數(shù)據(jù)目錄及其子文件的結構和作用。大家通過了解數(shù)據(jù)目錄的文件體系結構，能夠?qū)ostgreSQL數(shù)據(jù)庫全貌有個總體概覽，無論是日常運維、內(nèi)核研發(fā)，還是業(yè)務開發(fā)，這些都是必須掌握的基礎知識。