新インデックスの検証 その９
＜新インデックスの検証 その９＞ ペンネーム モンキーターン
今回も、引き続き bitmap join インデックス( Oracle9iから )の検証を行なう。
前回は、bitmap join インデックスの[ 作成時間 ][ 領域サイズ ][ 検索時間 ]
について、検証結果を見ていただいた。
今回は、bitmap join インデックスの[ DML処理時間 ]について検証を行なう。
検証スタート！！！
前回、検証テーブル( emp_100man )に対して、bitmap join インデックス
( bit_join_idx )を作成した。この検証テーブルに対して、DML処理を実行した
ときの負荷を検証していく。
検証テーブル( emp_100man )に100万件のデータをinsertしたときの処理時間を
測定する。
インデックスなしの場合
[ DML処理時間 = 1分35秒 ]
Normal インデックスの場合
[ DML処理時間 = 3分50秒 ]
bitmap join インデックスありの場合
[ DML処理時間 = 10分20秒 ]
上の結果より
bitmap join インデックスの[ DML処理時間 ]は、インデックスなしの場合に
比べて約10倍、Normalインデックスの場合と比べて約3倍のPerformance Downに
なっている。
これは、正直言って bitmap join インデックスを使用するにあたって注意し
なければならない点である。
前回と今回の結果より
確かに bitmap join インデックスの[ DML処理時間 ]は、Performanceが悪い。
しかし、事前に結合結果を格納できるメリットは、それ以上にすばらしいもの
があるのもまた事実である。
インデックスが作成してある表に対してバッチ処理による挿入と更新等は、関
係のあるすべてのインデックスをリアルタイムに更新する必要があるため、深
刻なオーバーヘッドが発生し、システムのパフォーマンスを大幅に低下させて
しまいます。
しかし、実表を更新する前にバッチDMLでインデックスをすべて削除し、バッチ
更新、バッチ挿入等を実行後に再作成することにより、たいていははるかに高
速に処理できることは明らかである。ただし、当然ながらすべての検索文(sel
ect文)を一時停止しておくことが前提にはなります。
bitmap join インデックスだけではありませんが、各機能のメリット・デメリ
ットを十分理解した上で使用すれば、あなたのシステムを格段に改善すること
が可能である。
今回は少々早いですが、ここまで
次回は、bitmap系を検証してみたくなったので、基本に戻って bitmap インデ
ックスの検証を行なう。
次回もお楽しみに・・・つづく
以上 雪が降った。雪が積もった。足が滑った。 茅ヶ崎にて