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只解压需要的列只读取需要的数据无效操作大幅减少。