分区

只对大型表分区。不要分区小表。

只有能基于查询条件实现分区消除（分区剪枝）时才使用分区。

选择范围分区而舍弃列表分区。

基于查询谓词对表分区。

不要在同一列上对表进行分布和分区。

不要使用默认分区。

不要使用多级分区，创建较少的分区让每个分区中有更多数据。

通过检查查询的EXPLAIN计划验证查询有选择地扫描分区表（分区被消除）。

不要用列存储创建太多分区，因为每个Segment上的物理文件总数：物理文件数 = Segment数 x 列数 x 分区数

一种好的分区策略通过只读取满足查询所需的分区来降低被扫描的数据量。

每个分区在每一个 Segment上都是一个单独的物理文件。就像在宽列存表中读取一整行比从对表读取同一行需要更多时间一样，在分区表中读取所有分区比从非分区表中读取相同的数据要求更多的时间。

下面是分区的最佳实践：

只分区大型表，不要分区小型表。

仅当可以基于查询条件实现分区消除（分区剪枝）并且可以基于查询谓词对表分区来完成分区消除时才在大型表上使用分区。优先使用范围分区而不是列表分区。

优先选择范围分区而不是列表分区。

只有当查询包含表的使用不可变操作符（例如=、<、<= 、>、>=以及<>）的直接简单限制时，查询规划器才能有选择地扫描分区表。

选择性扫描会识别STABLE和IMMUTABLE函数，但是不识别查询中的VOLATILE函数。例如，

date > CURRENT_DATE

之类的WHERE子句会导致查询规划器选择性地扫描分区表，但

time > TIMEOFDAY

之类的WHERE子句却不行。有必要通过检查查询的EXPLAIN计划来验证查询是否选择性地扫描分区表（分区被消除）。

不要使用默认分区。默认分区总是会被扫描，但是更重要的是，在很多环境下它们会被装得过多导致糟糕的性能。

绝不在相同的列上对表分区和分布。

不要使用多级分区。虽然支持子分区，但并不推荐使用这种特性，因为通常子分区包含很少的数据或者不包含数据。分区或者子分区数量增加时性能也增加简直就是天方夜谭。维护很多分区和子分区的管理负荷将会压过得到的性能收益。为了性能、可扩展性以及客观理性，请在分区扫描性能和总体分区数量之间做出平衡。

谨防对列式存储使用太多分区。

考虑负载并发性以及为所有并发查询打开并且扫描的平均分区数。

分区和列存文件的数量

对Greenplum数据库支持的文件数的唯一硬限制是操作系统的打开文件限制。但是，有必要考虑集群中文件的总数、每个Segment上的文件数以及一台主机上的文件总数。在一个MPP无共享环境中，每一个节点都独立于其他节点操作。每个节点受到其磁盘、CPU和内存的约束。CPU和I/O约束对Greenplum数据库并不常见，但内存常常是一种限制因素，因为查询执行模型会在内存中优化查询性能。

每个Segment上的最优文件数也基于该节点上的Segment数量、集群的大小、SQL访问、并发、负载和倾斜等因素而变化。通常在每台主机上有六到八个Segment，但更重要的是考虑每个Segment的文件数和节点上的文件总数。

例子 DCA V2 每节点64GB内存

节点数：16

每节点的Segment数：8

每个Segment的平均文件数：10,000

每节点上的文件总数是810,000 = 80,000，而该集群的文件总数是816*10,000 = 1,280,000。随着分区数和列数的增加，文件数会快速增加。

作为一种通常的最佳实践，请把每节点的文件总数限制为低于100,000。如上一个例子所示，每个Segment的最优文件数和每节点的文件总数取决于节点的硬件配置、集群的大小、SQL访问、并发性、负载以及倾斜。

————————————————

版权声明：本文为CSDN博主「学亮编程手记」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。

原文链接：https://blog.csdn.net/a772304419/article/details/145200427

————————————————

版权声明：本文为CSDN博主「学亮编程手记」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。

原文链接：https://blog.csdn.net/a772304419/article/details/145200427