1

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

    select count(*) from temper_300_1 group by onegid;

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

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

4

2 回答 2

1

group by尽管您当前的查询不会显示与每个计数相关联的组项，但您的速度不会比 快得多。

确保表格正确分布

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

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

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

于 2015-08-09T00:06:56.453 回答
0

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

分配：

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

另一个分布注意事项是，如果您的表尚未分布在onegid上，当查询运行以支持您的GROUP BY onegid子句时，它将在 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 压缩的有效性，进一步减少保存给定行数所需的区数，并进一步提高性能。

于 2015-08-10T23:10:39.567 回答