1

これは、実行したい最小限のクエリ ステートメントです。

    select count(*) from temper_300_1 group by onegid;

ただし、「where」句も必要です。私がやろうとしているのは、ヒストグラム クエリを作成し、特定の「onegid」を持つ要素の数を決定することです。クエリは、8 億行で約 7 秒かかります。誰かがより速い代替案または最適化を提案できますか。

私は実際に緯度と経度で構成される空間データからヒートマップをプロットしようとしていました。各要素にグリッド ID を割り当てましたが、「集約によるグループ化」は時間の面でかなりコストがかかります。

4

2 に答える 2

0

クエリに関連するパフォーマンスには、分散と行サイズ/エクステント密度という 2 つの主な考慮事項があると思います。

分布：

@jeremytwfortune が言及しているように、データがほとんど偏りなく適切に分散されていることが重要です。Netezza などの MPP システムでは、最も遅いデータ スライスと同じ速さしかありません。1 つのデータ スライスに残りの 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のみを指定して、temper_300_1 に対してクエリを実行すると、オプティマイザーはマテリアライズド ビューのみを参照します。これにより、特定の 3MB エクステントにより多くの行をパックできます。これにより、パフォーマンスが大幅に向上する可能性があります。

MVIEW 作成ステートメントの ORDER BY 句も、MVIEW の圧縮の効果を高める可能性が高く、特定の数の行を保持するために必要なエクステントの数をさらに減らし、パフォーマンスをさらに向上させます。

于 2015-08-10T23:10:39.567 に答える