정미나닷컴
[Oracle] 오라클 인덱스 구조 - Bitmap Index, 비트맵 인덱스 본문
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와 동일
'IT' 카테고리의 다른 글
[Oracle] 오라클 JOIN 순서의 중요성 (0) | 2017.10.29 |
---|---|
[Oracle] 오라클 인덱스 설계 (0) | 2017.10.26 |
[Oracle] 오라클 HWM (High Water Mark) (0) | 2017.10.22 |
[Oracle] 오라클 인덱스 단편화, Index Fragmentation (0) | 2017.10.22 |
[Oracle] 오라클 인덱스 스캔효율 (0) | 2017.10.15 |