在关系型数据库领域，PostgreSQL以其高度可扩展性、标准兼容性和强大的内部设计而备受开发者青睐。近日，一篇题为《Reading the internals of Postgres: Database cluster, databases, and tables》的技术文章引发社区热议，作者以源码和文件系统为线索，层层拆解了Postgres最核心的三个层级——集群、数据库与表。本文基于该文章的核心观点，结合业界实践，为您呈现Postgres底层的“骨架”逻辑。
从集群开始：一个实例的物理边界
PostgreSQL中的“数据库集群”并非像商业数据库那样指多台服务器组成的分布式环境，而是一个由单个Postgres服务器实例管理的所有数据库的集合。在操作系统层面，一个集群对应一个数据目录（通常由initdb创建），其中包含PG_VERSION、postgresql.conf、pg_hba.conf等配置文件，以及最重要的base子目录——所有用户数据库的实际数据都存储在此。
文章指出，集群实例启动时会加载共享内存与系统缓存，并启动一组后台进程（如检查点进程、WAL写入器、统计收集器等）。每个集群仅有一个postmaster守护进程，它负责监听客户端连接、fork出后端进程。值得注意的是，同一个物理服务器上可以运行多个集群，只需指定不同的数据目录和端口即可——这在多租户场景下非常实用。
数据库：隔离的数据空间
在集群内部，数据库是最顶层的逻辑隔离单元。每个数据库都有自己的系统目录（pg_catalog）、事务ID空间、角色集合以及表空间映射。文章通过分析pg_database系统表揭示了关键机制：每创建一个数据库，实际上是对模板数据库（template0或template1）的物理拷贝。base目录下的每个子目录（OID命名）对应一个独立的数据库，其中包含了所有该数据库内对象的文件。
有意思的是，Postgres通过OID（对象标识符）来管理数据库的元数据。例如，数据库的OID可以在pg_database表的oid列中查到，而该OID就是base目录下子文件夹的名称。这种设计使得文件系统与数据库元数据形成一一映射，极大简化了I/O路径。作者还举例说明了如何通过系统函数pg_database_size()反向追踪到目录的存储占用，让调优者能精确定位空间瓶颈。
表：从逻辑关系到物理文件
表的内部结构是本文最出彩的部分。在Postgres中，一张表对应一个或多个物理文件，文件命名规则为“表所在表空间_OID”加上后缀（如1代表主分支，vm代表可见性映射，fsm代表自由空间映射）。这些文件被划分为固定大小的页（默认8KB），页内存储的是元组。
文章详细解读了页面的布局：页头（PageHeaderData）包含页的LSN、空闲空间起始位置、特殊数据区等信息；之后是行指针数组（ItemIdData），每个指针指向一个元组的实际偏移量；元组中则包含隐藏的系统列（如ctid、xmin、xmax等），用于实现MVCC（多版本并发控制）。作者特别强调，Postgres不会在原地更新元组，而是通过插入新版本并标记旧版本为“死亡”来实现事务隔离，因此表文件极易产生膨胀——这正是VACUUM命令存在的意义。
此外，索引也是以B-Tree、Hash等结构存储在独立文件中，每个索引对应一个relfilenode。文章通过pg_class、pg_attribute和pg_index系统表，展示了如何从SQL层面反向推导出物理文件路径，揭示了“查询规划器→执行器→存储引擎”这一完整调用链。
结语：理解内核才能驾驭系统
PostgreSQL的优雅之处在于，它将数据库集群、数据库与表这三个概念通过OID和文件系统紧密耦合，同时保持逻辑上的清晰边界。《Reading the internals of Postgres》一文的价值不仅在于讲解“是什么”，更在于展示“为什么这样设计”——例如将WAL与数据文件分离、使用可见性映射加速扫描、通过自由空间映射降低碎片率。对于DBA和高级开发者而言，理解这些底层细节，意味着能够在出现性能问题时从系统表、进程视图甚至文件层面进行诊断，而非盲目依赖黑盒调优。
随着PostgreSQL 17的发布和新特性（如增量备份、逻辑复制增强）的加入，内核层面的知识愈发重要。无论是分布式改造、存储引擎定制，还是日常运维诊断，了解集群、数据库与表的底层映射关系，都是每一位Postgres用户走向成熟的必经之路。