17.00 - 17.05 - ハッシュ結合 - Advanced SQL Engine - Teradata Database

Teradata Vantage™ - SQLリクエストおよびトランザクション処理

Product
Advanced SQL Engine
Teradata Database
Release Number
17.00
17.05
Published
2020年6月
Content Type
プログラミング リファレンス
ユーザー ガイド
Publication ID
B035-1142-170K-JPN
Language
日本語 (日本)

ハッシュ結合について

ハッシュ結合は、特定の条件の下ではマージ結合(マージ結合を参照)や、等式プロダクト ジョイン(プロダクト ジョインを参照)より優れた方式です。ハッシュ結合は、等結合にのみ適用可能です。ハイブリッド ハッシュ結合で得られる処理能力の強化は主に、実際の結合操作を実行する前に、結合するテーブルを並べ替える必要がなくなることによります。一部の状況では、キャッシュの使用、バルク結合条件評価、およびSIMD命令の使用を改善することにより、メモリ内ハッシュ結合のパフォーマンスの方が向上します。

特に記載がない限り、ハッシュ結合の節にあるハッシュ結合についての一般的な情報は、メモリ内ハッシュ結合にも適用されます。
Vantageでは、次の結合タイプに対処するために、さまざまな形式のハッシュ結合を使用できます。
  • ハッシュ内部結合(従来の動的ハッシュ結合、および動的行パーティション排除を使用する動的ハッシュ結合)
  • ハッシュ包含準結合(動的ハッシュ結合のみ、メモリ内ハッシュ結合には適用されません)
  • ハッシュ排他準結合(動的ハッシュ結合のみ、メモリ内ハッシュ結合には適用されません)
  • 左、右、および完全外部ハッシュ結合(従来型ハッシュ結合および動的ハッシュ結合のみ)
  • 動的行パーティション排除を使用するハッシュ結合(動的ハッシュ結合のみ)

これらのハッシュ結合タイプの詳細は、従来型ハッシュ結合および動的ハッシュ結合を参照してください。

結合内の大さなテーブルのスプールを回避するかどうかに応じて、最適化ルーチンは、標準のハッシュ結合を動的ハッシュ結合(動的ハッシュ結合を参照)またはメモリ内動的ハッシュ結合(動的メモリ内ハッシュ結合を参照)に置き換える場合があります。結合条件がプライマリ インデックスではない列のセットに指定されている場合、行の再配置をソート操作の前に完了する必要があります。

ハッシュ結合は、他の結合方法のように、結合列の統計が最新のものである場合に最適な実行となります。これは特に、データ内のスキューの検出において最適化ルーチンを支援するために、ハッシュ結合コスト計算をする場合に重要です(スキューのあるデータがハッシュ結合の処理能力に及ぼすマイナスの影響の詳細については、データのひずみがハッシュ結合処理に及ぼす影響を参照)。

ハッシュ結合はその他の結合方式と同様にコストが見積もられ、最適化ルーチンはその結合のコストをその他の適格な結合方式および結合計画のコストと比較して、問合わせに対してコストが最小になる計画を判断します。

最適化ルーチンは、メモリ内最適化スプールを作成するかどうかも決定します。

メモリ内最適化スプールは、最大4つの列パーティションと以下を持つ、列パーティション スプールです。
  • ハッシュ値用のパーティション。
  • 固定長の等価結合条件で使用される最高の選択性を持つ結合列のパーティション。
  • 等価結合条件で使用される固定長列すべてのパーティション。
  • すべての可変長列、残余結合条件列、および射影列のパーティション。

ハッシュ結合の用語

ハッシュ結合方式の説明で必要となるいくつかの新しい用語の定義を、以下のテーブルに示します。

用語 定義
ビルド テーブル 2つの結合テーブルのうち小さいほうのテーブル。このテーブルを使用してハッシュ テーブルがビルドされるのでこのように呼ばれます。
ファンアウト 作成されるハッシュ組み合わせパーティションの最大数。

行がファンアウトされると、それらの行はいくつかのハッシュ パーティションにパーティション化されます。

ハッシュ結合または メモリ内ハッシュ結合 結合列セットに基づいて結合される2つのテーブルのうち小さいほうにハッシュ テーブルが作成されるときに使用される結合アルゴリズム。大きいほうのテーブルは、結合を実行するときのハッシュ テーブルの精査に使用されます。
ハッシュ テーブル いくつかのハッシュ バケットから成るメモリ常駐のテーブル。ハッシュ バケットはそれぞれ、特定のハッシュ範囲に属する行の順序付けされたリンク リストを持っています。
メモリ内ハッシュ テーブル 結合比較中のキャッシュ効率を高めるために設計された、残りの入力から作成されるメモリ常駐テーブル。また、これはSIMD命令の実行を有効にするためにも設計されています。
プローブ テーブル ハッシュ結合における2つの結合テーブルのうち大きいほうのテーブル。

結合状態が評価される前のハッシュ照合として、このテーブルの行を使用してハッシュ テーブルの行の精査が行なわれます。

パーティション ハッシュ結合におけるテーブルのセグメント。

テーブルは、いくつかのハッシュ結合パーティションにセグメント化されます。

ハッシュ組み合わせパーティションはメモリに常駐することもあります。その場合のパーティションはハッシュ テーブル、つまりスプールの構成要素にもなります。

ハッシュ結合操作のハッシュ組み合わせパーティション数は、50に制限されています。

ハッシュ結合のパーティションは、行パーティション化または列パーティション化されたテーブルまたは結合インデックスのパーティションとは関係ないことに注意してください(<Teradata Vantage™ - SQLデータ定義言語-構文規則および例、B035-1144>および<Teradata Vantage™ - データベースの設計、B035-1094>を参照)。これらはまったく関係のない別のものです。

作業領域不足 ハッシュ テーブルの作成プロセス中に、Teradata Databaseはハッシュ テーブルの行を格納するために1回で1つのセグメントを割り当てます。

割り当てられたセグメント数が最大数(MaxHTSegs)に達すると、作業領域不足が発生して、ハッシュ結合プロセスが右行ハッシュを使用して開始され、結合する一致行を探すためにハッシュ テーブルが調査されます。

ハッシュ結合と性能

性能向上のために、最適化ルーチンは次の状況でマージ結合の代わりにハッシュ結合を使用することがあります。
  • 1つ以上の結合キーにインデックスが作成されていない場合。
  • 結合段階でパフォーマンスが改善する場合。

ハッシュ テーブルを使用すると、ハッシュ結合によってマージ結合の前に使用されるソートを排除できます。

ハッシュ結合のパフォーマンスを最適化する方法についての詳細は、ハッシュ テーブルおよびメモリ内ハッシュ テーブルのサイズの制御を参照してください。

従来型ハッシュ結合

ビルド テーブル全体が使用可能メモリに収まるときは、従来型ハッシュ結合が適用可能です。システムは、ビルド リレーションの行をメモリ常駐のハッシュ テーブルに直接読み取ります。次にプロセスはプローブ テーブルから行を読み取り、それを使用してハッシュ テーブルの照合を個々に精査します。すべての結合条件を満たすハッシュ照合ごとに結果行が返されます。この場合は、パーティション化は行なわれないため、パーティション化に関連した入出力は発生しません。したがって、この形式のハッシュ結合が最も高速です。

Vantageは、ハイブリッドハッシュ結合と呼ばれる従来のハッシュ結合の変形と、動的ハッシュ結合(動的ハッシュ結合を参照)と呼ばれるハイブリッド ハッシュ結合の変形を使用します。この方式では、大きすぎて使用可能メモリに収まらないビルド テーブルは、メモリに収まるようにハッシュ結合パーティションと呼ばれるチャンクに分割されます(システムがこれを処理する方法についての詳細は、ハッシュ結合のペアの小さいほうのテーブルのパーティション化を参照)。

従来型ハッシュ結合は、左、右および完全外部結合に適用できます。これと同様に内部結合にも適用できます。

ハイブリッド ハッシュ結合アルゴリズムにより適用されるプロセスは次のプロセスで表わされます。
  1. 右のテーブル(行データだけでなく行ごとの行ハッシュ値が含まれているソートされていないスプール)から行を読み取ります。
  2. 右のテーブルの各行を、同じ行ハッシュ値を持つ左のテーブルのすべての行と照合します。
  3. 行を結合します。

次の図は、ハイブリッド ハッシュ結合プロセスを表わしています。


ハイブリッド ハッシュ結合プロセス

ハッシュ バケットのエントリによって、同じ行ハッシュ値を持つエントリが1つにクラスタ化されます。これにより、行ハッシュ値を使用した行の高速な検索が容易になります。これは、各ハッシュ バケットのエントリに1回アクセスするだけで済むためです。

従来型メモリ内ハッシュ結合

従来型ハッシュ結合向けに説明されているすべての考慮事項は、メモリ内ハッシュ結合にも適用されます。異なる点がいくつかあり、その1つとしてメモリ内ハッシュ結合でより多くのメモリの量が使用される可能性があります。

メモリ内ハッシュ結合アルゴリズムは、バルク処理向けに設計されています。つまり、従来型ハッシュ結合で説明されている処理の各ステップは、複数の行を操作するために機能強化されています。このアルゴリズムは、メモリ アクセス パターン、ひいてはキャッシュ効率の改善に役立ちます。

別の相違点は、ハッシュ テーブル データ構造にあります。メモリ内ハッシュ結合のハッシュ テーブル構造は、メモリ内スプール パーティション形式に従い、各パーティションの値をまとめて格納します。

ハッシュ結合のペアの小さいほうのテーブルのパーティション化

ハッシュ テーブルは、ハッシュ結合のペアの小さいほうのテーブルから派生します。これは単一パーティションのメモリ常駐データ構造であり、これにはハッシュ アレイと、ハッシュ アレイが指す大きいほうのテーブル内の行が含まれます。システムはハッシュ結合操作で小さいほうのテーブルを、特定のハッシュ値の範囲に属する行の順序付けされたリンク リストとして構成します。そのサイズに応じて、このテーブルは複数のさらに小さなパーティションに分解できます。

小さい方のテーブルが大きすぎてハッシュ結合処理に使用可能なメモリに収まらないときは、システムで小さなパーティションに分割します。これにより、各パーティションが使用可能なスペースに収まる大きさになります。パーティションのサイズは、DBS制御レコードの複数のパラメータの設定により制御されます(ハッシュ結合の制御変数を参照)。

テーブルは最大で50のパーティションに分割できます。パーティション化することにより、パーティション化を行なわない場合にハッシュ バケットがオーバーフロー状態になったときに仮想メモリ管理に必要となる保守オーバーヘッドを回避することができます。

システムが小さい方のテーブルをセグメント化するときに使用するアルゴリズムでは、結合列を使用して、結合を行なうのに必要な数のハッシュ結合パーティションに行をハッシュします。

例えば、結合を行なうにはハッシュ組み合わせパーティションが6つ必要であるとします。この場合は、小さいほうのテーブルの条件を満たす行の数が、使用可能メモリに収まる最大単一ハッシュ組み合わせパーティションの6倍の大きさになります。そこで、システムは各行を6つのハッシュ組み合わせパーティションの1つにハッシュします。

システムは大きいほうのテーブルについても同様にスプーリングとパーティション化を行ないます。大きいほうのテーブルはパーティションも大きくなりますが、これらはメモリに収まる必要はありません。システムは結合を行なうときに、スプールにコピーされている小さいほうのテーブルのハッシュ組み合わせパーティションをメモリに取り込みます。次に、もう一方のテーブル(これもスプールにコピーされている)の一致するハッシュ組み合わせパーティションの行がメモリ内の行と照合されます。

あるハッシュ組み合わせパーティションの行が、もう一方のテーブルの異なるハッシュ組み合わせパーティションに含まれる行と一致することはありません。これは、それぞれのハッシュ値が異なるからです。

左側のテーブルの各ハッシュ組み合わせパーティションは、対応する右側のテーブルのパーティションと順々にハッシュ結合されます。従来型ハッシュ結合のセクションの図では、左側の3つにパーティション化されたテーブルのパーティション2が、右側の3つにパーティション化されたテーブルのハッシュ結合パーティション2とハッシュ結合されています。

EXPLAINレポートでは、ハッシュ結合パーティションを作成するプロセスが、ファンアウトと呼ばれています(ハッシュ結合の例を参照)。ここでは、ハッシュ結合とハッシュ結合テーブルのパーティション化を表わす部分が太字で強調されています。

データのひずみがハッシュ結合処理に及ぼす影響

ビルド テーブルでのデータのひずみは、ハッシュ結合のパフォーマンスを著しく低下させることがあります。ハッシュ結合は、ハッシュ アルゴリズムによりビルド リレーションを相対的に同等サイズのパーティションに小さくできることを前提の1つにしています。ビルド テーブルに大量の重複行値があると、ハッシュ パーティション化アルゴリズムはそれを最適にパーティション化できない可能性があります。プローブ テーブルでのひずみ(スキュー)も、そのために結果的にプローブ テーブルがビルド テーブルより小さくなる場合は、パフォーマンスを低下させることがあります。

ハッシュ結合操作でどちらのテーブルでもスキューがある可能性があることを見込んで対応する場合は、DBS制御ユーティリティを使用して、ビルド テーブルの各パーティションのサイズをその親であるハッシュ テーブルに比例させることができます(ハッシュ結合の制御変数を参照)。

指定したひずみの許容度が不十分だったためにデータのひずみを補正することができなかった場合、ハッシュ テーブルバケットのオーバーフローが発生すると、システムは対応するプローブ テーブルの行と、メモリ常駐ハッシュ テーブルにすでにロードされているビルド テーブルの行を照合します。プローブ パーティションのすべての行が処理されると、システムはハッシュ テーブルをクリアし、ビルド テーブルの大きすぎるパーティションから追加の行をメモリに移します。そこでシステムはプローブ パーティションの行を再び読み取り、新しくロードされたビルド テーブルの行と照合します。ビルド パーティション全体が処理されるまでこの処置が繰り返されます。

メモリ内ハッシュ結合の場合、ビルド テーブルのデータ スキューにより、結合パフォーマンスが低下する可能性もあります。メモリ内ハッシュ テーブルのデフォルト サイズはさらに大きいため、メモリ内ハッシュ結合のスキューはさらに問題です。ハッシュ テーブル サイズが大きいと、最適化ルーチンは適切なテーブルに直接アクセスすることを選択する場合があります。ハッシュ テーブル オーバーフローがあると、大きくて適切なテーブルは複数回スキャンする必要があります。小さいハッシュ テーブル サイズを使用する場合、利用できるメモリが残りの入力全体を保持するには不十分だと見なされると、プランナーは2つの入力のパーティション化を選択する場合があります。メモリ内ハッシュ結合のプランニング中、最適化ルーチンは、行数の見積もりを増やすことによりスキューのコストをより控えめに調整します。

ハッシュ テーブルおよびメモリ内ハッシュ テーブルのサイズの制御

ハッシュ テーブルのサイズは、DBS制御フィールドのHTMemAllocとHTMemAllocBaseを使用して制御できます(ハッシュ結合の制御変数を参照)。値として0を指定すると、システムはハッシュ テーブルを作成できません。これによりハッシュ結合が実質的にオフになり、最適化ルーチンは結合計画を評価するときにこの方式を検討しません。

メモリ内ハッシュ テーブルのサイズを増やす必要がある場合は、Teradataグローバル サポート センターの担当者に連絡してください。

ハッシュ結合の制御変数

ハッシュ結合に関連したパラメータのHTMemAllocとSkewAllowanceにアクセスするには、DBS制御ユーティリティを使用します(<Teradata Vantage™ - データベース ユーティリティ、B035-1102>を参照)。これらを使用して、ハッシュ結合の性能を最適化します。HTMemAllocBaseは、Teradataサポート担当者だけがアクセスできる内部DBS制御フィールドです。このフィールドの値を変更する必要があるとお考えの場合は、テクニカル サポート チームにお問合わせください。

HTMemAllocは、メモリ内ハッシュ結合に適用されません。メモリ内ハッシュ結合にはSkewAllowanceが使用されます。
DBS制御フィールド 機能
HTMemAlloc HTMemAllocBase値のパーセンテージを計算してハッシュ テーブルのサイズを変えます。指定されたパーセントが大きいほど、ハッシュ テーブルも大きくなります。デフォルト値は10です。ゼロに設定すると、ハッシュ結合は最適化で使用されなくなります。

この設定は、Teradataグローバル サポート センターの指示によってのみ変更するようにしてください。

HJ2IMHJ 最適化ルーチンがハッシュ結合および動的ハッシュ結合を実行するためにメモリ内ハッシュ結合メソッドを優先して選択するかどうかを決定します。デフォルト値はFALSE (非有効)です。

FALSEに設定すると、最適化ルーチンは、新しい結合メソッドとしてメモリ内ハッシュ結合のコストを計算し、それをコストに基づいて選択します。TRUEに設定すると、最適化ルーチンは、コストにかかわらず、その他のハッシュ結合メソッドよりも優先して、可能な限りメモリ内ハッシュ結合メソッドを使用します。

SkewAllowance 各パーティションのサイズをハッシュ テーブルよりも小さくすることによりデータの偏りに対処します。

有効な入力値の範囲は20から80(%)です。

デフォルトは75(%)です。これはパーティションのサイズがハッシュ テーブルの25%に設定され、ハッシュ テーブルに収まらなくならないように、実際のパーティションが最適化ルーチンが見積もったサイズの4倍のサイズになることを示します。

DBS制御フィールドの情報については、<Teradata Vantage™ - データベース ユーティリティ、B035-1102>は参照できます

ハッシュ結合の例

最適化ルーチンは、この問合わせで、EmployeeテーブルとDepartmentテーブルを、等式条件Employee.Location = Department.Locationでハッシュ結合することにしています。Spool 2(ステップ4)とSpool 3(ステップ5)でハッシュ テーブルが22のハッシュ結合パーティションにセグメント化(ファンアウト)されることがEXPLAINテキストに示されています(ハッシュ結合のペアの小さいほうのテーブルのパーティション化を参照)。

ハッシュ テーブルのメモリ割り当ては5%、スキューの許容度は部分的EXPLAINの75%(データのひずみがハッシュ結合処理に及ぼす影響を参照)に設定されています。

EXPLAIN
SELECT employee.empnum, department.deptname, employee.salary
FROM employee, department
WHERE employee.location = department.location;

EXPLAIN出力の一部を次に示します。

 ...
3) We lock PERSONNEL.Department for read, and we lock PERSONNEL.Employee for read.
4) We do an all-AMPs RETRIEVE step from PERSONNEL.Employee by way of an all-rows scan with no residual conditions into  Spool 2 fanned out into 22 hash join partitions, which is redistributed by hash code to all AMPs. The size of Spool 2 is estimated to be 3,995,664 rows. The estimated time for this step is 3 minutes and 54 seconds.
5) We do an all-AMPs RETRIEVE step from PERSONNEL.Department by way of an all-rows scan with no residual conditions into  Spool 3 fanned out into 22 hash join partitions, which is redistributed by hash code to all AMPs. The size of Spool 3 is estimated to be 4,000,256 rows. The estimated time for this step is 3 minutes and 54 seconds.
6) We do an all-AMPs JOIN step from Spool 2 (Last Use) by way of an all-rows scan, which is joined to Spool 3 (Last Use).  Spool 2 and Spool 3 are joined using a hash join of 22 partitions, with a join condition of (“Spool_2.Location = Spool_3.Location”). The result goes into Spool 1, which is built locally on the AMPs. The result spool field will not be cached in memory. The size of Spool 1 is estimated to be 1,997,895,930 rows. The estimated time for this step is 4 hours and 42 minutes.
7) Finally, we send out an END TRANSACTION step to all AMPs involved in processing the request.
-> The contents of Spool 1 are sent back to the user as the result of statement 1. The total estimated time is 4 hours and 49 minutes.
DBS Control Record - Performance Fields:
HTMemAlloc       =  5%
SkewAllowance    = 75%

次の例で、部分的EXPLAINは、最適化ルーチンがメモリ内ハッシュ結合を処理する方法を示しています。

EXPLAIN
SELECT pit103.c2,pit104.c3,cpt1.c2
FROM pit104,pit103,cpt1
WHERE cpt1.c4 = pit103.c4 AND pit103.c3 = pit104.c4 AND cpt1.c2 > 100;
...
  5) We execute the following steps in parallel.
       1) We do an all-AMPs RETRIEVE step from TEST.pit104 by way of an
          all-rows scan with a condition of ("NOT (TEST.pit104.c4 IS
          NULL)") into Spool 2 (all_amps), which is built locally on
          the AMPs. Spool 2 is built as in-memory optimized spool with 
 3 column partitions. The size of Spool 2 is estimated with
          low confidence to be 20 rows (500 bytes). The estimated time
          for this step is 0.37 seconds.
       2) We do an all-AMPs RETRIEVE step from TEST.pit103 by way of an
          all-rows scan with a condition of ("(NOT (TEST.pit103.c4 IS
          NULL )) AND (NOT (TEST.pit103.c3 IS NULL ))") into Spool 3
          (all_amps), which is duplicated on all AMPs. Spool 3 is
          built as  in-memory optimized spool with 3 column partitions.
          The size of Spool 3 is estimated with low confidence to be
          400 rows (11,600 bytes). The estimated time for this step is
          0.37 seconds.
  6) We do an all-AMPs JOIN step from Spool 2 (Last Use), which is
     joined to Spool 3 (Last Use). Spool 2 and Spool 3 are joined
     using a  single partition in-memory hash join, with a join
     condition of ("c3 = c4"). The result goes into Spool 4 (all_amps),
     which is built locally on the AMPs. Then we do a SORT to order
     Spool 4 by the hash code of (TEST.pit103.c4). The size of Spool 4
     is estimated with no confidence to be 90 rows (2,250 bytes). The
     estimated time for this step is 0.33 seconds.
  7) We do an all-AMPs BULK RETRIEVE step from 3 column partitions of
     TEST.cpt1 with a condition of ("(TEST.cpt1.c2 >= 101) AND (NOT
     (TEST.cpt1.c4 IS NULL ))") into Spool 5 (all_amps), which is
     duplicated on all AMPs. Then we do a SORT to order Spool 5 by the
     hash code of (TEST.cpt1.c4). The size of Spool 5 is estimated
     with no confidence to be 140 rows (2,940 bytes). The estimated
     time for this step is 0.11 seconds.
  8) We do an all-AMPs JOIN step from Spool 4 (Last Use) by way of a
     RowHash match scan, which is joined to Spool 5 (Last Use) by way
     of a RowHash match scan. Spool 4 and Spool 5 are joined using a
     merge join, with a join condition of ("c4 = c4"). The result goes
     into Spool 1 (group_amps), which is built locally on the AMPs.
     The size of Spool 1 is estimated with no confidence to be 67 rows
     (3,618 bytes). The estimated time for this step is 0.56 seconds.
...

動的ハッシュ結合

動的ハッシュ結合により、大さなテーブルをスプールに入れることなく、非プライマリ インデックス列上で1つ以上の小さいテーブル(またはリレーション)と大さなテーブルとの間のバイナリまたはn方向の直接の等式結合を実行することができます。動的ハッシュ結合を使用する場合、小さいテーブルはそれぞれ単一のハッシュ組み合わせパーティションに収まる大きさでなければなりません。

動的ハッシュ結合は、非プライマリ インデックス列に基づいて2つのテーブルが結合され、小さいテーブル(左テーブル)が大きいテーブル(右テーブル)と比べて非常に小さい場合にのみ使用できます。

プロセスは以下の通りです。
  1. 小さい方のテーブルを複製する。
  2. 小さい方のテーブルをそれぞれハッシュ アレイに入れる。
  3. 右のテーブルから1行読み取る。
  4. 行ハッシュ コードを計算する。
  5. 右の各行を、同じ行ハッシュ値を持つ各ハッシュ アレイ内のすべての行と照合する。
  6. 一致する行を結合する。

動的ハッシュ結合は、左、右および完全外部結合、ならびに内部結合に適用できます。また、動的パーティション排除を行なうための等式条件を利用することもできます。

包含ハッシュ結合と排他ハッシュ結合でも、等式条件を指定したときには、動的パーティション排除が使用できます。

動的メモリ内ハッシュ結合

動的ハッシュ結合について説明されている考慮事項はすべて、メモリ内ハッシュ結合にも適用されます。異なる点がいくつかあり、その1つは、メモリ内ハッシュ結合のメモリの量はデフォルト値の100MBまたは値セット(ハッシュ テーブルおよびメモリ内ハッシュ テーブルのサイズの制御を参照)に達する可能性があるということです。

メモリ内動的ハッシュ結合アルゴリズムは、バルク処理向けに設計されており、複数の行を操作するために機能強化されています。このアルゴリズムは、メモリ アクセス パターン、ひいてはキャッシュ効率の改善に役立ちます。

メモリ内動的ハッシュ結合に使用するハッシュ テーブル データ構造は、従来型メモリ内ハッシュ結合に使用するものと同じです。

AllRowsOneAMPメモリ内ハッシュ結合

このタイプのハッシュ結合では、左のテーブルが1つのAMPに複製されます。メモリ内ハッシュ結合ステップは、1つのAMPから行を読み取り、ハッシュ テーブルを作成し、ハッシュ テーブル セグメントをすべてのAMPに複製します。すべてのAMPは、ハッシュ テーブル セグメントを受け取り、プローブと出力作成を継続します。ハッシュ テーブル セグメントの1コピーが、ノード内のすべてのAMPで共有されます。

メモリ内ハッシュ結合は、AllRowsOneAMPスプールの唯一のコンシューマです。

これにより、メモリ内ハッシュ結合の重複スプールを使用する場合と較べてI/Oパフォーマンスが向上します。パフォーマンス向上は、システム内のAMP数が増えると高まります。

実行モードは次の2つです。
  • デフォルト モード。左のテーブルが複製される従来型または動的なメモリ内ハッシュ結合は、AllRowsOneAMPメモリ内ハッシュ結合となります(これは、DPEメモリ内ハッシュ結合と、PRPD結合の一部であるメモリ内ハッシュ結合の場合は当てはまりません)。
  • リソース消費モード。デフォルト モードに加え、両方のテーブルが再分散される従来型のハッシュ結合は、AllRowsOneAMP-DirectまたはAllRowsOneAMP-Localのメモリ内ハッシュ結合になります。DirectかLocalかの決定は、コスト ベースで行なわれます。

どちらのモードでも、最適化ルーチンは経験則に基づく決定を行ないます。リソース消費モードは、所要時間は長くなってもリソース消費(I/O、CPU)を向上したい場合にのみ使用します。デフォルトでは、リソース消費モードは無効です。有効にするには、Teradataサポート センターにお問合わせください。

ハッシュ結合、メモリ内ハッシュ結合、およびパフォーマンス

1つ以上の結合キーにインデックスが付けられていない場合、最適化ルーチンはテーブルのマージ結合ではなくハッシュ結合を使用してパフォーマンスを向上させることができます。

ハッシュ結合ではハッシュ テーブルを使うことで、マージ結合に先立って使用されるソートが不要になります。

次のDBS制御フィールドでは、ハッシュ結合のシステム利用状況を最適化できます。

DBS制御フィールド 最適な初期設定値
HTMemAlloc
HTMemAllocを変更しても、メモリ内ハッシュ結合には影響しません。
2
SkewAllowance 75

ハッシュ結合関連のDBS制御フィールドの設定については、<Teradata Vantage™ - データベース ユーティリティ、B035-1102>にあるDBS制御フィールドの「HTMemAlloc」、「HJ2IMHJ」、および「Skew Allowance」を参照してください。

ハッシュ結合に関連するDBS制御フィールドの使用についての方針は、<Teradata Vantage™ - データベースの管理、B035-1093>の「Adjusting Skewの調整」を参照してください。

メモリ内ハッシュ結合の推奨事項

メモリ内ハッシュ結合を使用する場合の推奨事項は次のとおりです。
  • 選択性の高い列を固定長列にして、その固定長列をそれ自体による列パーティションか、狭いパーティションのいずれかにします。
  • 統計が未完了だとテーブルのカーディナリティが不正確になる場合があるため、結合条件に複数の列が関与する場合は複数列統計を収集します。この状況で、最適化ルーチンは、テーブルが使用可能なメモリ(デフォルトでは100MB)に収めることができ、したがってハッシュ テーブル オーバーフローを引き起こすことはなく、最終的にコストが少なくて済むと見なす場合があります。ハッシュ結合では、これと同じ状況が発生しません。ハッシュ テーブルの作成に使用するメモリが少なく、パフォーマンスの高いファンアウトも使用するためです。これらの事実に基づき、残りのテーブルからの結合列で複数列統計を収集することが推奨されます。
  • 前述の項目で述べたような問題を回避するため、統計を更新して最新の状態を保つようにしてください。

外部ハッシュ結合

Teradata Databaseは、左外部ハッシュ結合、右外部ハッシュ結合、および完全外部ハッシュ結合をサポートします。これらのタイプの結合は、メモリ内ハッシュ結合方式をサポートします。これらの各結合タイプの処理については、後続のトピックで説明します。

排他ハッシュ結合

排他ハッシュ結合は、リクエスト内で指定されたどの条件も満たさない(つまり、NOT INである)行のみが結合されるハッシュ結合の一種です。言い換えると、排他ハッシュ結合は、第2のテーブルに一致する行を持たない第1のテーブルの中にある行を検出するということです。

排他ハッシュ結合は、外部結合の暗黙の形式です。メモリ内ハッシュ結合では排他ハッシュ結合がサポートされていません。

包含ハッシュ結合

包含ハッシュ結合は、左リレーションの行と一致する最初の右リレーションの行が、その行に結合されるハッシュ結合の一種です。

メモリ内ハッシュ結合メソッドでは、包含ハッシュ結合がサポートされていません。