GaussDB(DWS) 之 DDL设计的几点建议

DDL的设计会影响数据变更和查询性能，在对时效有严格要求的业务中，数据结构尤为重要。设计时建议事项如下:

1.分布键的数量建议不大于4

在集群版GaussDB(DWS)中，一般分布键较多时数据分布会比较均匀；即在单分布键下数据分布节点计算时的影响因素较少，一旦该分布键值存在聚集，数据在节点上的表现也会出现倾斜现象，而多分布键会增加分布节点计算的影响因素，减小数据倾斜。但分布键过多会出现存储性能和联合查询性能问题，建议不大于4个分布键。

a）存储性能问题：

在数据新增时，需要按hash函数计算每一分布列的结果，再将结果整合起来，作为确定分布节点参数，分布键越多，计算越复杂越耗时。

b）联合查询性能问题：

多表联合查询时，当分布键所有列为join条件涉及列的子集时，在执行计划中数据不需要做重新分布；反之，需要按join条件进行数据的重分布，分布键列指定的越多，其成为join条件涉及列的子集概率越小，越容易发生数据的重分布，而数据重分布则会消耗资源和时间。

2.索引列数/PCK列数建议不大于4

a）索引列数越多，其维护索引数据需要的资源越多，出现重复索引概率越大。

b）PCK列越多，因在列存数据导入时需要对每一PCK列进行比较计算来划分CU，其过程将消耗越多时间和资源，导入性能降低；而且在数据查询时，查询条件所涉及列的前缀需要是PCK列（如PCK列为a、b、c，则查询条件需要为a>? and b>? and c>?类似样式的组合），这样才能在CU过滤时达到很好的效果，反之则需要遍历每一个CU，数据的聚簇没有发挥优势。

3.防止创建无效PCK列

在GaussDB(DWS)8.1.1版本中，CU的过滤比较支持char，int8，int2，int4，text，bpchar，varchar，date，time，timestamp，timestamptz数据类型。所以PCK列指定了非上述类型的列时，在实际CU过滤时并没有起到作用，称之为无效PCK列，而维护这个无效PCK列需要一定资源。

4.Numeric的使用规范

在涉及数值类型使用时，尽量使用整型，或对精度要求不高的情况下，使用float类型这类定长类型，比numeric这种变长类型计算性能好；即使用numeric类型，建议指明标度和精度，尽量在38位以内，因为在涉及numeric类型数值的计算时，底层会尝试将计算转换为int或bigint之间的计算，以提升计算效率，即数据类型的大整数优化。在GaussDB(DWS)8.1.1版本指出未指定精度的情况下，小数点前最大131,072 位，小数点后最大 16,383位，即按最大标度和精度处理，在计算时将无法进行大整数优化，计算效率相应下降。

5.索引列宽度建议在64字节内

过长字段一般都是字符串，这些字段基本不会执行比较操作，而且宽字段会造成索引体积过大。

6.复制表的数据量大小建议在100MB内

集群版的GaussDB(DWS)支持复制表（replication）类型，该表会在每一个节点中维护一份全量数据，其较多应用于可枚举类数据的存储。如果表数据量过大，会占用较多空间；并且在实际联合查询中，节点会遍历所有表数据，可能会比将表类型改为分布表后的联合查询消耗时间还长（分布表虽然可能会产生数据重分布，但每个节点遍历的数据量会减少）。

7.分布列指定规范性

在GaussDB(DWS)集群中，分布列建议不要指定为boolean或date类型字段，很容易出现数据的倾斜。

8.序列新增时cache个数指定值建议大于100

在表字段使用到sequence时，其next_value首先从本节点预先获取缓存下来的值中拿取，如果用完了则请求GTM服务再次获取，在大批量数据新增时，如果cache数量过少，会不断请求GTM，多个节点大批量请求会导致GTM压力过大，容易造成崩溃或阻塞，所以建议新建sequence时指定cache值大于100。

当然在实际DDL设计中还有很多需要注意的内容，后续博文将会逐一补充到位，同时也会针对每一项进行图文或示例解析。

想了解GuassDB(DWS)更多信息，欢迎微信搜索“GaussDB DWS”关注微信公众号，和您分享最新最全的PB级数仓黑科技，后台还可获取众多学习资料哦~