本文讨论GBase 8a数据库集群，在哪些情况下会出现部分节点磁盘占用大小差距较大，比如部分占用多或部分占用少的可能原因，以便用户根据业务要求进行调整。
目录导航
参考
目标表Hash分布表列的数据不均
目标表为hash分布表，这个是最常见的原因，节点数越多，现象越明显。原因是数据本身就分布不均匀。
曾有项目记录原始话单数据，根据主叫号码进行Hash分布，但发现各个节点磁盘占用差距达到了3倍。经数据排查，发现10086占用的总行数，基本等同于第2到第5的总和，甚至还要多。结果导致保存主叫10086的节点磁盘空间明细比其它的多。
解决方法
V8版本，可以选择其它的分布更均匀的，可接受的hash分布列，或者干脆使用随机分布表，将数据接近平均的分散。
V9版本，实现了多列hash，可以选择合适的多个列做Hash分布来缓解倾斜，当然需要根据业务，毕竟多列hash也代表这你的join/group里也必须包含这多列，否则没有性能提升，那就还不如直接做随机分布表。
汇总类查询转储第一列存在大量重复值
目标表多为随机分布表，采用insert 目标表 select 原表 group时，group的第一列有大量重复值，且其余group列又不是原表的hash分布列，则会导致大量数据分组到部分节点，然后insert 到了本地随即表里。
频繁加载小批量数据
只针对随机分布表，如果数据行数比节点数还少，或者数据行数每次都不是节点数的倍数，那么总会有部分节点的行数会少一行。
比如100个节点，每次加载90行，那么最后10个节点将每次都没有数据。
每次加载190行，那么最后10个节点将少一行。
数据库内部并没有在加载时动态调整这一行的偏差的功能。
如果频率很高，比如每5秒一次，那么随着时间累计积压，部分节点磁盘占用将比其它的少。
解决方案
增加加载间隔，比如从每5秒一次改成每5分钟一次，则可以极大改善这个差距的程度。
其它数据占用
如下是几种遇到过的，其它数据导致部分节点占用高的情况。
加载错误数据
当加载出现不合法的数据时，默认会将其保存到加载连接的gcluster节点的日志目录下。当某些业务加载错误数据多时，错误数据占用的空间将明显比其它节点多。
解决方法
提高数据质量，或者拒绝错误超过限定的加载。，具体看load的语法里有关MAX_BAD_RECORDS的部分。
用户导出的本地数据文件
用户偶尔会导出部分数据，发送给外部其它业务用，比如上报。而这些数据文件较大，且忘记了清理，会导致这些节点磁盘占用高。
日志频繁刷新导致
系统故障且不可自动，则会在恢复时记录大量的日志。
曾发生用户不同节点的配置文件不同，导致某个节点的密码修改失败，集群记录的event。在后续重做过程中，肯定还是报错，无法修改密码，同步失败记录日志。之后立即重试，不断重试，同步日志也就在不断的增长。
解决方法
尽快排查解决系统不一致的问题，包括节点故障。