Beamテーブルの1つ以上の列に対して範囲クエリまたは等価フィルタリングを頻繁に実行する場合は、複合ソートキーまたはインターリーブされたソートキーを指定して、クエリのパフォーマンスを向上させることができます。
テーブルを作成するとき、Beamでは1つ以上の列をソートキーとして指定できます。 データがテーブルに書き込まれた後、システムはソートキーによってデータをソートします。 Beamがテーブル内のソートされたデータをスキャンするとき、Beamは列の最大値と最小値を使用して、フィルタ条件を満たさないデータブロックをスキップできます。 これにより、I/Oオーバーヘッドが大幅に削減されます。 ほとんどの場合、ソートキーはデータ圧縮率の向上に役立ちます。 Beamは、複合ソートキーとインターリーブソートキーをサポートします。
使用上の注意
V7.0.1.x以降のAnalyticDB for PostgreSQL V7.0インスタンスのみがビームソート最適化機能をサポートしています。 インスタンスのマイナーバージョンを表示する方法については、「マイナーエンジンバージョンの表示」をご参照ください。
化合物ソート
複合ソートキーの定義
複合ソートキーは、ソートキー定義にリストされているすべての列で構成されます。 データは、列がリストされている順序に基づいてソートされます。 複合ソートキーは、クエリのフィルタ条件にソートキー列のプレフィックスが含まれている場合に効率的です。
次のステートメントを実行して、複合ソートキーを含むBeamテーブルを作成します。
CREATE TABLE beam_example (
id integer,
name text,
ftime timestamp
)
USING beam
DISTRIBUTED BY (id)
ORDER BY(id);複合ソートキーの維持
複合ソートキーを含むテーブルを作成した後、書き込まれたデータはソートキー列に基づいてすぐにソートされません。 バックグラウンドプロセスは、データ量とファイル数に基づいて最適なソート順序を自動的に生成します。 書き込まれたデータをすぐにソートする場合は、OPTIMIZEステートメントを実行できます。
次のステートメントを実行して、beam_exampleテーブルのデータを即座にソートします。
OPTIMIZE beam_example;OPTIMIZEステートメントは、DDLの変更をブロックします。 ステートメントを実行すると、DDLステートメントは自動的に続行されます。
インターリーブソート
使用上の注意
V7.0.4.0以降のAnalyticDB for PostgreSQL V7.0インスタンスのみがビームインターリーブソートをサポートしています。インスタンスのマイナーバージョンを表示する方法については、「マイナーエンジンバージョンの表示」をごください。
インターリーブされたソートキー列が2〜8つだけ含まれるビームテーブルを作成できます。
date列やtimestamp列など、増分された列は、インターリーブされたソートキーとして指定しないことをお勧めします。
インターリーブされたソートキーの定義
インターリーブされたソートキーは、ソートキーの各列に等しい重みを割り当てます。 このようにして、すべてのソートキー列が等しく使用されます。 インターリーブされたソートキーは、フィルタ条件がソートキー列を含むクエリに効率的です。
次のステートメントを実行して、インターリーブされたソートキーを含むビームテーブルを作成します。
CREATE TABLE beam_example_interleaved (
id integer,
name text,
ftime timestamp,
region varchar,
age integer
)
USING beam
DISTRIBUTED BY (id)
ZORDER BY(name, region, age);インターリーブされたソートキーの維持
インターリーブされたソートキーを含むテーブルを作成した後、書き込まれたデータはすぐにはインターリーブされません。 バックグラウンドプロセスは、データ量とファイル数に基づいて最適なソート順序を自動的に生成します。 書き込まれるデータの量が増加するにつれて、インターリーブされたソーティングは、データ範囲の変化に起因してデータスキューを生じさせ得る。 この場合、テーブルデータを手動で再ソートする必要があります。
たとえば、beam_example_interleavedテーブルは、name列とregion列に基づいてインターリーブ方式でソートされます。 次のステートメントを実行して、テーブルのインターリーブされたソートキー列のデータスキューを照会します。
SELECT * FROM adbpg_toolkit.pg_get_interleaved_skew('beam_example_interleaved'::regclass)
relid | colname | skew | suggestion
-------+----------+------+---------------
17139 | name | 0.46 |
17139 | region | 0.54 | NEED OPTIMIZE
17139 | OVER ALL | 0.54 | NEED OPTIMIZE
(3 rows)次のステートメントを実行して、現在のデータベースのすべてのインターリーブされた並べ替えテーブルの各列のデータスキューを照会します。
SELECT * FROM adbpg_toolkit.pg_stat_interleaved_skew;
relid | relname | colname | skew | suggestion
-------+--------------------------+----------+------+---------------
17139 | beam_example_interleaved | name | 0.46 |
17139 | beam_example_interleaved | region | 0.54 | NEED OPTIMIZE
17139 | beam_example_interleaved | OVER ALL | 0.54 | NEED OPTIMIZE
(3 rows)サンプル結果の列:
skew: インターリーブされたソートキー列のスキュー率。suggestion: インターリーブされたソートキー列の提案。NEED OPTIMIZEは、列を再ソートする必要があることを示します。colname列のOVER ALLは、インターリーブされたすべてのソートキー列の全体的なデータスキューを示します。 特定のインターリーブされたソートキー列のみのデータスキューについて学習した場合は、列のデータスキューに基づいてテーブル全体をソートできます。
テーブルデータをすぐに並べ替える場合は、OPTIMIZEステートメントを実行できます。
次のステートメントを実行して、beam_example_interleavedテーブルのデータを直ちにソートします。
OPTIMIZE beam_example_interleaved;OPTIMIZEステートメントは、DDLの変更をブロックします。 ステートメントを実行すると、DDLステートメントは自動的に続行されます。
ソートキーの追加または変更
テーブルを作成した後、ソートキーを追加、変更、または削除できます。
使用上の注意
テーブルにソートキーを追加したり、テーブル内のソートキーを変更したりすると、テーブルがロックされ、テーブル内のデータの読み書きができなくなります。
テーブルのソートキーを変更すると、テーブルのすべてのデータが書き換えられます。 テーブルに大量のデータが含まれている場合、データの書き換えに時間がかかります。 作業は慎重に行ってください。
テーブル内の複合ソートキーを変更すると、テーブルデータはすぐに再ソートされます。 テーブル内のインターリーブされたソートキーを変更しても、テーブルデータはすぐには再ソートされません。 テーブル内のインターリーブされたソートキーを変更した後、OPTIMIZEステートメントを実行することを推奨します。
例
複合ソートキーを追加または変更します。
ALTER TABLE beam_example SET ORDER BY(id, name);インターリーブされたソートキーを追加または変更します。
ALTER TABLE beam_example_interleaved SET ZORDER BY(name, region);ソートキーを削除します。
ALTER TABLE beam_example SET ORDER NONE;
ソートキーの選択
ビームテーブルのソートキーを選択する際の提案:
Beamテーブルの1つ以上の列に対して範囲クエリまたは等価フィルタリングを頻繁に実行する場合は、列をソートキーとして指定できます。
ビームテーブルの複数の列に対して範囲クエリまたは等価フィルタリングを頻繁に実行し、列のクエリ頻度とフィルタリング率がほぼ同じで、列に自動インクリメントが含まれていない場合は、インターリーブされたソートキーを選択することをお勧めします。 列のクエリ頻度とフィルタリング率が高い場合は、複合ソートキーを選択することを推奨します。
すべての列が同じ頻度で使用される複合ソートキーを指定する場合は、複合ソートキーの前に低濃度列を配置することをお勧めします。
インターリーブされたソートキーを指定する場合は、クエリのパフォーマンスを向上させるために、大量のデータを含む低濃度の列を選択することをお勧めします。
複合ソートキーとインターリーブソートキーのクエリパフォーマンスの違い
次の表に、異なるフィルタリング条件での複合ソートキーとインターリーブソートキーのクエリパフォーマンスの違いを示します。 この例では、ソートキーは、1テラバイトのデータを含むlineorder_flat Beamテーブルに指定され、Star Schema Benchmark (SSB) パフォーマンステストに使用されます。 ソートキーの列はLO_ORDERDATEとP_BRANDです。
フィルター条件 | 複合ソートキーのクエリパフォーマンス | インターリーブソートキーのクエリパフォーマンス |
最初の列に基づくポイントクエリ | 0.297 | 18.329 |
最初の列に基づくフィルタリングレートの1% | 1.268 | 19.224 |
最初の列に基づくフィルタリングレートの10% | 16.83 | 38.30 |
最初の列に基づくフィルタリングレートの50% | 65.62 | 76.99 |
最初の列に基づくポイントクエリ + 2番目の列に基づくポイントクエリ | 0.288 | 5.29 |
最初の列に基づく1% フィルタリングレート + 2番目の列に基づく1% フィルタリングレート | 7.36 | 6.46 |
最初の列に基づく10% フィルタリングレート + 2番目の列に基づく10% フィルタリングレート | 91.73 | 26.70 |
最初の列に基づく50% フィルタリングレート + 2番目の列に基づく50% フィルタリングレート | 376.22 | 87.82 |
最初の列に基づくフィルタリング率 + 2番目の列に基づくポイントクエリの50% | 71.83 | 19.16 |
最初の列に基づく10% フィルタリングレート + 2番目の列に基づく1% フィルタリングレート | 82.50 | 18.95 |
最初の列に基づく1% フィルタリングレート + 2番目の列に基づく10% フィルタリングレート | 7.98 | 6.43 |
最初の列に基づくポイントクエリ + 2番目の列に基づく50% フィルタリング率 | 0.50 | 31.48 |
2番目の列に基づくポイントクエリ | 87.04 | 19.67 |
2番目の列に基づくフィルタリングレートの1% | 515.08 | 78.90 |
2番目の列に基づくフィルタリングレートの10% | 567.85 | 131.39 |
2番目の列に基づくフィルタリングレートの50% | 588.86 | 134.36 |
上記のクエリ結果には、2種類のソートキー間の相対的なパフォーマンスの違いのみが表示されます。 結果は、SSBデータセットのAnalyticDB for PostgreSQLの最適なパフォーマンスを表していません。
テストの結論: 最初のソートキー列または最初のソートキー列のみに基づいて高いフィルタリング率でクエリが実行された場合、複合ソートキーの方が効率的です。 クエリが2番目のソートキー列または複数のソートキー列に基づいて実行される場合、インターリーブされたソートキーの方が効率的です。
関連ドキュメント
ビームソート最適化は、AnalyticDB for PostgreSQL V7.0インスタンスにのみ適しています。 AnalyticDB For PostgreSQL V6.0インスタンスの並べ替え最適化の使用方法については、「並べ替え最適化」をご参照ください。