GBase 8a数据库的“晚期物化内存瘦身术”解析（上）

明明只想查几列数据，数据库却把整行数据都拽进内存，结果内存爆了、查询慢了、并发没了。南大通用GBase 8a数据库（gbase database)的“晚期物化”技术，专门解决这个问题。它用“行号”代替真实数据跑完所有中间计算，只在最后一步才把需要的列解压、拼装、加载。实测下来，内存占用能省几十到上百倍。本期内容就来拆解这套“拆包延迟”的黑科技。

1、传统物化：为什么内存总是不够用？

先解释一个概念：“物化”，就是把查询的中间结果变成实实在在的数据集。

传统数据库（包括普通列存）采用“早期物化”：查询时先把整行数据读出来、拼好，再执行过滤、聚合。比如一张表有100列，只想查5列，但系统先把100列全加载到内存，再把不需要的95列扔掉——内存浪费严重。

在OLAP大表分析场景中，这种浪费会被放大。几亿行数据，每行几百字节，还没开始算，内存先被撑爆了。

2、晚期物化：把“拆包”留到最后

GBase 8a的晚期物化，逻辑很简单：“全程用行号（Row ID）计算，只在最后一步才加载真实数据。”

整个流程分三步：

01、Smart Scan智能过滤

利用列存自带的智能索引，快速跳过不满足条件的数据块。索引维护自动化，用户不用管。

02、行号标记全程运算

在过滤、JOIN、聚合等所有中间操作中，只传递行号。行号只占几十字节，而整行数据可能几百甚至几千字节。这一步就把内存占用压到了极致。

03、晚期物化生成结果

等所有计算完成，确定最终结果集后，才去解压需要的列，拼接成完整行，返回给用户。

一句话总结：先干活，后打包。无关数据全程不沾内存。

3、效果实测：几十倍到上百倍的内存节省

假设一张1亿行的表，要查5列数据，最终结果集是100万行。

结果：内存占用从“几百MB甚至几GB”降到“几十MB”。实测中，大表聚合、多表大JOIN场景，内存从几十GB降到几百MB，下降几十到上百倍。

除了省内存，还能降CPU和I/O：只解压需要的列，只读取需要的数据，无效操作大幅减少。