最適化されたビットマップフィルタリングの実装方法と仕組みを徹底解説

最適化されたビットマップフィルタリングの基本動作

ビットマップフィルタは、選択性（セレクティビティ）が高い場合にのみ有効に機能します。クエリオプティマイザーは、最適化されたビットマップフィルタが十分な選択性を持つかどうか、またどの演算子にフィルタを適用すべきかを判断します。オプティマイザーはスタースキーマ結合のすべての分岐に対して最適化されたビットマップフィルタを配置し、コストベースのルールを用いて、そのプランが最小の推定実行コストを実現できるかを評価します。

最適化されたビットマップフィルタの選択性が低い場合、コスト見積もりが過大になる傾向があり、そのプランは却下されます。プラン内のどこにビットマップフィルタを配置するかを検討する際、オプティマイザーはハッシュ結合のバリエーションとして、右側に深く積み重ねられた（ライトディープ）ハッシュ結合のスタックを想定します。この際、ディメンションテーブルとの結合は、最も選択性が高いと予測される結合から順に実行されるように構成されます。

PROBE述語が出力する情報

最適化されたビットマップフィルタが適用される演算子には、次のような形式のビットマップ述語が実行プランに含まれます。

PROBE([Opt_Bitmap1001], {[column_name]} [, 'IN ROW'])

このビットマップ述語からは、以下の情報を読み取ることができます。

• ビットマップ名：Bitmap演算子で定義された名前に対応します。接頭辞「Opt_」が付いている場合、最適化されたビットマップフィルタが利用されていることを示します。
• プローブ対象の列：フィルタリング後のデータが実行プランのツリー内を流れる起点となる列です。
• インロー最適化の要否：ビットマッププローブがインロー最適化（in-row optimization）を必要とする場合、「IN ROW」パラメータを付けて呼び出されます。不要な場合はこのパラメータは省略されます。

最適化されたビットマップフィルタリングの適用要件

最適化されたビットマップフィルタリングには、以下の要件があります。

• ファクトテーブルは最低でも100ページ以上のサイズが必要です。それより小さいテーブルはディメンションテーブルとして扱われます。
• ファクトテーブルとディメンションテーブルの間では、内部結合（INNER JOIN）のみが対象となります。
• ファクトテーブルとディメンションテーブルの結合述語は単一列による結合である必要がありますが、必ずしも主キーと外部キーの関係である必要はありません。整数型の列が優先的に選択されます。
• ディメンションテーブルとの結合は、ディメンション側の入力カーディナリティがファクトテーブル側の入力カーディナリティより小さい場合にのみ考慮されます。

並列クエリプランにおけるビットマップフィルタの役割

ビットマップフィルタリングおよび最適化されたビットマップフィルタリングは、クエリプラン内でBitmap表示プラン演算子を使用して実行されます。通常のビットマップフィルタリングは、ハッシュ結合またはマージ結合を使用する並列クエリプランでのみ利用可能です。一方、最適化されたビットマップフィルタリングは、ハッシュ結合を使用する並列クエリプランにのみ適用されます。

いずれの場合も、ビットマップフィルタはハッシュ結合のビルド入力側（ディメンションテーブル）で生成されます。ただし、実際のフィルタリング処理は一般的に、ハッシュ結合のプローブ入力側（ファクトテーブル）に位置するParallelism演算子の中で実行されます。結合キーが整数型の列である場合、Parallelism演算子を経由せず、元のテーブルスキャンやインデックススキャンの段階で直接フィルタを適用することが可能です。この手法が「インロー最適化」と呼ばれるものです。