更新日期:2024年09月11日
GBase 8a MPP 集群性能取决于各个节点整体的性能,每个节点存储的数据量对于
集群性能有很大影响,为了尽可能达到最好的性能,所有的数据节点应该尽量存储
等量的数据,因此在数据库表规划定义阶段要考虑表是复制表还是分布表,以及对
分布表上的某一些列设置为分布列进行hash 分布。
例如根据数据的分布特性设计,可以:
1. 将字典表或者维度表建成复制表的方式将数据存储到各个节点上,
即不须对其数
据进行分片存储。因为字典表的数据量相对较小,虽然在各个节点进行存储有一定
的数据冗余,但和事实表的JOIN 运算就可在本地进行,避免节点间搬动数据。
2. 对于事实表(大表)可将数据分布到不同的节点上存储,分布方法可采用随机分
布(目前很少用),或者单列hash 分布,或者多列hash 分布的方法,SQL 执行的查
询条件满足只在其中部分节点时,查询优化可决定SQL 的执行仅在这些节点执行
即可。
分布列选取原则
优先考虑大表间的JOIN,尽量让大表JOIN 条件的列为Hash 分布列(相关子
查询的相关JOIN 也可以参考此原则)
,
以使得大表间的JOIN 可以直接下发到
各节点分布式执行。
其次考虑GROUP BY,
尽量让GROUP BY 带有Hash 分布列,
让分组聚合一步
完成。
当有多个join 或group 列可选择时,优先选择唯一值多(count(distinct)值大)
的列做Hash 分布列,让数据均匀分布。
GBase 8a MPP Cluster 最佳实践
2 性能调优
文档版本(2022-02-11)
南大通用数据技术股份有限公司
19
通常是等值查询的列,并且使用的频率很高的应考虑建立为hash 分布列。
注意事项
hash 分布列只能选择数值和字符串类型的列。
作为hash 分布列的列不能进行update(包括快速update 模式下的更新)。
尽量保持hash join 的等值关联列在类型定义上完全相同。
如:char 和varchar 类型进行关联,可能出现结果为空情况,原因是char 型不
足最大长度时用空格补齐,varchar 则没有空格,如果关联则需要trim 空格。
又如:
gbase 中decimal 和bigint 类型join 时需要进行类型转换导致无法走最优
的执行计划,可以将两表的hash 分布列统一为相同类型bigint。