TimescaleDB 超表 物理表解释

一、PostgreSQL 基础存储逻辑(TimescaleDB 继承此机制)

TimescaleDB 是 PostgreSQL 的扩展,因此数据文件的底层存储逻辑完全继承 PostgreSQL。在 PostgreSQL 中:

  • 每个数据库对应 $PGDATA/base/<数据库 OID>目录(截图中路径为 /usr/local/pgsql/data/base/1723017230是数据库的 OID)。

  • 每个表(包括超表、普通表、分块后的 Chunk)对应一个关系文件节点(relfilenode)​ ,存储在数据库目录下的子目录中,子目录名即 relfilenode(如截图中的 1892518917等)。

二、TimescaleDB 超表的"物理分块"特性

TimescaleDB 超表的核心是水平分块(Chunking)​ ​:超表会被按时间范围(或其他维度)拆分为多个Chunk,每个 Chunk 是一个独立的 PostgreSQL 表(在底层存储上与普通表无差异)。

因此,超表的"物理存储"本质是多个 Chunk 对应的 PostgreSQL 表的集合,每个 Chunk 都有自己的 relfilenode 和数据文件。

三、数据文件类型及作用(以截图为例)

截图中展示了多个文件,核心类型包括主数据文件_fsm文件、_vm文件,以下逐一解释:

1. 主数据文件(如 1892518917等)
  • 作用 ​:存储表的行数据,是表的核心存储载体。

  • 结构​:

    • PostgreSQL 页面大小默认 8KB,数据文件按"页面"组织,每个页面存储若干行数据。

    • 单个数据文件最大为 1GB(可通过参数调整),超过 1GB 时会自动生成分片文件 ​(如 18925.118925.2...),每个分片仍为 1GB 内。

  • 示例 ​:截图中 18925大小为 104.31MB,是某张表(或 Chunk)的主数据文件,存储该对象的实际行数据。

2. _fsm文件(如 18925_fsm18917_fsm
  • 全称​:Free Space Map(空闲空间映射)。

  • 作用 ​:跟踪数据文件中哪些页面有空闲空间,帮助 PostgreSQL 高效分配存储(如 INSERT 时快速找到有足够空间的页面,避免频繁页面分裂)。

  • 特性​:

    • 每个主数据文件对应一个 _fsm文件。

    • 文件大小固定为 8KB(与 PostgreSQL 页面大小一致,按"页面"管理空闲空间信息)。

3. _vm文件(如 18925_vm18917_vm
  • 全称​:Visibility Map(可见性映射)。

  • 作用 ​:记录数据文件中哪些页面的所有元组对所有事务可见​(即已提交且未被后续事务修改)。

  • 特性​:

    • 每个主数据文件对应一个 _vm文件。

    • 加速 VACUUM(跳过无需清理死元组的页面)和查询(跳过需检查可见性的页面),提升性能。

    • 文件大小固定为 8KB(同页面大小)。

四、TimescaleDB 超表的文件"映射关系"

超表 → 多个 Chunk(每个 Chunk 是 PostgreSQL 表)→ 每个 Chunk 对应一套数据文件(主数据文件 + _fsm+ _vm+ 可能的分片文件)。

例如:

  • 超表 metrics按时间分块为 chunk_2023Q1chunk_2023Q2...

  • chunk_2023Q1对应 relfilenode 18925,其文件为 18925(主数据)、18925_fsm18925_vm...

  • chunk_2023Q2对应 relfilenode 18917,其文件为 18917(主数据)、18917_fsm18917_vm...

五、额外补充:元数据与索引文件

除了上述数据文件,TimescaleDB 超表还涉及:

  • 系统表元数据 ​:超表的定义(如分块策略、维度列)存储在 _timescaledb_catalog模式的系统表中(如 hypertableschunks)。

  • 索引文件​:超表的索引(如时间索引、哈希索引)也以独立 PostgreSQL 表存在,对应自己的 relfilenode 和数据文件(结构与普通表一致)。

总结

TimescaleDB 超表的数据文件本质是多个 PostgreSQL 表(Chunk)的文件集合,每个 Chunk 包含:

  • 主数据文件(存储行数据,超 1GB 分片);

  • _fsm文件(空闲空间管理);

  • _vm文件(可见性优化)。

这种设计既复用了 PostgreSQL 成熟的存储引擎,又通过"分块"实现了时序数据的高效水平扩展。

相关推荐
OK_boom16 小时前
C# Dapper匹配postgresql的jsonb类型
开发语言·postgresql·c#
SelectDB技术团队17 小时前
当 PostgreSQL 面临性能瓶颈:80TB 电商业务迁移至 Apache Doris 的实践思考
数据库·postgresql·apache
梦想画家19 小时前
告别轮询:基于PostgreSQL CDC构建实时数据管道
数据库·postgresql·kafka·实时湖仓
粗体鱼1 天前
RAG/Agent 记忆混合检索多路召回:RRF 算法与Chunk RRF、Document RRF如何决策TopK
postgresql·milvus·es·rag·rff·mermory
SelectDB2 天前
当 PostgreSQL 面临性能瓶颈:80TB 电商业务迁移至 Apache Doris 的实践思考
postgresql
IvorySQL2 天前
PG 日报|PG20 正式计划移除 refint 模块,官方指引迁移原生外键
数据库·人工智能·postgresql·开源·区块链
2601_960906722 天前
华为MateBook Pro S首发搭载麒麟XE90
华为·postgresql·sqlite·时序数据库·tdengine
丘丘用户思思澪2 天前
混合检索的极简主义:PostgreSQL + pgvector 生产级方案
数据库·postgresql·bm25·vectordb
依晨照旧2 天前
PostgreSQL 常用命令速查:MySQL 用户平滑上手,psql 元命令 + 库表管理 + 运维排查一篇通
后端·postgresql
AAA@峥2 天前
PostgreSQL 入门与实战指南|从基础概念到 CentOS 部署、运维、CRUD 完整教程
运维·postgresql·centos