[DB] Oracle - Bitmap INDEX

통상적으로 B tree 인덱스를 많이 사용하긴 하나 단점이 없는 것은 아니다. 예를들어 보자면 인덱스에 실제 컬럼의 값을 가지기 때문에

데이터의 중복이 일어나거나, 컬럼값의 분포도가 좁아야만 효율을 보장(컬럼의 결합생성으로 대체), NULL or NOT 과 같은 부정형 조건이나

복잡한 조건을 포함하는 경우 인덱스로서의 가치를 발휘할 수 없다는 점 등을 들 수 있겠다.



위에서 나열한 B tree 인덱스의 단점에 대한 대안을 Bitmap 인덱스는 제시할 수 있다. 그럼 Bitmap 인덱스의 구조에 대해서 먼저 알아보도록 하겠다.

위의 그림과 같은 형태의 인덱스를 생성했다고 가정해보자. 이렇게 인덱스를 생성할 경우 Root Block과 Branch Block은 B tree 인덱스와 

같은형태를 가진다. 하지만 세부 정보를 가지고 있는 Leaf Block의 경우 각 컬럼값에 해당하는 비트들이 들어가 있다.
(여기서는 yellow, green, red, null에 관한) 

이 인덱스를 이용하여 이차원 맵을 만들기 위해서는 우측 하단과 같은 형태로 컬럼값과 각 컬럼값에 대한 비트값들이 필요하다. 

더 쉽게 이해하고자 하면 우측 상단의 형태로 나타낼 수 있겠다. 우측 상단의 내용을 살펴보면 특정 컬럼에 해당하는 값만 1로 표현,

그렇지 않은 경우 0으로 모두 기록한 것을 확인할 수 있다.

우측 상단이나 하단 모두 개념적인 내용을 표현하는 것이고, 실제 인덱스를 조회할 경우 해당 COLOR의 Leaf Block에만 액세스하면 되겠다.  

비트를 저장할 때는 해당 로우가 유효값을 가지는 부분에만 1이라는 값을 저장하면 된다. 이렇게 저장된 비트값을 ROWID로 변환하는 과정을

통해 실제 데이터를 찾아갈 수 있다.  

또한 B tree 인덱스의 제한사항이라고 볼 수 있는 컬럼의 결합을 할 필요가 없다. 이러한 결합 대신에 각 컬럼대비 결과값을 이용한

비트맵 연산을 수행하면 되기 때문이다.

이렇게 또 다른 많은 장점을 가졌지만 = 이 아닌 범위를 통한 검색에는 적합하지 않다. 또한 수정이 빈번한 테이블에도 적합하지 않겠다.

 
Bitmap 인덱스를 주로 사용할 수 있는 곳은 데이터 웨어하우스이며 OLTP의 통계나 집계 업무처리 부분에도 적용 가능하겠다.

* 파티션 테이블에서는 로컬 인덱스에만 Bitmap 인덱스 적용가능


 
[Bitmap INDEX 액세스]

앞에서 만들어진것과 같은 Bitmap 인덱스를 실제로 액세스하여 결과값을 가져오는 부분에 대해서 살펴보자.

위의 그림과 같이 조건에 맞는 비트값을 추출하고 이 내용을 ROWID로 전환한다. 위 쿼리의 실행계획을 들여다보자.

다음은 비트맵 처리를 하는 과정에서의 실행계획의 종류이다.

위의 액세스 형태들이 조합되어 다양한 실행계획을 만들게 된다. 


B tree 인덱스와 의 차이점을 명확히 알아보기 위한 쿼리와 그에 따른 실행계획을 살펴보자.

NOT을 사용한 부분부터 살펴보면 col1에서 123에 해당하는 검색된 내용에서 col2 가 ABC인 것을 Bitmap MINUS를 통해 제거한다.

그리고 col2가 NULL값인 것 역시 제거를 하게 되는데, 조건에 사용된 모든 컬럼은 NULL값일 수 없기 때문이다. 

col3에 대해 범위 스캔이 발생한 결과값은 Bitmap MERGE를 통한 통합과정을 거치고, Bitmap OR를 거치고 

마지막으로 이 결과값을 Bitmap Conversion을 통한 ROWID로 전환한다. 


위의 과정을 B tree 인덱스에서 수행할 경우 OR를 기준으로 두 개의 단위 액세스가 별도 수행, 추후 결합하는 방식으로 처리된다.

<>의 경우 체크조건으로만 이용되기 때문에 실제 액세스하는 데이터 양을 감소시키지는 못한다. 이렇게 감소시키지 못하는 양이

적다고 생각할 수 있지만 많은 양의 데이터가 해당될 경우 무시할 수 없다.

Bitamp 인덱스의 경우 아직까지는 제한사항이 존재하지만 적합한 곳에 제대로 사용할 경우 탁월한 효과를 얻을 수 있겠다.

추후에 각 인덱스에 대한 실행계획을 더 자세히 알아보도록 하겠다.