文档首页/ 数据仓库服务 GaussDB(DWS)/ 开发指南/ 标准数仓开发指南(8.3.0.x)/ GaussDB(DWS)开发设计建议/ GaussDB(DWS)对象设计规范/ TABLE对象设计规范（重点）
更新时间：2024-11-30 GMT+08:00
查看PDF
分享

TABLE对象设计规范（重点）

规则2.9 创建表时必须选择正确的分布方式和分布列

违反规范的影响：

  • 分布式和分布列选择错误，导致表数据存储倾斜，访问性能下降，严重情况会触发存储和计算资源过载。

方案建议：

  • 创建表时通过DISTRIBUT BY显式指定分布方式和分布列，分布列选择原则如下表所示。
表1 分布列选择原则

分布方式

描述

适用场景

Hash

表数据按照分布列生成的hash值与DN实例的映射关系，将数据分布到各DN实例。

  • 优点：每个DN仅包含部分数据，占用整体空间小。
  • 缺点：数据分布的均匀程度强依赖分布列的选择；JOIN关联条件不包含各自分布列的场景存在节点间数据通信的消耗。

大表、事实表。

RoundRobin

表数据按照轮询的方式依次分布到各DN实例。

  • 优点：每个DN仅包含部分数据，占用整体空间小；数据轮询均匀分布，不依赖分布列，不存在数据存储倾斜问题。
  • 缺点：无法通过分布列条件消除和减少节点间通信，此类场景性能不如HASH。

大表、事实表，无合适分布列的表。

Replication

表中的全量数据在集群的每一个DN实例上保留一份。

  • 优点：每个DN上都有此表的全量数据，JOIN操作中可以完全避免节点间数据通信，从而减小网络开销，同时减少了STREAM线程启停开销。
  • 缺点：每个DN都保留了表的完整数据，数据的冗余，占用更多存储空间。

小表、维度表。

规则2.10 创建表时必须选择正确的存储方式

违反规范的影响：

  • 行存表使用不当导致查询场景性能差，资源过载。

  • 列存表使用不当导致CU膨胀，性能差，资源过载。

方案建议：

  • 创建表时通过orientation显式指定表的存储类型，存储类型的选择原则如下表所示。
表2 存储类型选择

存储方式

适用场景

不适用的场景

行存
  • DML增删改：UPDATE和DELETE操作多的场景
  • DML查询：点查询(返回记录少，基于索引的简单查询)

DML查询：统计分析类查询 (group , join的数据量大的场景)。

注意：

创建行存表（orientation = row）时，禁止指定compress属性，禁止使用行存压缩表。

列存
  • DML增删改：INSERT批量导入场景（单次单分区入库量接近或大于6w*DN数）
  • DML查询：统计分析类查询 (group , join的数据量大的场景)
  • DML增删改：UPDATE/DELETE多的场景、INSERT小批量插入的场景。
  • DML查询：高并发的点查询。

规则2.11 创建表时必须选择正确的分区策略

违反规范的影响：

分区的优点如下，如不做分区，其查询性能和数据治理效率会下降，数据量越大这种劣化越大。

  • 改善查询性能：对分区对象的查询可以仅搜索自己关心的分区，提高检索效率。
  • 提升数据治理效率：如数据生命周期管理场景，针对历史分区做TRUNCATE/DROP PARTITION，效率和效果远优于DELETE。

方案建议：

  • 针对包含时间类型字段的表设计分区。
表3 分区策略选择

分区策略

描述

适用场景

范围分区（Range Partitioning）

根据分区键值的范围，将数据存储到不同的分区中，分区键范围连续但不重叠。
  1. 日期或者时间类的字段作为分区键。
  2. 查询中大多包含分区键作为过滤条件。
  3. 定期按照分区键清理数据。

列表分区（List Partitioning）

根据分区键值的列表进行分区，各分区的列表值不重复
  1. 特定数量的枚举值作为分区键值。
  2. 查询中大多包含分区键作为过滤条件。

建议2.12 表字段的设计要遵循高效、准确原则

违反规范的影响：

  • 存储空间大、查询效率降低。

方案建议：

  1. 选择最高效的类型。
    • 如能整型就不用浮点型，能用整型就不用字符型。
    • 使用变长字符类型时根据数据特征指定最大长度。
  2. 选择最准确的类型。
    • 使用时间类型存储时间，不使用字符类型存储时间。
    • 使用满足需求的最小数值类型，如果int或smallint够用，就不用bigint而浪费空间。
  3. 正确使用约束。
    • 明确不存在NULL值的字段加上NOT NULL约束，优化器会在特定场景下对其进行自动优化。
    • 业务层面能补全的字段，不要使用DEFAULT约束，避免数据加载时产生不符合预期的结果。
  4. 避免非必要类型转换。
    • 当多个表存在逻辑关系时，表示同一含义的字段应该使用相同的数据类型。
    • 不同类型的比较操作会导致数据类型转换，可能导致索引和分区剪枝失效，影响查询性能。

建议2.13 避免使用自增列或自增数据类型

违反规范的影响：

  • 自增序列或自增数据类型在大量使用时，会造成GTM压力过大及序列生成速度慢。

方案建议：

  • 如果只是想获取一个唯一标识，可以使用UUID。
  • 如果必须使用自增序列，在没有严格递增的需求，可设置CACHE，比如1000，降低GTM压力。

相关文档