KingbaseES存储结构详解：数据页、索引与WAL机制

先做个说明市面上讲KingbaseES的文章不少但大部分都在讲SQL语法、备份恢复真正深入到存储内部结构的内容非常少。我研究KingbaseES的存储结构有一段时间了期间翻过官方文档、对照过Oracle和PostgreSQL的实现也在实际项目中排查过几次存储相关的问题这篇就把积累的东西一次讲清楚。内容包括逻辑存储层的设计、物理文件组织、页内部结构、索引存储机制、WAL日志机制以及实际操作中一定会遇到的膨胀、损坏、空间排查等问题。看完之后你对金仓数据库“数据到底怎么放的”会有一个完整清晰的认识排查问题时也能直接上手。1. KingbaseES存储架构概览逻辑与物理双层的映射关系1.1 逻辑存储层级从数据库实例到数据页KingbaseES的整体存储结构我觉得可以概括为一句话逻辑上分层物理上分块。逻辑层次的顶层是实例Instance一个实例对应一个运行中的数据库服务进程组通常监听一个独立端口。实例下面是多个数据库Database不同数据库之间逻辑隔离这一点和Oracle的“一个实例对应一个库”有本质区别反而更像PostgreSQL。再往下是表空间Tablespace、Schema、表Relation最后落到数据页Page/Block这一层。我把这个层级关系整理成一张表方便大家对照记忆层级对应物理对象作用域说明实例Instance数据目录集合、共享内存段、后台进程管理所有数据库对应一个data目录数据库Databasedata/base/xxx 子目录逻辑隔离权限隔离表空间Tablespace独立目录非base下跨库共享存储位置Schema/表Relation表空间内的若干文件业务数据组织单元数据页Page/Block文件内固定大小块默认8KB读写的最小单位这里面有个关键点很多从Oracle转过来的DBA第一次接触金仓时都会问“表空间对应哪个数据文件是不是一个表空间一个文件”。实际上金仓的表空间和Oracle不太一样它逻辑上确实有“表空间”这个概念但物理上并不强制每个表空间对应一个独立文件而是对应一个操作系统目录。表空间里的表会以独立文件的形式存放在这个目录下。所以你在金仓里执行CREATE TABLESPACE时指定的其实是“路径”而不是Oracle那种“数据文件路径大小”。1.2 物理存储目录base目录、oid与relfilenode的对应关系搞清楚了逻辑层再看物理层就顺了。KingbaseES的数据目录通常叫data下面核心目录是base、global、pg_wal早期版本叫pg_xlog、pg_tblspc、pg_stat等。base目录里每个子目录的目录名是一个数字这个数字就是“数据库OID”。你连上某个库之后执行SELECT oid, datname FROM pg_database;拿到的oid就能直接去data/base/下找到对应的目录。所以排查一个库占了多少空间最简单粗暴的办法就是直接统计base下面对应目录的总大小比如du -sh /data/kingbase/base/16405这里16405是数据库OID。global目录存放的是集群级的共享对象比如pg_control、全局系统表等。pg_tblspc目录里放的是软链接指向你创建表空间时写的那个物理路径。这个设计和PostgreSQL一模一样而不像Oracle那样有个dbf文件列表需要维护。再往深一层每个表或者索引在物理上是一个文件文件名称为relfilenode。你执行SELECT pg_relation_filepath(你的表名);返回的就是类似base/16405/16783这样的路径。这个16783就是当前的relfilenode。在KingbaseES里当表执行过VACUUM FULL或者CLUSTER之后relfilenode会发生变化因为文件被重建了。这个细节很重要——你如果监控发现在线巡检时表文件的mtime变了不一定是有业务在写也可能是有人执行了重构类的操作不要误判为异常写入。1.3 存储结构设计的兼容性思路金仓的存储引擎内核来源于PostgreSQL但为了兼容Oracle又做了不少封装。我在实际使用中感受最深的一点是很多Oracle开发的SQL和PL/SQL在KingbaseES上可以直接跑但涉及存储特性的操作比如你直接去读dba_data_files来查数据文件返回的结果其实是金仓做了一层视图映射。这意味着你可以用Oracle习惯的视图查但底层实现完全是另一套。这种“兼容”设计带来的一个实际问题是网上很多教程直接照搬PostgreSQL的存储说明来套金仓容易踩坑。比如PostgreSQL里pg_current_wal_lsn()这样的函数金仓早期版本改过名字现在版本基本保留了pg_current_wal_lsn但某些老版本要写sys_current_wal_lsn或者别的名字各个大版本之间不完全一致。所以你在研究金仓存储结构时最好是对着目标版本的官方文档来验证不要只看泛用性的资料。注意金仓的版本号体系比较复杂V8系列下又分V8R3、V8R6等子版本存储细节有差异。下面我讲的内容以目前较常见的V8R6为主但凡是跨版本有差异的点我都会额外说明。2. 页Page的内部布局数据在磁盘上的最小组织单元2.1 固定页大小与页内分区KingbaseES默认数据页大小是8KB编译时通过BLCKSZ控制默认值是8192字节。整个页结构分为四个区页头PageHeaderData、行指针数组ItemIdData、空闲空间Free Space、元组数据区Tuple Data。页头和行指针数组是从页的头部向下生长的元组数据是从页的尾部向上生长的中间就是空闲空间。空闲空间耗尽时页就不能再插入新行了需要往新页里写。页头里包含的关键信息包括页的LSN最近修改该页的WAL记录位置、页的检查点位pd_checksum、页内元组数量pd_lower其实就是空闲空间起始位置pd_upper是空闲空间结束位置等。如果你用类似pageinspect的插件金仓对应功能也有可以直接查看这些结构。我在分析表膨胀问题时经常先看pd_lower和pd_upper算一下空闲空间占比就能判断页是不是“假满”。关于页大小我想说一点8KB在OLTP场景下是比较合适的它兼顾了缓存效率和行大小适配性。如果单行数据非常大比如超过2KB你可能会关心是否要调大块大小但是KingbaseES的块大小必须在编译时指定运行期无法修改。所以如果是纯Oracle迁移场景原来依赖大块缓存优势的业务迁移过来之后可能需要重新评估缓冲命中率——这是存储结构差异带来的性能适配问题。2.2 行数据Heap Tuple的物理组织方式每个元组行在页内的存放不是像Oracle那样“列表管理全部数据”而是通过行指针数组 元组实体两级定位。页头后面是一组ItemIdData每个4字节其中包含元组实体在页内的偏移量和长度。元组实体本身在页尾部包含元组头HeapTupleHeaderData和实际字段数据。堆元组头里有两个值得重点解释的字段t_xmin和t_xmax。在金仓的MVCC机制里每一行都记录了插入和删除/更新它的“事务号”。这也是理解“更新等于删插”的关键在KingbaseES默认的堆表引擎里执行一次UPDATE物理上的结果大概率是“旧元组被标记为删除t_xmax被设置为新事务号但数据还在 新元组插入到页里”。这跟在Oracle里直接原地覆盖完全不同也直接引出了后面章节要讲的“表膨胀”问题。还有一个细节KingbaseES支持一种“TOAST”The Oversized-Attribute Storage Technique机制专门处理大字段。当一行的某个字段太大比如一个几MB的文本或者二进制内容直接塞进堆元组里会让整个页都放不下。此时引擎会自动把大字段值拆分成多个块默认约2000字节每块存到独立的TOAST表中原行里只保存一个指向TOAST表的OID和指针。这个过程对应用是透明的但影响颇大如果业务表大量存大对象物理文件会额外多出一个_toast后缀的文件空间统计和清理策略都必须关注它。2.3 可见性判断机制老版本数据的存储与清理因为有了t_xmin和t_xmax判断一行“是否可见”就变成了比较事务快照与这些事务号的大小关系。我一直觉得这是KingbaseES存储结构里最核心的设计它把“并发控制”和“物理存储”绑定在了一起也让一切空间膨胀都源于MVCC这个本质。当一个事务执行DELETE后被删除的行其实还躺在数据页里只是t_xmax被标了新事务号快照老的查询仍然能读到它。只有等到这个删除事务以及更老的读事务全部结束VACUUM才会把这种“死亡元组”占用的空间标记为可复用。而VACUUM不会立即把空间还给操作系统它只是把页内部的空间标记为空闲文件整体大小不变。这就是为什么你VACUUM之后看du文件还是那么大必须执行VACUUM FULL才能收缩文件。顺便补充一个和存储布局直接相关的使用建议频繁UPDATE的业务表页内的空闲空间会非常零碎新插入的行可能无法紧凑排列导致页利用率下降。此时合理的FILLFACTOR默认100需要调整给页预留一些UPDATE空间这能明显减少页分裂和死元组堆积。比如一张表经常把行的某个字段从一个较短字符串更新为更长字符串FILLFACTOR80往往能比默认值减少30%以上的行迁移和页分裂。这个参数在存储布局上本质就是“人为改制UPSERT空间”。3. 表空间与数据文件规划从创建到运维的完整路径3.1 表空间创建与重定向金仓里创建表空间语法很简洁CREATE TABLESPACE tbs_app LOCATION /data/kingbase/tbs_app;执行这个语句前目录必须存在且为空而且系统用户kingbase用户要有该目录的写权限。创建完成后你可以在建表时指定表空间CREATE TABLE t1(id int, name text) TABLESPACE tbs_app;创建完表之后去/data/kingbase/tbs_app目录下你会看到一堆以数字命名的文件这些就是表对应实际数据文件。这里有一个实践细节切换表空间不等于迁移数据文件。如果你想把已有表从默认表空间挪到新表空间需要执行ALTER TABLE t1 SET TABLESPACE tbs_app;这条修改会在物理层面把表文件从旧位置复制到新位置并更新系统目录整个过程要加锁但一般比较快。如果表示几十GB的大表这个过程会重启IO压力最好安排在业务低谷执行。和金仓相关的还有一个操作从Oracle迁移时如果原库的某些表分布在不同的表空间DBA通常习惯性地也想在金仓建同名表空间来保持迁移一致性。我的实际建议是不要完全照搬Oracle的表空间规划。金仓没有Oracle那种分区表“每个分区独立表空间”的硬件性能需求表空间更多是用来做存储位置隔离——比如把热点业务表放到SSD盘、把归档历史表放到机械盘。规划时按存储介质和应用生命周期去分通常两三个表空间就够了。3.2 数据文件大小与自动扩展机制金仓堆表文件默认大小是1GB。当表超过1GB时文件会继续扩展成relfilenode.1、relfilenode.2这样的分段文件。这一点和PostgreSQL一样但和Oracle默认单个数据文件通常设为32GB甚至更大有显著差异。实际运维时需要注意文件一多备份恢复、慢查询全扫描都会受到一定影响因为操作系统和数据库都要维护更多句柄。文件扩展的触发条件是“当前文件末尾页已满需要新页”。这种扩展操作会申请新的文件段但不会立即发生磁盘空间写满而是随着写入逐步增长。在查询方面SELECT pg_relation_size(表名)返回的是当前表的主堆文件总大小所有段之和不包括索引和TOAST。我一般排查空间时喜欢一次看全SELECT pg_size_pretty(pg_total_relation_size(big_table)) AS total_size, pg_size_pretty(pg_relation_size(big_table)) AS heap_size, pg_size_pretty(pg_total_relation_size(big_table) - pg_relation_size(big_table)) AS index_toast_size;如果index_toast_size占比惊人地高就需要单独排查索引膨胀和TOAST了。关于“文件满了会不会自动扩展”金仓对数据文件的增长基本不做限制限制来自文件系统。真正影响可用性的反而是WAL目录pg_wal的增长。如果某个库大量写数据WAL文件会不停产生和归档如果归档失败或者wal_keep_segments配置过大pg_wal目录会被撑满数据库会直接罢工。这种表现很容易让新手误判为“数据文件满了”其实是WAL空间的问题。3.3 分区表与表空间的配合使用金仓分区表在物理存储上也遵循“一个分区一个独立文件”的规则所以分区对存储结构的影响是显而易见的它能有效阻止单个表文件无限膨胀到超出文件系统的最大文件数限制同时让“只读老分区”的物理数据可以独立搬迁到慢速存储。我在本地测试时验证过一个情况在使用RANGE分区的情况下每天一个分区按月归档。归档逻辑很简单把老月份的分区DETACH然后单独备份该分区的表空间目录。这比全表逻辑删除要可靠得多因为物理文件可以单独控制。但需要注意金仓的分区表在早期版本中对“分区裁剪”的优化不如Oracle成熟某些复杂条件查询可能要扫描所有分区此时你会发现IO压力非常大——“明明我只查上个月的数据为什么磁盘读取那么猛”这本质上还是物理存储层次的问题。所以分区的时候要注意查询条件尽量写成能在WHERE里BETWEEN这种范围形式并且在每个分区上建好对应的本地索引避免走全分区扫描。4. 索引存储结构BTree物理实现与膨胀原理4.1 BTree索引的页内布局KingbaseES默认的堆表索引是BTree结构在物理存储上索引也是一个独立的文件内部同样按8KB页组织。BTree的页面分为三种根页、内部页分支页、叶页。和Oracle索引不同金仓的索引叶页里存的是索引键值 对应的堆表行的物理位置TID页号偏移量而不是像Oracle那样通过ROWID直接物理定位。查询过程是有趣的先走索引找到匹配的TID然后通过TID回表读取堆页。如果查询要返回的列不在索引里就必然有一次表扫描回表。这个机制决定了“索引覆盖”的重要性——如果你能用“索引包含列”或者复合索引把查询需要的列都覆盖到就能省掉回表IO性能差好几倍。索引页的内部结构比堆页稍微复杂但核心还是“页内键值有序排列 页间指针链接”。BTree的特征是数据都存放在叶层内部页只放键值和子页指针因此整个索引的高度通常只有3~4层千万级数据的查询也能在几次页读之内完成。实践中的一个关键心得是不要把索引建得过长索引键值越长单个页能放下的键越少树的高度越高IO次数越多。比如一个varchar(200)的建索引成本远远高于int索引尽量不要超过32字节的边界。4.2 索引膨胀的机制与影响索引膨胀和表膨胀的根源相同都是MVCC留下的死元组未及时清理。当堆表里的死元组被VACUUM清理时索引里指向这些死元组的指针也会被标记为过期但索引页里的空间回收通常不及时。更麻烦的是如果堆表UPDATE频繁导致索引键值变更索引会不断插入新键、删除旧键页内出现大量碎片空间。有一个非常经典的现象表只有几万行但某个索引文件却占了500MB。这种“索引膨胀”一般出现在高并发UPDATE且高频小事务的场景。排查的时候可以用SELECT pg_size_pretty(pg_relation_size(idx_name)) AS idx_size;和表大小对比感受一下。解决索引膨胀有两个方法第一REINDEX INDEX idx_name全量重建索引杀敌一千但会持有写锁大索引上执行会造成业务停摆必须谨慎。第二定期VACUUM并及时回收配合老版本里CONCURRENTLY参数。金仓支持并发重建索引吗其实V8R6已经类似PostgreSQL提供了REINDEX INDEX CONCURRENTLY的语法但执行耗时更长而且要占用更多临时空间你需要自行测试权衡。我的建议生产环境大表的索引重建优先用并发方式做个维护窗口能接受长时间占用就上。4.3 FILLFACTOR在索引和表上的差异化设置前面提到过表的FILLFACTOR设置索引的FILLFACTOR同样重要而且语义不同。对BTree索引而言FILLFACTOR越低初始构建时页内预留的空闲空间越多将来插入新索引项时页分裂的概率越低。对一张频繁INSERT且不太UPDATE的表索引的FILLFACTOR可以设到90这样索引页既有一定的余地应付随机插入又不会因为太空导致索引膨胀。对于频繁UPDATE被索引列的表建议将索引的FILLFACTOR设得更低一些比如70~80这样更新时索引键值迁移会有更多缓冲空间。我曾经接手过一个项目业务每天早高峰大量UPDATE一张订单表系统卡顿严重。排查时发现其中一个组合索引的叶页几乎都满了实际读到的avg_leaf_density接近95%UPDATE触发大量的页分裂和旧指针清理整个系统被索引维护拖累。后来把该索引FILLFACTOR重建为75问题明显缓解——虽然索引空间多了三分之一但明显改善了SQL执行的稳定性。注意FILLFACTOR的修改对已经存在的索引必须重建才能生效不能只改参数不重建。这是个容易踩的坑。5. WAL预写日志与崩溃恢复存储可靠性的底层支柱5.1 WAL文件的结构与管理方式WALWrite-Ahead Logging是KingbaseES保证数据不丢的基石。它的语义是任何用户数据的修改先写WAL日志再改数据页。这样做的好处是不用每次提交都把脏页刷到磁盘只需要把日志刷掉就行崩溃后靠WAL重放就能恢复。WAL文件默认在data/pg_wal目录下每个文件大小默认16MB编译时以XLOG_SEG_SIZE控制。文件命名是24位十六进制时间线ID日志序号所以你在目录里会看到一长串像00000001000000000000002F这样的文件。每个WAL文件内部按8KB页组织页内是一个接一个的日志记录。每一条记录都包含头部记录类型、长度、事务ID、上一条记录的指针 实际的页面数据变更或逻辑信息。WAL机制对存储结构有一个非常直接的影响数据页越分散一个逻辑操作需要写的WAL记录越多吗其实不一定。WAL记录的是页面的变更或一些重要事件跟你操作的页是否集中没有必然关系但如果你频繁更新相同页面WAL里会积累大量重复的整页写full page write。所以KingbaseES有一个“全页写”机制在基准备份后的第一次修改时把整个页的镜像记到WAL里用于防止部分写导致崩溃后无法恢复。这个选项由full_page_writes控制默认开启不能随意关闭否则恢复时可能遇到页损坏。实际运维中WAL目录的IO压力和存储配置密切相关。我在生产环境建议务必把pg_wal放在独立的高性能磁盘上最好是带备电的SSD否则一个事务风暴就能把磁盘IO打满甚至造成全库卡死。另外WAL目录要留足够的余量一般至少给数据总量的10%~20%作为本底空间高峰写入时要按事务量动态调整。5.2 检查点Checkpoint机制的存储影响每过一段时间数据库会执行一次检查点Checkpoint把WAL里已记录的修改实际刷到数据文件中然后推进pg_control里的“检查点位置”。检查点完成后更早的WAL文件理论上就可以清理或覆盖了。这里有个关键体验如果你配置了checkpoint_completion_target0.9数据库会尽量把检查点的写脏页操作分散到整个检查点周期内避免突然的IO尖刺。但如果你是机械盘大表频繁更新时检查点周期内的持续写IO依然会明显。存储结构上体现为被修改的页会在一个周期内集中落盘数据文件写入量在时间轴上并不均匀。我在一次仓库优化中把max_wal_size从默认的1GB调到了4GB同时拉长了检查点间隔明显减少了磁盘尖刺。副作用是WAL目录占用的空间变大了。后来我评估了一下如果业务能接受故障时丢更多WAL重放时间即恢复时间RTO变长这个调整就非常划算如果不能接受则要权衡。这个平衡是存储结构中“WAL大小vs数据落盘频率”的典型取舍。5.3 归档日志与备份的存储关系如果你的库开了归档模式WAL日志在覆盖前会先被复制到归档目录。归档日志的存储量往往能超出预期。我见过不少客户业务数据总共才200GB归档目录却积压了超过1TB。原因往往是归档命令archive_command执行失败或者存储端上传速度跟不上WAL产生速度导致WAL无法清理最后pg_wal和归档目录双双爆炸。在存储结构层面归档期间还会出现一个有意思的现象WAL段文件在被覆盖之前必须被完整归档如果某个WAL段因为文件系统元数据问题偶尔失败数据库会反复重试导致后续WAL继续堆积。排查时我建议先看归档命令的日志再看pg_stat_archiver视图SELECT * FROM pg_stat_archiver;如果failed_count持续上涨基本可以断定归档链路出了问题。这时不要拖赶紧修复外部存储的写入问题并考虑临时手动清理一部分已经成功归档的WAL段在有备份的前提下——否则一旦磁盘满数据库直接拒绝所有写操作恢复代价非常大。6. 实际运维中的存储结构问题排查手册6.1 表膨胀的处理流程与VACUUM策略表膨胀是我在日常运维中遇到频率最高的存储结构问题没有之一。观察到表文件在不断增大但实际“活数据”并没有那么多时可以按下面的流程走一遍先看VACUUM状态和死元组数量SELECT relname, n_live_tup, n_dead_tup, last_vacuum, last_autovacuum, last_analyze FROM pg_stat_user_tables WHERE relname your_table;再估计膨胀率。虽然没有一个官方SQL能百分百准确给出“膨胀率”但用pg_relation_size对比n_live_tup的平均行宽可以推算“理想大小”和“实际大小”的差距。比如一张表活数据约50万行平均行宽500字节理想堆文件大小约500 * 50万 ≈ 250MB但实际文件1GB基本就是膨胀了。处理策略分两级轻度膨胀跑普通VACUUM就可以回收页内空间供后续复用文件大小不会下降重度膨胀必须VACUUM FULL或者pg_repack。但VACUUM FULL会锁表并重写文件在业务高峰期绝对禁止。如果你不想业务中断可以考虑pg_repack它通过额外日志表的方式在线重排数据对业务影响小很多但需要额外安装插件和预留一倍表空间。关于自动清理Autovacuum配置我建议参数常用设置说明autovacuum_max_workers3~5并发清理的Worker数量autovacuum_vacuum_threshold50触发阈值基数autovacuum_vacuum_scale_factor0.05~0.1占比系数大表建议调低autovacuum_vacuum_cost_delay10ms~20ms限速值避免清理风暴autovacuum_vacuum_cost_limit200~1000总成本上限大表的Autovacuum触发计算是死元组数超过threshold scale_factor * 元组总数时触发。比如10GB的表如果scale_factor0.1要积累10%的死元组才会触发这个容忍度太高了会造成大量死元组堆积。对这种大表我建议单独设置表级参数ALTER TABLE big_table SET (autovacuum_vacuum_scale_factor 0.01);6.2 文件系统与页损坏的检测手段存储结构层的损坏会影响数据库正常运行。金仓提供了pg_checksums工具对应PostgreSQL 12的特性来检查和启用页校验和。如果启用了数据校验和每次页读/写时都会校验pd_checksum发现哪页坏了就能快速定位。使用方式是在停库状态下执行pg_checksums -d /data/kingbase -r也可以只用-c检查而不重写。运行时如果遇到“invalid page in block xxx of relation base/.../...”这类日志大概率是某个数据文件发生了损坏。这时我的操作路径是先从备份中恢复损坏的文件。如果库还在运行把损坏的表或索引下线对应文件标记坏页用VACUUM FULL尝试重写该文件。如果损坏发生在系统表上恢复难度陡增应尽快联系原厂支持或者利用最近的物理备份恢复。特别提示机械盘坏道、虚拟机漂移、内存ECC错误都可能导致页损坏。我见过一个客户的SSD盘使用过久后静默损坏数据库日志里零星出现坏页错误但应用只偶发报错。这种“隐性损坏”最可怕因为你不发现它就会慢慢扩散所以启用checksum 定期巡检文件完整性是非常必要的。6.3 快速定位存储占用大户的SQL最后分享一个日常巡检一定用得上的SQL集合。我总在故障发生时快速定位“到底哪个对象占满了我的空间”这组查询能使排查效率提升很多按整库总大小排前十的表SELECT schemaname, relname, pg_size_pretty(pg_total_relation_size(relid)) AS total_size, pg_size_pretty(pg_relation_size(relid)) AS heap_size FROM pg_stat_user_tables ORDER BY pg_total_relation_size(relid) DESC LIMIT 10;查当前有哪些表空间各自落在哪个物理目录SELECT spcname, pg_tablespace_location(oid) AS location FROM pg_tablespace;查WAL目录大小与归档状态SELECT * FROM pg_stat_archiver;du -sh /data/kingbase/pg_wal查所有索引大小并按大小排序快速定位索引膨胀SELECT schemaname, tablename, indexname, pg_size_pretty(pg_relation_size(indexrelid)) AS idx_size FROM pg_stat_user_indexes ORDER BY pg_relation_size(indexrelid) DESC LIMIT 20;这套查询适用于任何版本的金仓因为它们基于系统视图基本都兼容。我平时做巡检脚本基本就是把这些SQL串起来每周跑一次输出报告。最后再分享一个实际经验金仓的存储结构虽然和PostgreSQL很像但真要深入还是得用官方自带的工具和视图不要只看通用教程。尤其是遇到版本差异时先确认你的内核小版本再对照官方文档做验证。我用金仓这段时间最大的感受是它的存储内核足够稳但“稳”的前提是你要真正理解它背后是怎么落盘、怎么管理空间的。把页结构、WAL、VACUUM、膨胀这几条线串起来运维中九成以上的存储问题都能做到快速判断、精准处理。