数据库工程师圈子里流传着一个奇怪的共识:65536是个"魔法数字"。不是因为它在二进制里好看(虽然确实好看,2的16次方),而是因为GBase 8a把它写进了存储引擎的底层设计。每个数据块固定65536行,最后一块故意不压缩——这套组合拳打出来,加载速度飙到30TB/小时,查询时能跳过整批无关数据,压缩比还能做到1:20。
听起来像典型的"既要又要"?其实是精准取舍。OLAP场景下,没人关心单条记录怎么存,大家只关心十亿行数据怎么算得快。GBase 8a的DataCell架构就是围绕这个前提设计的,三个环节环环相扣。
![]()
加载环节:把随机写变成顺序写
![]()
传统数据库最怕小批量插入。每次写几行,磁头来回寻道,性能直接崩盘。GBase 8a的做法是强制攒够65536行才落盘,零散插入被攒成大块顺序写入。文档里写的30TB/小时不是实验室数据,是生产环境跑出来的。
新数据永远往当前DC的"尾巴"里塞,这个尾巴不压缩、不碰历史块。插入操作轻到近乎无感——代价是未满的DC暂时吃不到压缩红利,攒够之前白白占着磁盘空间。数据仓库场景下,这个代价完全可以接受:白天灌进来的日志流,夜里批量压缩封存,第二天查询时已经是紧致形态。
查询环节:跳过比读取更重要
列存引擎的基本功是"只读需要的列",GBase 8a在这之上加了层轻量索引。每个DC头部存着三样东西:最小值、最大值、空值计数。优化器拿查询条件一比对,整批65536行直接跳过,解压和计算全省了。
更底层的是SIMD友好设计。65536个同类型值连续排布,CPU向量指令一次处理一批,聚合和过滤的吞吐拉满。代价是点查场景——比如"找ID等于某值的记录"——可能被迫读完整列块。但列存本来就不是为点查生的,真要用行存引擎才是正道。
压缩环节:同质数据才能压出奇迹
![]()
65536行同一列的数据,类型相同、分布相近,压缩算法能找出的规律比行存多得多。1:20的压缩比在文本类数据上并不夸张,压缩后的数据还能直接参与计算,省下来的I/O和内存都是真金白银。
压缩策略可以分层设置:库级、表级、列级各选算法(0、3、5等编号对应不同速度与压缩比的平衡)。尾巴块暂时不压,等封盘时一次性处理,存储收益随后兑现。
这套设计的本质是什么?
用工程术语说,是"对齐友好":65536行 × 列宽 = 内存页整数倍,DMA传输、CPU缓存、磁盘扇区都能对齐。用产品术语说,是"场景特化":牺牲点查体验,换批量分析的极致效率。
数据仓库和BI报表正是这样的场景——没人半夜三点查单条订单,但早上九点要看千万级聚合。GBase 8a的DC架构把这个需求翻译成了具体的数字:65536行一块,尾巴不压,能跳则跳。魔法数字背后没有魔法,只有对 workload 的清醒认知。
特别声明:以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布,本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.