ビットマップインデックスの構造
- 値に該当するかどうかをビットマップで持つ
- あるカラムが「特定の値であるか」を0/1で表現する
- 値とROW_IDのStart/Endをツリー構造で持つ
ビットマップインデックスを使うメリット
* ROW_IDを持たず、連続するビット値は圧縮されるため、B-Treeに比べて容量が少なくて済む * カーディナリティの低いカラムの検索に強い * NULLの検索も可能 * AND、OR検索にも強い（論理和で検索できるから）
ビットマップインデックスを使うデメリット
データの登録・更新・削除時はブロック単位でロックがかかるため、性能劣化（待機の発生）が起こりやすい
（論理的には、ビットマップセグメントと考えてもそれほど差支えはなさそう）Aという値をBに変えた場合に、Aのビットマップを0にBのビットマップを1に変更する必要がある
- 新規登録の場合はカラムが取りうる値すべてのビットマップに対してインサートが必要
- 同値のビットマップは圧縮されるため、ブロック単位でのロック行数は膨大になる可能性がある
（0のビットマップが1億件連続していたとしたら、それは圧縮して同一ブロックに格納される）
まとめ
- 膨大なレコードのロックが頻発することを考えると、OLTPには向かない
- OLAP（BIとか）データがReadOnlyの場合有用
使用例
性別カラムとかには分かりやすく便利そう！
