Oracle's two major index types are Bitmap indexes and
B-Tree indexes. B-Tree indexes are the regular type that OLTP systems make
much use of, and bitmap indexes are a highly compressed index type that tends to be used
primarily for data warehouses.
- For columns with very few unique values (low
cardinality)
Columns that have low cardinality are good candidates (if the cardinality of a
column is <= 0.1 % that the column is ideal candidate, consider also 0.2%
– 1%)
- Tables that have no or little insert/update are good candidates (static data in
warehouse)
- Stream of bits: each bit relates to a column value in a single
row of table
create bitmap index person_region on person (region);
Row
Region North East West South
1
North 1 0
0 0
2
East 0 1
0 0
3
West 0 0
1 0
4
West 0 0
1 0
5
South 0 0
0 1
6
North 1 0
0 0
The advantages of them are that they have a highly compressed
structure, making them fast to read and their structure makes it possible for the
system to combine multiple indexes together for fast access to the underlying
table.
Compressed indexes, like bitmap indexes,
represent a trade-off between CPU usage and disk space usage. A compressed structure is
faster to read from disk but takes additional CPU cycles to decompress for access - an
uncompressed structure imposes a lower CPU load but requires more bandwidth to read in a
short time.
One belief concerning bitmap indexes is that they are only suitable
for indexing low-cardinality data. This is not necessarily true, and bitmap indexes can
be used very successfully for indexing columns with many thousands of different
values.
The reason for confining bitmap indexes to data warehouses is that
the overhead on maintaining them is enormous. A modification to a bitmap index
requires a great deal more work on behalf of the system than a modification to a b-tree
index. In addition, the concurrency for modifications on bitmap indexes is
dreadful.