Netezza 中的“分组依据”聚合是否有更快的替代方法？答案

【问题标题】：Is there a faster alternative to "group by" aggregation in Netezza?Netezza 中的“分组依据”聚合是否有更快的替代方法？
【发布时间】：2015-08-07 19:41:10
【问题描述】：

这是我要执行的最小查询语句。

    select count(*) from temper_300_1 group by onegid;

不过，我确实也有“where”子句。我想要做的是建立一个直方图查询并确定具有特定“onegid”的元素数量。查询 8 亿行大约需要 7 秒。有人可以提出更快的替代方案或优化方法吗？

我实际上是在尝试从由纬度和经度组成的空间数据中绘制热图，我为每个元素分配了一个网格 ID，但是“按聚合分组”在时间方面的成本很高。

【问题讨论】：

您的表是否正确编入索引？ mysql 是否允许使用足够的 RAM 来将整个索引保存在内存中？等
这样会得到相关的表信息：SHOW CREATE TABLE temper_300_1\G

标签： sql netezza spatial-query date-histogram

【解决方案1】：

您不会比group by 更快，尽管您当前的查询不会显示与每个计数关联的组项。

确保表格正确分布

select datasliceid, count(1) from temper_300_1 group by onegid;

计数应该大致相等。如果不是，您的 DBA 需要在更好的分配键上重新分配表。

如果是，您可以要求您的 DBA 在该特定列上创建一个 materialized view，按该列排序。您可能会看到一些性能提升。

【讨论】：

【解决方案2】：

我想说，与您的查询相关的性能有两个主要考虑因素：分布和行大小/范围密度。

分布：

正如@jeremytwfortune 所提到的，重要的是您的数据分布良好且几乎没有偏差。在诸如 Netezza 之类的 MPP 系统中，您的速度仅与最慢的数据片一样快，如果一个数据片的数据是其余数据片的 10 倍，那么它可能会拖累您的性能。

另一个分布注意事项是，如果您的表尚未分布在 onegid 上，当查询运行以支持您的 时，它将在 onegid 上动态重新分布>GROUP BY onegid 子句。这将发生在 GROUP BY 和带有 PARTITION BY 的窗口聚合中。如果 onegid 值的分布不是相对均匀，您可能会面临处理偏差。

如果您的表已经分布在 onegid 上并且您不提供任何其他 WHERE 谓词，那么从这个角度来看，您可能已经进行了最佳配置。

行大小/范围密度

当 Netezza 读取数据以支持您的查询时，每个数据片将读取其磁盘的 3 MB 扩展区。如果您的行比 onegid 值宽得多，那么您从磁盘读取的数据将超过回答查询所需的数据。如果您的表很大，您的行比 onegid 更宽，并且查询时间性能至关重要，那么您可以考虑创建一个物化视图，如下所示：

CREATE MATERIALIZED VIEW temper_300_1_mv AS select onegid from temper_300_1 ORDER BY onegid;

当您在 SELECT 子句中仅使用 onegid 对 temp_300_1 执行查询时，优化器将仅引用物化视图，该视图将能够将更多行打包到给定的 3MB 范围内。这可以显着提升性能。

MVIEW 创建语句中的 ORDER BY 子句还可能提高 MVIEW 压缩的有效性，进一步减少保存给定行数所需的区数，并进一步提高性能。

【讨论】：