Redshiftで遊ぼう~アソシエーション分析~(後編)

まえがき

Redshiftで遊ぼう~共起分析~(前編)の続きです。

前回作成したクエリではまだ DS_BCAST_INNERが発生しており、改善できる余地があるように思われます。

今回のエントリではこれを解消するとともに、クエリを作っていくときの注意点をまとめてみます。

DISTKEYは1テーブルに1つだけ

前回のエントリで以下のように書きました。

ここはどうしても2列が結合に使われてしまうために、 DISTKEYを付けられないのです

ではどうしようもないのかというと、そんなことはありません。 こういうときのために DISTSTYLE ALL があるのです。

改訂その2

ではさっそく・・・ DS_BCAST_INNER をすべて回避した!というのがこちら

そして突撃・・・8分50秒・・・変わらなくね?実行計画を見てみます。

残っていた DS_BCAST_INNER も回避し、 DS_DIST_ALL_NONE が出てきています。 全体的に cost も低下しています。 多少早くなってくれても良さそうなものなのですが・・・。

システムテーブル

ここでクエリのパフォーマンスを別のところから見てみます。

svl_query_summary ビューは、 実行されたクエリに関するパフォーマンス情報を持っています。
実行計画と違い、こちらは『実際に実行されたときの記録』なので、パフォーマンスを知りたいのであればむしろこちらを見たほうが良いです。

このビューは名前のとおり サマリ なので、ノードやスライスごとの詳細まで見たければ、 svl_query_report を参照することで確認できます。

ちなみに svv_query_state という非常にそれっぽいビューがありますが、 こいつの中身は常に空っぽです。。。1

詳細まで見ていくとしんどいので、サマリを確認してみます。

まずは前回エントリの『初版』のクエリから

★印をつけたところが DS_BCAST_INNER 発生箇所と考えられます。

続いて『改訂1』

初版と比べると★印が1個減っています。
これは前回実行計画を見たとおり DS_BCAST_INNERDS_DIST_NONE に変わったためと考えられます。

そして今回作成した『改訂2』

このとおり★印が無くなっています。めでたしめでたし・・・ではなく、改訂2は結果からすると「やりすぎ」です。

『改訂1』のサマリによると、今回解消した DS_BCAST_INNER に要した時間は最大でも600マイクロ秒程度、 対象となったデータサイズは750キロバイト程度だということが見て取れます。
さらに、 DISTSTYLE ALL を選択した事によって全ノードに同じデータを持つ事になり、容量を余分に消費してしまうことになります。

改訂1→改訂2で実行時間がほとんど変化しなかった理由もここにあります。
つまり、 DS_BCAST_INNER されても問題ない程度のデータ容量なのであれば、Redshiftのパワー2を見越して放置するという選択肢もありえるというわけです。

改訂1では、実行時に DS_BCAST_INNER されてしまうものの、パフォーマンスに与える影響は軽微、かつ、容量の増加は一時的なもの、となります。
改訂2では、 DISTSTYLE ALL したテーブルを放置しないようにするための別の仕組みが必要となってきます。

まとめ

  • 結合を複数列でやるなら DISTSTYLE ALL を使えないか考える
  • システムテーブル可愛い
  • Redshiftすごい
  • でも、やりすぎはよくない

数字ばっかりで見るのがしんどいのですが、以上です。