Gabse8a数据分布规划

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 分布列，让数据均匀分布。

通常是等值查询的列，并且使用的频率很高的应考虑建立为 hash 分布列。

注意事项

hash 分布列只能选择数值和字符串类型的列。

作为 hash 分布列的列不能进行update（包括快速 update 模式下的更新）。

尽量保持 hash join 的等值关联列在类型定义上完全相同。

如：char 和varchar 类型进行关联，可能出现结果为空情况，原因是 char 型不 足最大长度时用空格补齐，varchar 则没有空格，如果关联则需要 trim 空格。

又如：gbase 中 decimal 和 bigint 类型join 时需要进行类型转换导致无法走最优 的执行计划，可以将两表的 hash 分布列统一为相同类型bigint。