비트맵 인덱스은 데이터 변경 시 B*TREE 인덱스와는 다른 점이 있다. B*TREE 인덱스는 변경되는 인덱스 엔트리에만 영향을 주는 반면, 비트맵 인덱스는 모든 비트맵에 영향을 끼친다는 것 바로 이점이다.

비트맵 인덱스의 변경

비트맵 인덱스는 비트값들을 압축해 리프 블록에 저장한다. 이 덕분에 작은 크기에 더 많은 비트맵을 저장할 수 있는 이점이 있다. 그러나 해당 비트값이 변경돼야 할 때에는 얘기가 달라진다.

압축된 각 컬럼 값의 비트맵을 압축 해제하고, 각각의 인덱스 비트맵을 모두 변경해야 하기 때문이다. 이때 리프 블록 레벨의 락(Lock)이 발생된다. 해당 테이블에 변경이 발생하는 경우 많은 부하가 뒤따르는 구조인 것이다.

<그림 2>처럼 <이현희, 여자>라는 데이터가 테이블에 삽입(Insert)되면 비트맵 인덱스에도 < 이현희, 여자>에 대한 비트맵이 추가된다. B*TREE 인덱스처럼 <이현희, 여자>를 인덱스 엔트리에 삽입하는 것이 아니라 모든 컬럼 값의 비트맵에 해당 데이터의 비트값을 추가한다.

데이터 삽입 시 인덱스에 해당 값만 저장하는 게 아니라 모든 비트맵을 변경해야 하다보니 성능 저하가 발생하게 된다. 이는 데이터의 삽입뿐 아니라 업데이트(Update), 삭제(Delete) 시에도 동일하다. 그러므로 비트맵 인덱스는 DML(Data Manipulation Language)이 많은 테이블에는 적합하지 않다.

비트맵 인덱스의 생성

비트맵 인덱스는 어떻게 생성하면 될까? 생성 방식은 B*TREE 인덱스와 거의 유사하다. 단지 생성 시 옵션을 선택해야 할 뿐이다.

• [리스트 1] 비트맵 인덱스 생성

•   CREATE BITMAP INDEX DEPT_IDX ON DEPT (DNAME);
  

<리스트 1> SQL 문으로 비트맵 인덱스를 생성할 수 있다. 생성 시 create_bitmap_area_size 매개변수에 설정된 값만큼 메모리를 사용하게 된다.

지금부터는 비트맵의 장단점에 대해 알아보자. 이를 명확히 이해해야만 어떤 경우에 비트맵 인덱스를 써야할지 알 수 있을 것이다.

비트맵 인덱스의 장점

비트맵 인덱스는 인덱스 크기가 작다는 점, 그리고 분포도가 낮은 컬럼에 유리한 강점을 가지고 있다.

· 비트맵으로 인덱스 값을 관리하고 해당 비트맵을 압축하므로 B*TREE 인덱스보다 작은 용량을 차지한다.

· 데이터 웨어하우스(Data Warehouse, 이하 DW)처럼 대용량이고 분포도가 낮은 컬럼에 사용하는 게 효과적이다. DW 등의 시스템에서는 통계 데이터를 추출하기 위해 분포도가 낮은 컬럼에 대해서도 많은 액세스를 수행한다.

예컨대 연령별 월 사용금액을 추출할 경우 연령이라는 컬럼 자체는 분포도가 낮다. 이 경우 비트맵 인덱스으로 상당한 성능 향상 효과를 얻을 수 있다.

비트맵 인덱스의 단점

비트맵 인덱스는 B*TREE 인덱스 대비 동일한 데이터에 있어 인덱스 크기가 더 작다. 분포도가 낮은 컬럼에 유리한 강점을 가졌는데, 단점은 무엇일까.

· 비트맵 인덱스는 DML이 많은 테이블에서 블록 레벨 락에 의한 DML 속도 저하가 발생할 수 있다.

· 분포도가 낮은 컬럼에 적용해도 성능 저하가 발생한다.

DML이 많거나 컬럼의 분포도가 높은 경우 B&TREE 인덱스는 이용하는 게 바람직하다.

컬럼의 분포도가 높다는 것은 관리해야 할 비트맵의 개수가 많음을 의미한다. 비트맵 인덱스는 비트맵이 많으면 성능을 보장하기 어려운 태생적 한계를 가지고 있다. 따라서 기수(Cardinality)가 낮은 컬럼에 비트맵 인덱스를 써야 한다.

또 DML이 발생하면 압축돼 있는 비트맵의 압축을 해제하고 변경한 후 다시 압축해야 한다. 이러한 작업을 모든 비트맵에 수행해야 하므로 DML이 많은 테이블에 비트맵 인덱스를 쓰는 것은 바람직하지 않다.