정미나닷컴

[Oracle] 오라클 인덱스 구조 - Bitmap Index, 비트맵 인덱스 본문

IT

[Oracle] 오라클 인덱스 구조 - Bitmap Index, 비트맵 인덱스

정미나 2017. 10. 22. 18:51

Bitmap Index (비트맵 인덱스)


- Key 값에 중복이 없고, Key 값 별로 하나의 비트맵 레코드를 가짐

- 비트맵 상의 각 비트가 하나의 테이블 레코드와 매핑  


row#0( 8001) flag: ------, lock: 0, len=35

col 0; len 2;  (4):  42 4c 55 45                    키 값 : BLUE

col 1; len 6;  (6):  01 00 9f 4c 00 00        → 시작 RowID

col 2; len 6;  (6):  01 01 a4 03 01 47       → 종료 RowID

col 3; len 15;  (15):  00 c1 ae bb fa 02 c1 a1 10 c1 94 19 c2 dc 07    → 비트맵

- 시작 RowID와 종료 RowID만 갖고 있다가 테이블 액세스가 필요할 때면 각 비트가 첫번째 비트로부터 떨어져 있는 상대적인 거리를 이용해 RowID 값을 환산 (오라클이 한 블록에 저장할 수 있는 최대 레코드 수를 이용해 계산)




Key 값의 수가 많을 때

- Key 값의 수가 너무 많아 한 블록에 모두 담지 못할 경우 B*Tree 구조를 사용

- Key 값의 수가 많을수록 인덱스 높이 증가

- B*Tree 인덱스보다 더 많은 공간을 차지할 수 있어 비효율적


Key 값별로 Row 수가 많을 때

- Row 수가 너무 많아 한 블록에 모두 담지 못하는 경우 두 개 이상의 블록에 저장

- 한 블록에 적어도 2개 비트맵 레코드가 담기도록 잘라서 저장

  (한 블록에 저장 가능한 start RowID, end RowID → 1~50 이라고 했을 때 1~25/26~50 으로 잘라서 저장한다는 말?)


비트맵 인덱스 활용

- Distinct Value 개수가 적을 때 효율적

- 적은 용량을 차지하므로 인덱스가 여러개 필요한 대용량 테이블에 유용 (다양한 dimension을 가진 팩트성 테이블, DW)

- Lock에 의한 DML 부하가 심하므로(레코드 하나만 변경되더라도 해당 비트맵 범위에 속한 모든 레코드에 Lock이 걸림) OLTP성 환경에 부적합

- Table Random Access가 발생하는 건 B*Tree와 동일