tencent cloud

TDSQL-C for MySQL

動向とお知らせ
製品アップデート
製品お知らせ
初心者ガイド
製品概要
プロダクト概要
製品の強み
適用シーン
製品アーキテクチャ
製品仕様
インスタンスタイプ
製品機能一覧
データベースのバージョン
リージョンとアベイラビリティゾーン
基本概念
利用制限
利用ガイドの推奨事項
自社開発カーネル
カーネル概要
カーネルバージョンのアップデート情報
カーネル最適化バージョン
機能特性
パフォーマンス関連機能
セキュリティカテゴリの機能
安定性機能
分析エンジン特性
カーネル問題のチェックと修復
購入ガイド
課金概要
製品価格
クラスタを作成する
構成変更説明
未払いについての説明
継続支払いの説明
返金ポリシー
従量課金から年/月単位サブスクリプションへの変換
従量課金からServerlessへの変換
付加価値サービスの課金説明
料金請求書の確認
クイックスタート
データベース監査
概要
監査インスタンス一覧
監査サービスを有効化する
監査ログの確認
ログ配信
事後アラーム設定
監査ルールの変更
監査サービスを変更する
監査サービスを停止する
監査ルールテンプレート
監査タスクの照会
サブユーザーへのデータベース監査利用権限付与
Serverlessサービス
Serverless入門
サーバーレス版クラスタの作成と管理
伸縮性スケーリング管理ツール
Serverlessリソースパック
マルチAZデプロイ
設定を変更する
よくあるご質問
Serverlessコスト見積ツール
操作ガイド
操作概要
コンソールでのクラスタページビューの切り替え
データベース接続
インスタンス管理
設定を変更する
インスタンス形態管理
クラスタ管理
読み取り専用インスタンス管理 
データベースプロキシ
アカウント管理
DMC
DMC(データベース管理ツール)
パラメータ設定
マルチAZデプロイ
グローバルデータベース
バックアップとリストア
操作ログ
データマイグレーション
パラレルクエリ
列ストレージインデックス CSI
分析エンジン
データベースセキュリティと暗号化
モニタリングとアラーム
SQLの基本操作
以下のコマンドを実行して、TDSQL-C for MySQLに接続してログインします
Tag
実践チュートリアル
TDSQL-C for MySQL データベース監査の等級保護実践
非InnoDBテーブル問題のワンクリック移行検出処理方法
DTSによるデータベースバージョンのアップグレード MySQL 5.7から8.0へ
TDSQL-C for MySQL 使用規範
新版コンソール
データベースプロキシの複数接続アドレスによる複数ROグループの実現
データベースプロキシのメリット
ストレージの課金モードの選び方
DTSによるリモートディザスタリカバリの構築
クラスタ用VPCの作成
データ復旧の方法
CPU使用率の高騰問題の解決方法
サブユーザーへの監視データ閲覧権限付与方法
ホワイトペーパー
セキュリティホワイトペーパー
性能ホワイトペーパー
トラブルシューティング
接続関連
性能関連
よくあるご質問
基本概念
購入と課金
サポートされるフォーマット
接続とネットワーク
機能特性
コンソールの操作
データベーステーブル
パフォーマンスとログ
データベース監査
TDSQL-C for MySQLとTencentDB for MySQLの違い
関連契約
SLA
利用規約
TDSQL-C ポリシー
プライバシーポリシー
データ処理と安全プロトコル
汎用参考
標準と認証
用語一覧
お問い合わせ

Runtime Filter ユーザーマニュアル

PDF
フォーカスモード
フォントサイズ
最終更新日: 2025-12-30 16:47:25
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側の間にデータの再分散はありません。

image.png


Global RFのプランは以下の通りです。Build側とProbe側の間にデータの再分散が存在し、RFはデータがネットワーク転送される前に事前にフィルタリング可能です。これによりネットワーク転送量と後続のJOIN処理のオーバーヘッドを削減でき、性能向上を実現できます。

image.png



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ヒントのサポートを提供します
はい。

ヘルプとサポート

この記事はお役に立ちましたか?

フィードバック