GBase 8a存储空间优化：从被磁盘撑爆到学会省着用

上个月学GBase 8a的时候，我犯了个低级错误：用单机版跑了一天数据导入导出测试，insert了好几轮，中间还做了不少delete清理。结果第二天一看，磁盘用掉了80%，明明数据量不大，硬盘怎么这么快就满了？

翻来覆去找原因，后来在社区看到一篇文章才恍然大悟：GBase 8a是列存数据库，delete只是在数据上打了个“已删除”的标记，磁盘空间根本没释放，也不会被新数据重用。这个机制和MySQL不一样，我一开始完全没想到。

第一个尝试是改压缩。默认情况下8a用的是轻量级压缩，压缩比不高。我找到一篇文档说可以通过表重建来提升压缩级别，释放大约50%的空间，原理是把历史数据迁移到高压缩的新表上。压缩方式有好几种，什么Nozip、HighZ、RapidZ，官方推荐HighZ。我试了一下，把一张测试表重建压缩，空间从1.2G降到了400多M，效果还是很明显的。不过文档里也提醒，高压缩会增加CPU开销，查询会变慢，但对我来说在单机学习场景下可以接受。

第二个是shrink space。这个命令分几种，普通shrink space是按数据文件回收，只有整个文件的数据全被标记删除才释放；shrink space full是行级回收，把所有有效数据重新整理一遍，回收得更彻底。我试了个小表做shrink space full，用了大约一分钟，空间确实释放出来了。但需要注意一个坑：shrink操作会先备份再删除，磁盘占用是先增大再减小。我当初就是没注意，后来专门看了看文档里关于备份空间的提醒。

还有一点：shrink full相当于重建整张表，表越大越慢，不适合频繁操作。另外尾块数据所在文件也没法回收，所以不是所有delete都能释放。

在折腾过程中还留意到一个参数：gcluster_shrink_to_rebalance，设为1之后shrink space不会阻塞insert、load这些操作。我目前单机测试没开这个，但感觉在生产环境应该有用。

总体下来，我现在的做法是：如果有大量历史数据不再变动，优先考虑重建高压缩表；对频繁更新的小表定期做shrink full；临时表用完直接truncate而不是delete。目前磁盘从最开始几乎被撑爆，到压缩重建后剩余30%左右，至少短时间内不再担心空间问题了。