29

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

でテーブルを作成するとSORTKEY (COL1, COL2)、すべての列が COL1、次に COL2 でソートされて保存されるということですか? それとも、カラム型ストアであるため、各カラムが異なる順序で格納されるのでしょうか? つまり、COL1 の順序で COL1、COL2 の順序で COL2、および順序付けされていない他の列ですか?

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

ありがとう。

4

3 に答える 3

19

を宣言するSORTKEY(COL1, COL2)と、すべての列が でソートされCOL1COL2まるで完了したかのようになりORDER BY (COL1, COL2)ます。

JOINを高速化するために使用している場合、AFAIUは、マージ結合が発生するため、結合されるテーブルでSORTKEY同じものを使用する限り問題ではありません。SORTKEY

COL1が のように非常に選択的である場合type_id、同じ を持つ行が少数しかないことを意味しますtype_id。したがって、別の列を SORTKEY に追加することはできますが、ほとんどの行の削除が既に行われているため、その有用性は制限されています。

COL1あなたのように高度に選択的でない場合stamp(これは少し奇妙です; とにかく..よりも選択的であると予想していたでしょうtype_id)、それは、によるフィルタリングでstampはそれほど多くの行が削除されないことを意味します。したがって、2 番目のソート キーを宣言する方が理にかなっています。ただし、以前に行を削除する方がコストがかからないため、これは他の方法よりも効率的ではありません。stampではなく でフィルタリングすることがある場合はtype_id、これを行うのが理にかなっているかもしれません。

于 2013-07-07T08:44:39.667 に答える
17

Redshift も使用しており、約 20 億件のレコード (毎日 +2000 万件) があります。

私たちの場合 (そして、自分のデータをどのように使用/クエリするかを分析することをお勧めします)、タイムスタンプを最初の sort_key として使用しました。これに関する問題は、1 秒以内に約 200 行を記録することです。その結果、1 MB のブロックには数秒しか含まれず、その 1 つのブロックにすべての種類のデータしか含まれません。つまり、タイムスタンプは非常に選択的ですが、すべてのブロックにあらゆる種類のデータがあるため、実際にはさらにフィルタリングすることはできません.

最近、sort_keys の順序を逆にしました。最初の値には約 15 の異なる値があり、2 番目の値には約 30 の値があります。タイムスタンプは現在最後の値ですが、それでも 1 つのブロックは秒単位で測定されます。

この結果、(最初の 2 つの sort_keys をフィルターとして非常に頻繁に使用するため) 次のようになります。さらにフィルタリングしたいのですが。

新しいソリューションでは、日付範囲に関係なく、最初のステップでブロックの約 14/15 が削除され、次に残りのブロックの約 95% が削除され、タイムスタンプは残りのブロックの 91% が削除されます。

2 つの 8 億レコード テーブルを使用して徹底的にテストしましたが、これらはソート キーの順序を除いて同じでした。「where」句の期間が長いほど、より良い結果が得られました。明らかに結合の場合はさらに重要になります。

したがって、私の提案は、データベースと、頻繁に実行するクエリの種類を把握することです。最も選択的な列が最初のソートキーとして最適ではない可能性があるためです。役野塩路が言ったように、すべてはあなたが何をフィルタリングしているかによって異なります。

于 2014-06-15T14:25:32.793 に答える
3

の順序sort_key

  1. distにあるものを考慮し、最初にフィルターして結合します
  2. フィルター内のものを考慮し、結合します
  3. フィルター内のものを考慮する
  4. 参加者を考慮する
  5. group by、order by(ウィンドウ関数を含む)でそれらを考慮する

一般的なルール:同じレベルの場合は、カーディナリティが低いほうが優先されます。

于 2015-04-14T21:22:42.557 に答える