複数のソートキー列を持つことは何を意味しますか？

Question

Redshiftでは、複数の列をSORTKEY列と指定できますが、ベストプラクティスのドキュメントのほとんどは、単一のSORTKEYがあるかのように記述されています。

SORTKEY (COL1, COL2)で表を作成すると、すべての列がCOL1、次にCOL2でソートされて格納されますか？あるいは、それがカラム型ストアなので、各カラムは異なる順序で格納されますか？私。 COL1の順番のCOL1、COL2の順のCOL2、および他の列は順不同ですか？

私の状況は、（とりわけ）type_idとtimestamp列を持つテーブルがあるということです。データはおおよそタイムスタンプ順に到着します。ほとんどのクエリは、type_idとtimestampの両方によって結合/制限されます。通常、type_id句はより具体的です。つまり、timestamp句を調べるよりも、type_id句を調べるほうがはるかに多くの行を除外できます。このため、type_idはDISTKEYです。私はSORTKEY (type_id)、SORTKEY (stamp)、SORTKEY (type_id,stamp)、SORTKEY (stamp,type_id)の賛否両論を理解しようとしています。

ありがとうございました。

Answer 1

あなたがSORTKEY(COL1, COL2)を宣言した場合は、すべての列は、COL2ORDER BY (COL1, COL2)かのように行われた、COL1でソートされます。

SORTKEYを使用してJOINを高速化する場合は、結合するテーブルに同じSORTKEYを使用する限り、AFAIUは問題ありません。なぜなら、マージ結合が起こるためです。

がtype_idのように選択性が高い場合は、同じ番号の小さい行があることを意味します。type_idしたがって、別の列をSORTKEYに追加することはできますが、ほとんどの行削除がすでに発生しているため、そのユーティリティは制限されています。

COL1は（ところで少し奇妙である;？私はそれがtype_idより選択的であることが予想されるだろうとにかく...）あなたのstampのような非常に選択されていない場合、それはstampによるフィルタリングは、それほど排除しないことを意味します行。したがって、2番目のソートキーを宣言するのがより理にかなっています。しかし、以前の行を削除する方が安価であるため、これは他の方法より効率が悪いです。 stampでフィルタリングすることがありますが、type_idではフィルタリングしない場合は、これを行うのが理にかなっています。

Answer 2

私たちはRedshiftも使用しており、約20億レコード（毎日+20百万）があり、sort_keyの選択肢が少ないほど、sort_keyリストの方が多くなるはずです。

私たちの場合（最初のsort_keyとしてタイムスタンプを使用して、独自のデータを使用/クエリする方法を分析することをお勧めします）。これに伴う問題は、1秒以内に約200行を記録することで、1MBのブロックには数秒しかかからず、その1つのブロック内のすべてのタイプのデータが含まれるということです。意味は、たとえタイムスタンプが高度に選択的であっても、すべてのブロックにすべての種類のデータがあるので、実際にはフィルタリングできないからです。

最近、sort_keysの順序が逆になりました。最初のものは約15個の異なる値を持ち、2番目の値は約30個などです。タイムスタンプは最後のものですが、依然として1ブロックはまだ秒単位で測定されます。

古い解決策：1年間のデータを選択して月を選択すると、ブロックの91％が削除されますが、開いた後に削除されます（これは最初の2つのsort_keysをフィルタとして頻繁に使用します）。そのすべてを、さらにフィルタリングしたいとは思っています。

新しいソリューションは、日付範囲に関係なく、最初のステップで約14/15のブロックを削除し、残っているものの約95％、タイムスタンプは残りのものの91％を引き下げます。

ソートキーの順番を除いて、同じ8億個のレコードテーブルを使用して完全にテストしました。 'where'節の期間が長くなればなるほど、良い結果が得られます。明らかに結合の場合にはさらに重要になります。

あなたのデータベースと頻繁に実行するクエリの種類がわかります。なぜなら、最も選択的な列が最初のsort_keyとして最適でない可能性があるからです。塩野信夫が言ったように、それはすべてあなたがフィルタリングしているものによって決まります。

Answer 3

私は

はフィルタ

のものがでそれらを考慮考える参加、sort_keyの注文が

1. distの中のもの、フィルタ考えると
最初の結合フィルタのものを検討する必要がありますと言うだろう参加する
3. は、グループ順に（ウィンドウ機能を含む）考慮する（ウィンドウ関数を含む）

一般的なルール：同じレベルの場合、最初に基数を下げます。