ビットマップ フィルタを使ったデータ ウェアハウスのクエリ パフォーマンスの最適化
データ ウェアハウスのクエリは、そのほとんどがスター スキーマに従って設計され、数億件の行を 1 回のクエリで処理できます。既定では、スター スキーマに対するクエリがクエリ オプティマイザによって検出され、効率的なクエリ プランが作成されます。オプティマイザが効率的なプランを生成するために用いる手法の 1 つにビットマップ フィルタがあります。ビットマップ フィルタは、操作ツリーの特定の部分にあるテーブルから得られた一連の値の圧縮表現を使用して、同じツリーの別の部分にある 2 つ目のテーブルから行を抽出します。このフィルタが実行していることは、基本的には半結合による除去処理です。つまり、2 つ目のテーブルでは、1 つ目のテーブルと結合するのに適した行だけが処理されます。
SQL Server 2008 では、SQL Server 2005 と同様、ビットマップ フィルタは、最適化後のクエリ プランで導入できるほか、クエリ プランの生成中にクエリ オプティマイザで動的に導入することもできます。フィルタを動的に導入することを最適化されたビットマップ フィルタと呼びます。最適化されたビットマップ フィルタでは、条件に該当しない行をクエリ プランの初期段階でファクト テーブルから排除できるため、スター スキーマを使ったデータ ウェアハウス クエリのパフォーマンスを飛躍的に高めることができます。最適化されたビットマップ フィルタを使用しなかった場合、ディメンション テーブルとの結合操作で条件に該当しない行が削除される前に、操作ツリーのどこかの部分でファクト テーブルのすべての行が処理されてしまいます。最適化されたビットマップ フィルタを適用することによって、条件に該当しない行をファクト テーブルから即座に排除できます。
最適化されたビットマップ フィルタは、SQL Server の Enterprise Edition、Developer Edition、および Evaluation Edition でのみ使用できます。
ビットマップ フィルタについて
ビットマップ フィルタには、ビットマップ インデックスにはない利点があります。ビットマップ インデックスは、値リスト インデックス内の行 ID (RID) リストを表現するための代替形式です。テーブル内の特定の列値を格納している行が、1 つ以上のビット ベクタを使って表されます。どちらも、結果の処理から不要な行を取り除くという点ではきわめて効果的ですが、ビットマップ フィルタとビットマップ インデックスとの間には大きな違いがあります。まず、ビットマップ フィルタはインメモリ構造であるため、基になるテーブルに対して DML (データ操作言語) 操作が実行された場合でもインデックスのメンテナンスに伴うオーバーヘッドを低く抑えることができます。さらに、ビットマップ フィルタは、非常にコンパクトであるという特長があります。既存のディスク格納型のインデックスが、対応するテーブルのサイズに依存するのに対し、ビットマップ フィルタは、クエリの処理時間に与える影響を最小限に抑えながら動的に作成できます。
ビットマップ フィルタと最適化されたビットマップ フィルタの比較
クエリ プランにビットマップ フィルタや最適化されたビットマップ フィルタを実装するには、Bitmap プラン表示操作を使用します。ビットマップ フィルタは、ハッシュ結合またはマージ結合が使用されている並列クエリ プランでのみ適用されます。最適化されたビットマップ フィルタは、ハッシュ結合が使用されている並列クエリ プランにのみ適用できます。いずれの場合も、ハッシュ結合のビルド入力 (ディメンション テーブル) 側にビットマップ フィルタが作成されます。ただし、実際のフィルタ処理は、ハッシュ結合のプローブ入力 (ファクト テーブル) 側にある Parallelism 操作内で実行されるのが一般的です。整数型の列に基づく結合の場合、フィルタは Parallelism 操作ではなく、初期テーブルまたはインデックス スキャン操作に直接適用できます。この手法を行内最適化と呼びます。
最適化後、クエリ プランにビットマップ フィルタが導入された場合、クエリのコンパイル時間は短縮されます。ただし、オプティマイザが生成できるクエリ プランは制限され、基数やコストの見積もりは考慮されません。
最適化されたビットマップ フィルタには、次のような利点があります。
複数のディメンション テーブルからのフィルタがサポートされます。
1 つの操作に複数のフィルタを適用できます。
最適化されたビットマップ フィルタは、さまざまな種類の操作に適用できます。たとえば、Distribute Streams や Repartition Streams などの交換操作のほか、テーブル スキャン、インデックス スキャン、フィルタなどの操作に適用できます。
SELECT ステートメントのほか、INSERT、UPDATE、DELETE、MERGE の各ステートメントで使用されている読み取り専用操作にフィルタを適用できます。
インデックス付きビューの作成で、インデックスを挿入するための操作にフィルタを適用できます。
オプティマイザは、基数およびコストの推定により、最適化されたビットマップ フィルタが適切かどうかを判断します。
オプティマイザはさまざまなプランを生成できます。
最適化されたビットマップ フィルタの実装方法
ビットマップ フィルタの効果が期待できるのは選択度が高い場合だけです。クエリ オプティマイザは、どのような場合に、最適化されたビットマップ フィルタの選択度が効果を期待できる程度に高くなるか、また、どのような操作にフィルタを適用すべきかを判断します。オプティマイザは、スター結合のすべての分岐に最適化されたビットマップ フィルタを設定し、コスト ルールを使用しながら、そのプランが最小の推定実行コストを提供するかどうかを判断します。最適化されたビットマップ フィルタの選択度が低かった場合、推定コストが高すぎるとして、そのプランは破棄されます。最適化されたビットマップ フィルタをプラン内のどこに配置すべきかを検討する際、オプティマイザは、適切な深さのハッシュ結合のスタックなど、ハッシュ結合の派生形を探します。ディメンション テーブルとの結合が実装されて、最も選択度が高いと推定される結合が最初に実行されます。
最適化されたビットマップ フィルタが適用された操作には、PROBE([Opt_Bitmap1001], {[column_name]} [, 'IN ROW']) という形式のビットマップ述語が存在します。ビットマップ述語は、次の情報をレポートします。
Bitmap 操作で導入された名前に対応するビットマップ名。プレフィックス 'Opt_' は、最適化されたビットマップ フィルタが使用されていることを示します。
プローブの対象列。フィルタ処理されたデータは、ここを起点としてツリーを通過します。
ビットマップ プローブで行内最適化が使用されるかどうか。使用される場合、ビットマップ プローブが IN ROW パラメータで呼び出されます。それ以外の場合、このパラメータは省略されます。
例
次の例は、単純なスター スキーマに対するクエリを表しています。単一の整数型列で主キー対外部キーの結合を使用し、DimProduct と DimCustomer という 2 つのディメンション テーブルを、ファクト テーブル FactInternetSales に結合します。
USE AdventureWorksDW;
GO
SELECT *
FROM dbo.FactInternetSales AS F
INNER JOIN dbo.DimProduct AS D1 ON F.ProductKey = D1.ProductKey
INNER JOIN dbo.DimCustomer AS D2 ON F.CustomerKey = D2.CustomerKey
WHERE D1.StandardCost <= 30 AND D2.YearlyIncome <= 50000;
次の図は、SQL Server 2005 における、このクエリの実行プランを表しています。1A 地点では、既にディメンション テーブルがスキャンされており、条件に該当しない行をファクト テーブル (1B) から除外するための情報が把握されています。ただし、Table Scan 操作のプロパティは、ファクト テーブルから取得する行を制限するための述語が使用されていないことを示しています。
一方、次の図は、SQL Server 2008 における、同じクエリの実行プランを表しています。最適化されたビットマップ操作は、両方のディメンション テーブルのサブツリーで使用されます。テーブル スキャン オペレータのプロパティは、最初の結合操作の前に、これらのサブツリーからのフィルタ (ビットマップ プローブ) が直接ファクト テーブル ツリーに適用され、ファクト テーブルから取得する行が制限されていることを示しています。
最適化されたビットマップ フィルタの要件
最適化されたビットマップ フィルタには、次の要件があります。
ファクト テーブルのページ数が 100 ページ以上あること。それより小さなテーブルは、オプティマイザによってディメンション テーブルと見なされます。
ファクト テーブルとディメンション テーブル間の内部結合のみ考慮される。
ファクト テーブルとディメンション テーブル間の結合述語が単一列結合であること。主キー対外部キーの関係である必要はありません。整数ベースの列をお勧めします。
ディメンションとの結合は、ディメンションの入力基数が、ファクト テーブルの入力基数よりも小さい場合にのみ考慮される。