スライディング ウィンドウ マージ結合
直接マージ結合は、1つのテーブルがパーティション化され、もう一方がパーティション化されていない場合、または両方のテーブルがパーティション化されている一方で、そのパーティション化が同一でない場合には使用できません。これは、2つのテーブルの行が同じように順序付けられていないためです。最適化ルーチンでは、PPIを認識するスライディング ウィンドウ マージ結合を適用して、標準の直接マージ結合で対応できない状況に対応することができます。除去されていなく空でない組み合わせパーティションが複数ある場合、スライディング ウィンドウ結合の速度は、マージ結合またはRowkeyベースのマージ結合よりも遅くなる可能性があります。ただし、除去されていなく空でない組み合わせパーティション数が少ない場合、パフォーマンスはこれらとほぼ同じ速度で提供されます(このとき、CPUの使用率とメモリの消費量は大きくなります)。
スライディング ウィンドウ マージ結合は、左リレーションと右リレーションのそれぞれを適切なサイズのウィンドウに構造化するという全般的な原則に従います。必要なパーティション数についての適切な数は、結合を行なうために使用可能なメモリに基づいて最適化ルーチンよって決定されます。この結合は、これら左ウィンドウと右ウィンドウの各ペア間の積結合として実行されます。この操作では各ウィンドウのペア内で通常のマージ結合に対して使用されるのと同じアルゴリズムを使用します。ただし、ウィンドウ内での行の順序は、複数のパーティションにわたる行ハッシュ順とは限りません。
非パーティション テーブルを行パーティションPIテーブルに結合するのに誰もが考える方法は、行パーティションPIテーブルの排除されておらず空でない各パーティションに非パーティション テーブル全体にわたる1つのパスを作成し、一連の副結合として結合を実行することでしょう。これは、特に大きな非パーティション テーブルでは、非効率的な結合方法であることがわかります。この方法の非効率性を回避するため、スライディング ウィンドウ マージ結合では同様の概念を使用しますが、ディスクの読み込み数は最小化されます。
- システムはパーティション化されていないテーブルの最初のデータ ブロックを読み込み、次に、行パーティション化されたPIテーブルの排除されていない空でない各組み合わせパーティションの最初のデータ ブロックをメモリに読み込みます。
- パーティション化されていないデータ ブロックの行が、各行パーティション化されたPIデータ ブロックの行と比較されます。
結合ルーチンは行ハッシュ順に行を提示しますが、それは、各組み合わせパーティションのデータ ブロックに順番にアクセスするプロセスであると考えることができます。
- データ ブロックの行がなくなると、システムはその組み合わせパーティションの次のデータ ブロックを読み込みます。
この結果、各テーブルの各データ ブロックは1度だけ読み込まれることになります。これはパーティション化によります。マージ結合では、通常、ディスクまたはキャッシュから、テーブルの1つに含まれるいくつかの行を複数回読み込む必要があります。データ ブロックのプールを管理するのに追加のオーバーヘッドが発生しますが、除去されていなく空でない組み合わせパーティションすべてをウィンドウがカバーする場合は、結合のパフォーマンスはそれほど低下しません。
問合わせ条件によって、またはそれらが空であるため、組み合わせパーティションのかなりの部分が排除できる場合、その排除できるか空である組み合わせパーティションの比率によっては、全体のパフォーマンスが従来のマージ結合に比べて劇的に向上することがあります。
スライディング ウィンドウ マージ結合アルゴリズムでの制限の要因となるのは、メモリに同時に含めることができるデータ ブロックの数です。ファイル システム キャッシュ メモリは、データ ブロックに対してメモリを提供します。
この目的のためのメモリ利用状況は、DBS制御パフォーマンス フィールドのPPICacheThrPで制御します。その値は、スライディング ウィンドウを必要とする各クエリー ステップに利用できるファイル システム キャッシュの10分の1%単位で表わされます。
PPICacheThrPのデフォルト値は10です。この値は、1%をテーブルわします。
データ ブロック バッファよりも排除されていない空でない組み合わせパーティションが多い場合、結合のパフォーマンスが大幅に低下する可能性があります。十分なメモリが20のデータ ブロック、および100のパーティションがある1つのテーブルに割り当てられているとします。この場合、スライディング ウィンドウ方式が適しています。最初の20の組み合わせパーティションが処理された後、結合ウィンドウが組み合わせパーティションの21～40を処理する際に、システムはパーティション化されていないテーブルを再び読み込みます。パーティション化されていないテーブルに対して合計5つのパスが必要な場合、パーティション化されていないテーブルと行パーティション化されたPIテーブルがほぼ同じサイズであると仮定すると、理論上、ウィンドウがテーブル全体をカバーする結合に比べて、結合に約5倍の時間がかかることになります。実際には、パフォーマンスの低下は5倍まで大きくなりません。これは、いずれの場合も、出力スプール ファイルの行数が全く同じであり、非パーティション テーブルについて言えば、小さい各ウィンドウは大きいウィンドウよりもまばら(スパース)になるためです。ウィンドウがかなり小さい場合は、非パーティション テーブルによるキャッシュ利用との相殺により、パフォーマンスが向上する可能性があります。
- 両方のテーブルがパーティション化されているが、異なるパーティション式が含まれている。
- パーティション列で指定されている結合条件がない。
どちらの場合も、スライディング ウィンドウが両方のテーブルに適用される可能性があります。このような問合わせのEXPLAINテキストは、スライディング ウィンドウ マージ結合が使用されていることも、各テーブルに使用されているコンテキストの数も示しません。
| 等式要素 | 指定される数 |
|---|---|
| LDR ntp | どのテーブルもパーティション化されていない場合の論理データの読み込み数 |
| LDR t2p | 2番目のテーブルがパーティション化されている場合の論理データの読み込み数 |
| LDR btp | 両方のテーブルがパーティション化されている場合の論理データの読み込み数 |
| d 1 | 最初のテーブルのデータ ブロック数 |
| d2 | 2番目のテーブルのデータ ブロック数 |
| p 1 | 最初のテーブルの排除されていない組み合わせパーティションの数 |
| p2 | 2番目のテーブルの排除されていない組み合わせパーティションの数 |
| k 1 | 最初のテーブルでメモリに含めることができるデータ ブロック数 |
| k2 | 2番目のテーブルでメモリに含めることができるデータ ブロック数 |
| データ ブロック単位の割り当て | 値 |
|---|---|
| 最小 | 8以下。PPICacheThrPが0に設定されていても、除去されていない組み合わせパーティションの数に一致する。 |
| 最大 | 次のうち一番小さい数。
最大割り当てが最小割り当てよりも小さくなることはありません。 |
必要に応じて、PPICacheThrPの値を大きくすると、パーティション ウィンドウ化ステップに相対的に多くのメモリが割り当てられ、その他の目的にキャッシュを使用する他のステップへの割り当てが少なくなります。
デフォルトのPPICacheThrP設定値は、パーティション ウィンドウ化に関連しないステップがキャッシュ不足になることがないように低くなっています。例えば、所定のAMPに最大50を超える同時スライディング ウィンドウ結合はないとします。それぞれの結合が多くの組み合わせパーティションを含むテーブルで動作し、最大でウィンドウ化に割り当てられているキャッシュ メモリの約50%を消費する可能性があります。この最悪の場合のシナリオでも、AMPには他のデータ ブロック用にキャッシュの残り半分があります。
スライディング ウィンドウは、組み合わせパーティション式によって定義される行パーティションに基づいています。スライディング ウィンドウ マージ結合のコスト効率を良くするため、限られた数の配置済み組み合わせパーティションのみを結合に含めることができます。ただし、通常は、複数レベルの行パーティション化を実行する場合は、組み合わせパーティション式に多くの組み合わせパーティションを定義します。そのため、複数レベルの行パーティション化でスライディング ウィンドウ マージ結合を使用すると、コストがかかりすぎる場合があります。
スライディング ウィンドウ マージ結合の最終的なコストは、ウィンドウ ペア1個のマージ結合コストに、結合に関係するウィンドウ ペアの数を乗算した値です。関係するウィンドウ ペアの数は、PPIリレーション セットの組み合わせパーティション数とウィンドウ サイズの関数になります。
最適化ルーチンは、常に、問合わせを処理するために評価対象となる結合計画のコストを見積もります。ただし、見積もりがAMP上の実際のデータと異なることがシングル ウィンドウ結合の処理中に明らかになった場合、システムはスライディング ウィンドウ マージ結合を代用することを選択する場合があります。また、最適化ルーチンによって開発されたクエリー計画が、スライディング ウィンドウ マージ結合を指定することがあります。ただし、配置済み行パーティションがほとんどない場合、最終的にはシステムがリクエストを動的に再最適化して、シングル ウィンドウ マージ結合を使用することがあります(動的行パーティション排除による積結合を参照)。
パーティション列に行パーティション排除を許可する条件がある場合、最適化ルーチンは行パーティションの総数ではなくアクティブな行パーティション数を使用します。
PIリレーションのパーティション列と、パーティション レベルの制約の生成に使用できるその他のテーブルとの間に範囲制約がある場合、AMPソフトウェアによって動的行パーティション排除が操作に適用されます。
スライディング ウィンドウ マージ結合は、一般的に、ウィンドウ内の組み合わせパーティションの数が、結合する必要がある配置済みの排除されていない組み合わせパーティションの数より大幅に少ない場合は、PIテーブルの結合操作には使用できません。
- 文字パーティション化されたテーブルのプライマリ インデックス列に対する等式結合条件の動的行パーティション排除
文字パーティション化された結合については、動的行パーティション排除を使用したマージ結合はサポートされません。最適化ルーチンは、文字パーティションPIテーブルへの直接結合としてこの結合方法を選択することはありません。
- プライマリ インデックス付きのテーブルとNoPIテーブルとの間のスライディング ウィンドウ マージ結合に対する動的行パーティション排除
最適化ルーチンは、NoPIテーブルの最初のスプールなしで、プライマリ インデックス テーブルとNoPIテーブル間のスライディング ウィンドウ マージ結合に、動的行パーティション排除を使用することはできません。
- リレーションの任意のが列パーティション化されている場合のスライディング ウィンドウ マージ結合に対する動的行パーティション排除
動的パーティション排除を使用するスライディング ウィンドウ マージ結合では、一方のリレーションが列パーティション化されている場合、最初に列パーティション化されたリレーションをスプールしてから、それをソートする必要があります。
スライディング ウィンドウ マージ結合の例
次の例では、2つのテーブルがプライマリ インデックスで結合されます。WHERE句条件は、ordersのパーティション化レベル1の2つの行パーティションと、パーティション化レベル2の15の行パーティションを除くすべてのパーティションを排除します。WHERE句条件は、lineitemのパーティション化レベル1の1つの行パーティションと、パーティション化レベル2の19の行パーティションを除くすべてのパーティションを排除します。
これらの条件を適用した後、データベースはordersの組み合わせパーティション式の30の組み合わせパーティションを、lineitemの組み合わせパーティション式の19の組み合わせパーティションに結合して、合計で49の組み合わせパーティションを作成します。
- 残りの組み合わせパーティションがすべて配置されている。
- システムのPPICacheThrPの設定に基づいて、18の組み合わせパーティションだけを一度に結合できる。
このとき、最適化ルーチンがスライディング ウィンドウ マージ結合を最もコスト効率のよい方法であると見積もる場合、データベースはその結合を使用して2つのテーブルを結合することができます。
最適化ルーチンが、ordersの8つの組み合わせパーティションをlineitemの10の組み合わせパーティションに一度に結合することを決定するとします。
- 最適化ルーチンはordersの組み合わせパーティションを8、8、8、6の4つの組み合わせパーティションのセットに分割します。
- 最適化ルーチンは、lineitemの組み合わせパーティションを10および9の2つの組み合わせパーティションのセットに分割します。
データベースは、ordersの組み合わせパーティションの各セットを、lineitemの組み合わせパーティションの各セットに直接マージ結合して、合計で8つのシングル ウィンドウ マージ結合を行ないます。
このクエリー例で結合される2つのテーブル、ordersとlineitemの定義DDLテキストは、次のようになります。
CREATE TABLE orders ( o_orderkey INTEGER NOT NULL, o_custkey INTEGER, o_orderstatus CHARACTER(1) CASESPECIFIC, o_totalprice DECIMAL(13,2) NOT NULL, o_orderdate DATE FORMAT 'yyyy-mm-dd' NOT NULL, o_orderpriority CHARACTER(21), o_clerk CHARACTER(16), o_shippriority INTEGER, o_comment VARCHAR(79)) PRIMARY INDEX (o_orderkey) PARTITION BY ( RANGE_N(o_custkey BETWEEN 0 AND 49999 EACH 100), RANGE_N(o_orderdate BETWEEN DATE '2000-01-01' AND DATE '2006-12-31' EACH INTERVAL '1' MONTH)) UNIQUE INDEX (o_orderkey); CREATE TABLE lineitem ( l_orderkey INTEGER NOT NULL, l_partkey INTEGER NOT NULL, l_suppkey INTEGER, l_linenumber INTEGER, l_quantity INTEGER NOT NULL, l_extendedprice DECIMAL(13,2) NOT NULL, l_discount DECIMAL(13,2), l_tax DECIMAL(13,2), l_returnflag CHARACTER(1), l_linestatus CHARACTER(1), l_shipdate DATE FORMAT 'yyyy-mm-dd', l_commitdate DATE FORMAT 'yyyy-mm-dd', l_receiptdate DATE FORMAT 'yyyy-mm-dd', l_shipinstruct VARCHAR(25), l_shipmode VARCHAR(10), l_comment VARCHAR(44)) PRIMARY INDEX (l_orderkey) PARTITION BY ( RANGE_N(l_suppkey BETWEEN 0 AND 4999 EACH 10), RANGE_N(l_shipdate BETWEEN DATE '2000-01-01' AND DATE '2006-12-31' EACH INTERVAL '1' MONTH));
これらのテーブルの定義に基づき、最適化ルーチンは結合計画に直接スライディング ウィンドウ マージ結合方式を選択して、次の問合わせを処理するときに、条件を満たす49の組み合わせパーティションを結合します。
SELECT * FROM orders INNER JOIN lineitem WHERE o_orderkey = l_orderkey AND o_orderdate BETWEEN DATE '2005-04-01' AND DATE '2006-06-30' AND o_custkey IN (618, 973) AND l_shipdate BETWEEN DATE '2005-04-01' AND DATE '2006-10-31' AND l_suppkey = 4131;