HASH JOINは、データベースで一般的なデータベース結合アルゴリズムの一種です。これは、ハッシュテーブルを使用して結合プロセスを加速します。通常、ビルドとプローブの2つの段階に分かれます。プローブ段階でデータ量が比較的大きく、出力データが少ない場合、ランタイムフィルターを有効にして、一部のデータを事前にフィルタリングすることで性能を向上させることができます。
読み取り専用分析エンジンのRuntime Filterは、RF BuildとRF Filterの2つの部分で構成されます。RF BuildはHASH JOINのBuild側でRuntime Filterを構築するために使用されます。RF Filterは対応するHASH JOINテーブルのProbe側のTableScanに配置され、データを事前にフィルタリングして性能を向上させる役割を果たします。
Runtime Filterのタイプ
Local Runtime Filter
ローカルRuntime Filterは一般的に、データJOIN時にシャッフルが行われないシナリオで使用されます。この場合、現在の構築ノードのRuntime Filterがプローブのニーズを満たすため、ネットワーク転送は不要です。Runtime Filterのデータをプローブ側に直接渡すことで利用可能になります。
上図のように、JOIN時にBuildテーブルがシャッフル送信されていない場合、同一プラン内のRuntime Filter Buildオペレータは自身のデータを構築し、対応するFilter Probe部分に送信します。
Global Runtime Filter
上図のように、JOIN時にBuildテーブルがシャッフル送信されていない場合、同一プラン内のRuntime Filter Buildオペレータは自身のデータを構築し、対応するFilter Probe部分に送信します。
JOIN時にBuildテーブルのデータがシャッフル分散される場合、現在のプラン内のRuntime Filter Buildオペレータが構築するデータは完全なものではなく、Runtime Filterは現在のオペレータが構築したデータに加え、同一プラン内の他のオペレータが構築したデータを受信し、マージした後で使用可能になります。
フィルタータイプ
フィルターアルゴリズムの選択においては、通常、データ分布の状況に応じて以下の一つまたは複数のフィルターアルゴリズムを選択します。
Bloom Filter
Bloom Filterは古典的なフィルターアルゴリズムとして、いくつかのハッシュ関数を用いてデータの存在有無を判定します。Runtime Filterにおけるブルームフィルタのサイズは通常、データのNDV(Number of Distinct Values)に依存します。当然ながら、ブルームフィルタには偽陰性(False Negative)が発生する可能性があり、フィルタリングすべきデータを正しく除去できない場合があります。ただし、これらのデータはJOINのプローブ段階で同様にフィルタリングされます。
MIN_MAX Filter
MIN_MAX FilterはBuild側データの最大値と最小値を収集し、フィルタリング時にデータがこの範囲内にあるかどうかを判断します。範囲外の場合はフィルタリングされます。Build側のデータがある範囲で分布している場合、MIN_MAX Filterのフィルタリング効果が良くなります。
IN Filter
IN FilterはNDV値が小さいシナリオを対象としており、このようなケースでは当該列のすべての値を直接プローブ側に送信してマッチングを行います。
読み取り専用分析エンジンにおけるRuntime Filter
Runtime Filterを有効化または無効化する
読み取り専用分析エンジンのRuntime Filterはデフォルトで有効になっています。以下のスイッチを使用して有効または無効にできます。
mysql> set libra_enable_runtime_filter=ON;
mysql> set libra_enable_runtime_filter=OFF;
有効にすると、オプティマイザはJOINを評価し、条件を満たす場合には自動的にRuntime Filterを有効化します。
すべてのJOINでRuntime Filterを強制的に有効化する必要がある場合、上記のパラメータに加えて以下のパラメータを設定できます。
mysql>SET libra_enable_cost_based_runtime_filter=OFF;
Runtime Filterプラン
以下のように、これはLocal RFのプランであり、JOINに三種のRuntime Filterを割り当てています。このシナリオでは、HASH JOINのBuild側とProbe側の間にデータの再分散はありません。
Global RFのプランは以下の通りです。Build側とProbe側の間にデータの再分散が存在し、RFはデータがネットワーク転送される前に事前にフィルタリング可能です。これによりネットワーク転送量と後続のJOIN処理のオーバーヘッドを削減でき、性能向上を実現できます。
Runtime Filterパラメータの調整
Runtime Filterでは以下のパラメータを調整できます。
libra_enable_runtime_filterはRuntime Filterを有効化するかどうかを示します。
|
パラメータ型 | BOOL。 |
既定値 | ON。 |
値の範囲 | ON:ランタイムフィルタを有効化します。 OFF:Runtime Filterを無効化する |
スコープ | Global & Session。 |
SET_VARヒントのサポートを提供します | はい。 |
libra_runtime_filter_type は割り当て可能な Runtime Filter タイプの設定を示します。
|
パラメータ型 | VARCHAR。 |
既定値 | MIN_MAX、BLOOM_FILTER、IN_FILTER。 |
値の範囲 | BLOOM_FILTER:JOIN BUILD側のJOIN KEYのBloom Filterを構築し、プローブ側のデータのフィルタリングを行います。 MIN_MAX:JOIN BUILD側のJOIN KEYの最大最小値を構築し、プローブ側のデータフィルタリングを行います。 IN:JOIN BUILD側のJOIN KEYの値リストを構築し、プローブ側のデータフィルタリングを行います。 空文字列:Runtime Filter機能を無効化することを意味します。 |
スコープ | Global & Session。 |
SET_VARヒントのサポートを提供します | はい。 |
libra_enable_cost_based_runtime_filterはコストベースのRuntime Filter割り当てを有効化するかどうかを示します。無効にすると、デフォルトですべてのRuntime Filterを生成します。
|
パラメータ型 | BOOL。 |
既定値 | ON。 |
値の範囲 | ON:コストベースのランタイムフィルタ割り当てを有効化する OFF:コストベースのランタイムフィルタ割り当てを無効化する。 |
スコープ | Global & Session。 |
SET_VARヒントのサポートを提供します | はい。 |
libra_max_in_runtime_filter_ndvは、コストベースのランタイムフィルタにおいて、INタイプのランタイムフィルタを生成する際のBUILD側の最大NDV(Number of Distinct Values)値を示します。
|
パラメータ型 | INT。 |
既定値 | 1024。 |
値の範囲 | 0 - MaxValue。 |
スコープ | Global & Session。 |
SET_VARヒントのサポートを提供します | はい。 |