Amazon Redshift クエリを設計するためのベストプラクティス

このセクションでは、クエリを設計するためのベストプラクティスの概要を説明します。最適なクエリパフォーマンスと効率を実現するために、このセクションのベストプラクティスに従うことをお勧めします。

SELECT * FROM ステートメントを使用しない

SELECT * FROMステートメントを使用しないことをお勧めします。代わりに、分析する列を必ず一覧表示してください。これにより、クエリの実行時間が短縮され、Amazon Redshift Spectrum クエリのスキャンコストが削減されます。

避けるべきことの例

select * 
from sales;

ベストプラクティスの例

select sales_date, sales_amt
from sales;

クエリの問題を特定する

STL_ALERT_EVENT_LOG ビューを確認して、クエリで発生する可能性のある問題を特定して修正することをお勧めします。

クエリの概要情報を取得する

クエリの概要情報を取得するには、SVL_QUERY_SUMMARY ビューと SVL_QUERY_REPORT ビューを使用することをお勧めします。この情報を使用してクエリを最適化できます。

クロス結合を避ける

絶対に必要な場合を除き、クロス結合を使用しないことをお勧めします。結合条件がない場合、クロス結合により 2 つのテーブルのデカルト積が生成されます。クロス結合は通常、ネストされたループ結合 (可能な結合タイプの中で最も遅い) として実行されます。

避けるべきことの例

select c.c_name, 
          n.n_name 
from tpch.customer c, 
        tpch.nation n;

ベストプラクティスの例

select c.c_name, 
           n.n_name 
from tpch.customer c, 
join tpch.nation n
  on n.n_nationkey = c.c_nationkey;

クエリ述語での関数の回避

クエリ述語で関数を使用しないことをお勧めします。クエリ述語で関数を使用すると、パフォーマンスに悪影響を与える可能性があります。関数は通常、各行に処理オーバーヘッドを追加し、クエリの実行全体を遅くするためです。

避けるべきことの例

select sum(o_totalprice)
from tpch.orders
where datepart(year, o_orderdate) = 1992;

ベストプラクティスの例

select sum(o_totalprice)
from tpch.orders
where o_orderdate between '1992-01-01' and '1992-12-31';

不要なキャスト変換を避ける

データ型のキャストには時間とリソースが必要で、クエリの実行が遅くなるため、クエリで不要なキャスト変換を使用しないことをお勧めします。

避けるべきことの例

select sum(o_totalprice)
from tpch.orders
where o_ordertime::date = '1992-01-01';

ベストプラクティスの例

select sum(o_totalprice)
from tpch.orders
where o_ordertime between '1992-01-01 00:00:00' and '1992-12-31 23:59:59';

複雑な集計に CASE 式を使用する

同じテーブルから複数回選択するのではなく、CASE 式を使用して複雑な集計を実行することをお勧めします。

避けるべきことの例

select sum(sales_amt) as us_sales
from sales
where country = 'US';

select sum(sales_amt) as ca_sales
from sales
where country = 'CA';

ベストプラクティスの例

select sum(case when country = 'US' then sales_amt end) as us_sales,
           sum(case when country = 'CA' then sales_amt end) as ca_sales
from sales;

サブクエリを使用する

クエリ内の 1 つのテーブルが述語条件にのみ使用され、サブクエリが少数の行 (約 200 未満) を返す場合は、サブクエリを使用することをお勧めします。

避けるべきことの例

サブクエリが返す行数が 200 行未満の場合：

select sum(order_amt) as total_sales
from sales
where region_key IN
        (select region_key
         from regions
         where state = 'CA');

ベストプラクティスの例

サブクエリが 200 行以上を返す場合：

select sum(o.order_amt) as total_sales
from sales o
join regions r
  on r.region_key = o.region_key
  and r.state = 'CA';

述語を使用する

述語を使用してデータセットをできるだけ制限することをお勧めします。述語は、クエリで返されるデータをフィルタリングおよび制限するために SQL で使用されます。述語で条件を指定することで、指定した条件に基づいてクエリ結果に含める行を指定できます。これにより、関心のあるデータのみを取得でき、クエリの効率と精度が向上します。詳細については、Amazon Redshift ドキュメントの「条件」を参照してください。

結合でテーブルをフィルタリングする述語を追加する

述語が同じフィルターを適用する場合でも、結合に参加するテーブルをフィルタリングするために述語を追加することをお勧めします。述語を使用して SQL の結合でテーブルをフィルタリングすると、処理する必要があるデータの量を減らし、中間結果セットのサイズを減らすことで、クエリのパフォーマンスを向上させることができます。WHERE 句で結合オペレーションの条件を指定することで、クエリ実行エンジンは、結合前に条件に一致しない行を削除できます。これにより、結果セットが小さくなり、クエリの実行が高速化されます。

避けるべきことの例

select p.product_name, sum(o.order_amt)
from sales o
join product p
   on r.product_key = o.product_key
where o.order_date > '2022-01-01';

ベストプラクティスの例

select p.product_name, sum(o.order_amt)
from sales o
join product p
  on p.product_key = o.product_key
  and p.added_date > '2022-01-01'
where o.order_date > '2022-01-01';

述語に最も安価な演算子を使用する

述語では、できるだけ安価な演算子を使用します。比較条件演算子は LIKE 演算子よりも優先されます。 LIKE演算子は、SIMILAR TO 演算子または POSIX 演算子よりも引き続き優先されます。

GROUP BY 句でソートキーを使用する

GROUP BY 句でソートキーを使用すると、クエリプランナーはより効率的な集計を使用できます。GROUP BY クエリのリストにソートキー列のみが含まれている場合、クエリは 1 フェーズ集約の対象となることがあります。その 1 つは分散キーでもあります。GROUP BY リスト内のソートキー列には、最初のソートキーと、ソートキーの順序で使用する他のソートキーを含める必要があります。

マテリアライズドビューを活用する

可能であれば、複雑なコードをマテリアライズドビューに置き換えてクエリを書き換えます。これにより、クエリのパフォーマンスが大幅に向上します。詳細については、Amazon Redshift のドキュメントの「Amazon Redshift でのマテリアライズドビューの作成」を参照してください。

GROUP BY 句と ORDER BY 句の列に注意してください

ORDER BY GROUP BY 句と 句の両方を使用する場合は、列を GROUP BY句と ORDER BY句の両方に同じ順序で配置してください。 GROUP BY では、データを暗黙的にソートする必要があります。ORDER BY 句が異なる場合は、データを 2 回ソートする必要があります。

避けるべきことの例

select a, b, c, sum(d)
from a_table
group by b, c, a
order by a, b, c

ベストプラクティスの例

select a, b, c, sum(d)
from a_table
group by a, b, c
order by a, b, c