WHERE句と小さなテーブルとの比較

Question

WHERE句を持つテーブルのクエリ時間に意味のある差異（または特定のテーブルサイズについての経験則）があるかどうかは、結果セットをサイズに等しい小さなテーブルと比較して制限しますポストWHEREの、限定された結果セット？例えば

：

1. あなたのテーブルには、長年にわたるタイムスタンプを持つレコードを持っています。結果を過去10日間に限定するWHERE句を含むクエリを実行します。

2. テーブルのデータはわずか10日間で、上記と同じクエリを実行します（WHERE句がない場合は明らかです）。

上記の2つのシナリオでクエリのパフォーマンスの違いが見込まれますか？私はRedshiftを使用していることに注意してください。明らかに、シナリオ2のメリットの1つである、より少ないデータを格納するコストを$$削減することができます。

Answer 1

テーブルとインデックスに完全に依存します（ソートキーのシフトキーの場合）。伝統的に、タイムスタンプに降順のインデックスがあり、where句でタイムスタンプを使用すると、クエリエンジンは必要なレコードをすばやく見つけて探しを停止します。

2つのテーブルを保持していても、レコードを少なくすることでメリットがあるかもしれませんが、パフォーマンス上のメリットが実際に必要であることがテストで分かった場合は、

Answer 2

Redshiftでは、答えは「はい」です。大きなテーブルのwhere句ではなく、より小さなテーブルをクエリする方が速いです。これはRedshiftが一般的にテーブル内のすべての行をスキャンするためです。少なくとも配布/ソートキーの最適化によって除外されていない行。ストレージは通常、容量が赤方偏移のクラスタを計画する決定要因ではないので、それがある -

も赤方偏移ストレージが安価であるほとんどすべての場合には、この質問

の他の重要な側面に対処することができます。これは、実行するクエリに必要なパフォーマンスを得ることに関するものです。

1. Redshiftクエリのパフォーマンスを4つの方法で向上させることができます。 クラスタのサイズを大きくします。
2. クエリをチューニングします。
3. の内容と使用パターンを考慮して、Redshiftテーブルの定義を変更します。ソートと分散キーは の大きな違いになります。圧縮タイプも考慮する必要があります。
4. 優先順位の高いクエリを優先するため、Redshiftのパフォーマンス管理を実装します。