Amazon Redshift の多次元データレイアウトソートキーにより、反復スキャンフィルターを含むワークロードのパフォーマンスを向上

最も広く使用されているクラウドデータウェアハウスである Amazon Redshift は、最も要求の厳しいワークロードのパフォーマンス要件を満たすために大幅に進化しました。この記事では、その新機能の 1 つである多次元データレイアウトソートキーについて説明します。

Amazon Redshift は、多次元データレイアウトソートキーをサポートすることでクエリのパフォーマンスを向上させました。多次元データレイアウトソートキーは、テーブルの物理的なカラムではなくフィルター述語でテーブルのデータをソートする新しいタイプのソートキーです。多次元データレイアウトソートキーは、特にクエリワークロードに反復スキャンフィルターが含まれている場合に、テーブルスキャンのパフォーマンスを大幅に向上させます。

Amazon Redshift にはすでに自動テーブル最適化 (ATO) 機能が用意されており、管理者の介入なしにソートキーと分散キーを適用してテーブルの設計を自動的に最適化します。この投稿では、 ATO が提供する追加機能として、Amazon Redshift のソートキーアドバイザーアルゴリズムによって強化された多次元データレイアウトソートキーを紹介します。

多次元データレイアウトソートキー

AUTO ソートキーを使用してテーブルを定義すると、Amazon Redshift ATO はクエリ履歴を分析し、ワークロードに適したオプションに基づいて、テーブルの単一カラムのソートキーまたは多次元データレイアウトソートキーを自動的に選択します。多次元データレイアウトを選択すると、Amazon Redshift は、通常同じクエリでアクセスされる行を同じ場所に配置する多次元ソート関数を構築し、その後、クエリ実行中にソート機能を使用してデータブロックをスキップしたり、個々の述語カラムのスキャンをスキップしたりします。

次のユーザークエリを考えてみましょう。これは、ユーザーのワークロードの主なクエリパターンです。

SELECT season, sum(metric2) AS "__measure__0"
FROM titles
WHERE lower(subregion) like '%United States%'
GROUP BY 1
ORDER BY 1;

Amazon Redshift は、各カラムのデータを 1 MB のディスクブロックに格納し、テーブルのメタデータの一部として各ブロックの最小値と最大値を格納します。クエリで範囲が制限された述語を使用する場合、Amazon Redshift は最小値と最大値を使用して、テーブルスキャン中に大量のブロックをすばやくスキップできます。ただし、このクエリの subregion カラムのフィルターでは、最小値と最大値に基づいてスキップするブロックを決定することはできません。その結果、Amazon Redshift は titles テーブルのすべての行をスキャンします。

SELECT table_name, input_rows, step_attribute
FROM sys_query_detail
WHERE query_id = 123456789;

subregion を使用したシングルカラムのソートキーを使用し、 titles テーブルを指定してユーザーのクエリを実行した場合、前述のクエリの結果は次のようになります。

  table_name | input_rows | step_attribute
-------------+------------+---------------
  titles     | 2164081640 | 
(1 rows)

これは、テーブルスキャンが 2,164,081,640 行を読み取ったことを示しています。

titles テーブルのスキャンを改善するために、Amazon Redshift は多次元データレイアウトソートキーの使用を自動的に決定する場合があります。述語 lower(subregion) like '%United States%'を満たす行はテーブルの専用の領域に全て配置されるため、Amazon Redshift は述語を満たすデータブロックのみをスキャンします。

述語 lower(subregion) like '%United States%' を含む多次元データレイアウトソートキーを使用して titles テーブルを指定してユーザーのクエリを実行すると、sys_query_detail クエリーの結果は次のようになります。

  table_name | input_rows | step_attribute
-------------+------------+---------------
  titles     | 152324046  | multi-dimensional
(1 rows)

これは、テーブルスキャンが元のデータの 7% に過ぎない 152,324,046 行を読み取り、多次元データレイアウトソートキーを使用したことを示しています。

この例では 1 つのクエリを使用して多次元データレイアウト機能を紹介していますが、Amazon Redshift はテーブルに対して実行されるすべてのクエリを考慮し、最も一般的に実行される述語を満たす複数の領域を作成できることに注意してください。

今度は、より複雑な述語と複数のクエリを使った別の例を見てみましょう。

次の例に示すように、4 つの行を持つテーブル items (cost int, available int, demand int) があるとします。

#id	cost	available	demand
1	4	3	3
2	2	23	6
3	5	4	5
4	1	1	2

主なワークロードは、次の 2 つのクエリで構成されています。

70% のクエリパターン:

select * from items where cost > 3 and available < demand

20% のクエリパターン:

select avg(cost) from items where available < demand

従来のソート方法では、cost カラムに対してテーブルを並べ替える方法を選び、cost > 3 の評価式に対してこのソートのメリットが得られるようにすることができます。そのため、単一の cost カラムを使用してソートした後のテーブルのアイテムは次のようになります。

#id	cost	available	demand
領域 #1, with cost <= 3
領域 #2, with cost > 3

#id	cost	available	demand
4	1	1	2
2	2	23	6
1	4	3	3
3	5	4	5

この従来のソートを使用すると、ID が 4 と 2 の上位 2 行 (青色の行) は、cost > 3 を満たさないため、すぐに除外できます。

一方、多次元データレイアウトソートキーでは、ユーザーのワークロードでよく発生する2つの述語（cost > 3、available < demand）の組み合わせに基づいてテーブルがソートされます。その結果、テーブルの行は 4 つの領域へソートされます。

#id	cost	available	demand
領域 #1, with cost <= 3 and available < demand
領域 #2, with cost <= 3 and available >= demand
領域 #3, with cost > 3 and available < demand
領域 #4, with cost > 3 and available >= demand

#id	cost	available	demand
4	1	1	2
2	2	23	6
3	5	4	5
1	4	3	3

この概念は、単一の行ではなくブロック全体に適用したり、従来のソート手法には適さない演算子(like など) を使用する複雑な述語に適用したり、3 つ以上の述語に適用したりすると、さらに強力になります。

システムテーブル

次の Amazon Redshift のシステムテーブルは、テーブルとクエリで多次元データレイアウトが使用されているかどうかをユーザーに示します。

特定のテーブルが多次元データレイアウトソートキーを使用しているかどうかを判断するには、svv_table_info の sortkey1 が AUTO (SORTKEY (padb_internal_mddl_key_col)) と等しいかどうかを確認できます。
特定のクエリが多次元データレイアウトを使用してテーブルスキャンを高速化しているかどうかを判断するには、sys_query_detail ビューの step_attribute をチェックします。スキャン中にテーブルの多次元データレイアウトソートキーが使用された場合、値は multi-dimensional になります。

パフォーマンスベンチマーク

反復スキャンフィルターを使用して複数のワークロードについて内部でベンチマークテストを実施し、多次元データレイアウトソートキーを導入すると次の結果が得られることを確認しました。

ソートキーがない場合と比較して、実行時間が合計で 74% 短縮されました。
各テーブルに最適なシングルカラムのソートキーを使用する場合と比較して、実行時間が合計で 40% 短縮されました。
ソートキーがない場合と比較して、テーブルから読み取られる合計の行数が 80% 減少しました。
各テーブルに最適なシングルカラムのソートキーを使用した場合と比較して、テーブルから読み取られる合計の行数が 47% 減少しました。

機能比較

多次元データレイアウトソートキーが導入されたことで、ワークロードでよく発生するフィルター述語に基づいた式でテーブルをソートできるようになりました。次の表は、Amazon Redshift の機能を 2 つの他社製品と比較したものです。

機能	Amazon Redshift	製品 A	製品 B
カラムに基づくソート	Yes	Yes	Yes
式に基づくソート	Yes	Yes	No
ソート用のカラムの自動選択	Yes	No	Yes
ソート用の式の自動選択	Yes	No	No
カラムに基づくソートか、式に基づくソートかの自動選択	Yes	No	No
スキャン中の式に対するソートプロパティの自動使用	Yes	No	No

考慮事項

多次元データレイアウトを使用するときは、次の点に注意してください。

テーブルを SORTKEY AUTO に設定すると、多次元データレイアウトが有効になります。
Amazon Redshift Advisor は、過去のワークロードを分析することにより、テーブルのシングルカラムのソートキーまたは多次元データレイアウトを自動的に選択します。
Amazon Redshift ATO は、進行中のクエリのワークロードとの相互作用に基づいて、多次元データレイアウトソート結果を調整します。
Amazon Redshift ATO は、既存のソートキーと同じ方法で多次元データレイアウトソートキーを管理します。 ATOの詳細については、自動テーブル最適化の使用を参照してください。
多次元データレイアウトソートキーは、プロビジョニングされたクラスターとサーバーレスワークグループの両方で機能します。
テーブルで AUTO SORTKEY が有効になっていて、スキャンフィルターが繰り返し使用されることが検出されたら、多次元データレイアウトソートキーは既存のデータで使用されます。多次元ソート機能の結果に基づいてテーブルが再構成されます。
テーブルの多次元データレイアウトソートキーを無効にするには、ALTER TABLE table_name ALTER SORTKEY NONE を使用してください。これにより、テーブルの AUTO ソートキー機能が無効になります。
プロビジョニングされたクラスターをサーバーレスクラスターに復元または移行するとき、またはその逆の場合でも、多次元データレイアウトソートキーは保持されます。

まとめ

この投稿では、多次元データレイアウトソートキーを使用すると、主要なクエリに反復スキャンフィルターがあるワークロードのクエリ実行時のパフォーマンスが大幅に向上することを示しました。

Amazon Redshift コンソールからプレビュークラスターを作成するには、クラスター ページに移動し、Create preview cluster を選択します。米国東部 (オハイオ)、米国東部 (バージニア北部)、米国西部 (オレゴン)、アジアパシフィック (東京)、ヨーロッパ (アイルランド)、ヨーロッパ (ストックホルム) の各リージョンにクラスターを作成し、ワークロードをテストできます。

この新機能に関するフィードバックをお待ちしています。

著者について

Yanzhu Ji は Amazon Redshift チームのプロダクトマネージャーです。彼女は、業界をリードするデータ製品およびプラットフォームにおける製品ビジョンと戦略の経験があります。彼女は、ウェブ開発、システム設計、データベース、および分散プログラミング技術を使用して、価値あるソフトウェア製品を構築する優れたスキルを持っています。私生活では、Yanzhu は絵を描いたり、写真を撮ったり、テニスをしたりするのが好きです。

Milind Oke はニューヨークを拠点とするデータウェアハウススペシャリストソリューションアーキテクトです。彼は 15 年以上にわたってデータウェアハウスソリューションを構築しており、Amazon Redshift を専門としています。

Jialin Ding は Learning Systems Group の Applied Scientist で、機械学習と最適化の手法を適用して Amazon Redshift などのデータシステムのパフォーマンスを向上させることを専門としています。

翻訳はソリューションアーキテクトの小役丸が担当しました。原文はこちらです。

Amazon Web Services ブログ