본문 바로가기

데이터베이스/오라클

2. 비트맵 인덱스

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와 동일

'데이터베이스 > 오라클' 카테고리의 다른 글

5. 함수 Rank , Dense_Rank  (0) 2022.01.23
4. 뷰 Merging  (0) 2022.01.23
3. 쿼리 변환  (0) 2022.01.23
2. Index란  (0) 2022.01.18
1. 인덱스에 대한 고찰  (0) 2022.01.18