top of page
検索
  • a k

Redshiftとソートキー

はじめに

Redshiftのソートキーはすっごく重要です。

  1. 最速JOINはマージJOIN

  2. Group byでもソートキーが使用される

  3. WHEREでレコードを絞り込むときにも有効

どの場合もソートキーの項目順をちゃんと合わせてないといけません。特に夜間バッチでよく使われる全件突合+全件出力ではマージJOINを目指します。


ソートキーの利用


マージJOIN

条件

JOINのキーに分散キー、ソートキーが使用されているソートキーの順番が同じ

これは効き目がめっちゃ大きいのでぜひとも狙いたいところ。


Group by

条件

集計キーに分散キー、ソートキーが使用されているソートキーの上位から歯抜けにならずに集計キーに使ってること

マージJOINと同じ条件ですね。これもソート済の特性をうまく利用されるので集計元テーブルのソートキーはちょっと注目ソートキーははWindow関数のグルーピングでも使用されます。


Where

条件

絞り込みの条件に先頭のソートキーが含まれてること。2つのソートキーが設定されている場合に、効率的に検索する場合にはwhereで先頭に設定されているソートキーが指定されていることが必須。そうしないとゾーンマップ(データブロック毎の最大最小値データ)が使用できない。

先頭のソートキーがWhereに含まれてると、絞り込みが激速です。絞り込みされる処理ではその後のJOINがハッシュJOINになっても気にしない。


ソートについて

ソート処理

ソートキーを使うためにはソート処理が動きますが、ソート自体は負荷が高い処理なので、リソースも多く使います。


ソートのディスク容量

ソートするためには一時領域が必要なので、メモリに乗らないような大きなデータをソートするとソート用の領域としてディスクが使用されます。どでかいデータを一発INSERTする時にディスクの使用率が一時的に上がるのは(たぶん)そのためです。

Disk増加の回避策は

やったことないけど 第一ソートキーの条件でテーブルを複数に分割。 そのテーブルをUNIONのVIEWで繋いで使用する。  ゾーンマップはうまく使われるはずだけど、マージJOINに持って言ってくれるかは未知数


おわりに

一時的なディスク容量って、結構使うから嫌ですよね。どうしてもディスクが跳ねるときは第一ソートキーのmodなどで参照データを均等数に絞り込んで、同じSQLを2〜3回に分けて流す方が早かったりする。なんで2〜3回かって言うと、それで動かないようだと根本的な処理構成/データ構造を見直したほうが良いと思う。当然だけど、分散キーで分けちゃだめ。


以上


閲覧数:123回0件のコメント

最新記事

すべて表示

Quick Sightの分析のクロスアカウントコピー

はじめに 今回のブログではQuick Sightで作成した分析をクロスアカウントコピーするための方法を紹介します。 開発環境で作成した分析を本番環境にコピーしたい時などにこの方法が使えるのではないかと思います。 2024/07/12追記 QuickSightでアセット(データセット・分析・ダッシュボードなど)を管理する機能が追加されました。この機能を使って、アセットを複製する記事はこちらで紹介され

Amazon Redshiftのクエリがなぜかたまに遅くなる原因

始めに 弊社では、膨大なデータの夜間バッチ処理にRedshiftを採用しています。 適材適所でサービスを選択しており、夜間以外はお役御免で停止しておき、費用面を抑えるよう工夫しています。 メンテナンスウィンドウも設けて運用していて概ね問題なく稼働しています。 しかし、稀に全体的にクエリが遅くなってしまう謎の事象に悩まされていました。 今回この事象の原因を突き止めたので、その内容を共有したいと思いま

Commentaires


bottom of page