Greenplum 数据库 - Count Distinct Queries 缓慢的问题

Posted 2023-03-31

【中文标题】Greenplum 数据库 - Count Distinct Queries 缓慢的问题

【英文标题】：Greenplum Database -Problem of Count Distinct Queries Slowness

【发布时间】：2021-09-28 19:04:37

【问题描述】：

我们正在为数据仓库使用 Greenplum OSS 版本，并在其中提供数 TB 的数据。

我们有一个特殊的问题是 Count(distinct) 查询不执行，并且执行计划是由 Postgres 查询优化器而不是 GPORCA 准备的

以下是有关问题的详细信息。 任何人都可以提供相同的帮助

基础设施背景：- 一种。 8 个数据节点的集群 湾。每个节点上 16 个 vcpu C。每个节点上 32 GB RAM d。每个节点 8 个段 e.集群 IOPS - 读取 - ~4 GB/s

数据背景：-

1.2 亿条记录的完全分布式表 - 64 个段 每个 Segment 包含 – 200 万条记录

需求背景和面临的问题：-

20+ 独立属性被探测为动态时间输入的不同值。 （需要注意的重点->这些属性本质上是独立的，因此不能通过group by子句将它们组合在一起，并且需要distinct）

Count(distinct) - 我们需要在 10 秒内的交互式查询响应来处理仪表板的这些计数。 （但获得 180+ 秒的响应时间）

我们的分析：-

根据解释计划，甚至没有为这些查询调用 GPORCA，并且 Postgres 查询优化器正在准备执行计划 我们尝试创建追加优化的行/列表，以尝试增加响应时间，但没有明显的改进。 关闭 - “optimizer_force_multistage_agg” - 未产生任何效果。- 响应时间 - 192 秒 关闭 - “enable_groupagg” - 未产生任何效果 - 响应时间 - 192 秒 开启 - “enable_hashagg” - 响应时间 - 120 秒

基于以上事实，我们想知道

为什么没有启用 GPORCA 优化器 为什么 count(distinct) 查询花费的时间比 count(*) 查询多 15 倍。是否未使用并行化。 我们如何优化这些查询。 是否有其他替代方案可以满足此要求。

【参考方案1】：

几个观察：

只是为了确认一下，ORCA 已在数据库范围内开启（优化器=开启）？ 具有 16 个 vCPU 的 8 个段的 CPU 与段的比率为 2:1。 VMmware 一般建议每段 3-4 个 cpu 32 GB RAM 对我来说对于每个主机这么多段来说似乎有点小。

问题：

您是否在表上运行了 analyze 或 analyzeb（不确定是否是开源版本）以确保统计信息完全是最新的？ 您是在 20 个属性中的 1 个上执行 select distinct，还是您正在运行 select distinct on 的多个属性的组合？如果是第一个，是否在最常用的列上建立了索引？ 您是否尝试过对查询进行解释分析，以便准确了解问题所在？ 这个表有多少列？

吉姆·麦肯 VMware Tanzu 数据